GUI в расте нормально (в продакшене) не щупал, поэтому спорить не буду. Хотя мне кажется, что GUI в целом чаще в виде фреймворков реализован. Ну а касательно тоника - коммуникация через каналы кажется вполне себе прямым способом, а не костылём.
Мне кажется, что выборка специфическая. Я не придираюсь, скорее любопытно. Можно список, скажем, из десяти таких библиотек? По моему, это справедливо для веб-фреймворков, но зачем иметь несколько в одной кодовой базе? Ещё можно про асинхронные рантаймы и то практически все используют токио и не парятся.
Так я же не спорю с претензиями к языку. Автор оригинальной статьи поделился ценным опытом, можно быть в чём-то не согласным, но мнение в любом случае полезно. Но после вот этой цитаты:
Ну человек прав в том, что все rust комьюнити этого не понимает. То есть они пытаются писать движки вместо игр
Мне показалось, что мы обсуждаем конкретно то, что движки делают "не так как надо". Вот и высказался, что пока этим занимаются несколько энтузиастов в свободное время, то такие претензии не совсем по адресу.
Подозреваю, что большинству из тех, кто пилит движки (тот же беви) интересно как раз пилить движок. Учитывая, что это всё делается на добровольных началах, то странно предъявлять претензии к тому как люди тратят своё свободное время.
Да, было бы неплохо, если появился бы конкурент коммерческим движкам на расте, но я не уверен, что есть смысл это требовать от кучки энтузиастов.
Вместо следования semver (что вообще-то является обязательным для проектов cargo, т.к. именно так cargo обрабатывает поле version), автор наперекор всем делает ломающие изменения в патчах
А разве это именно ломающее изменение? Вроде, же просто расширение апи? Ну то есть формально да, это нарушение семвер, но не кажется прям большой проблемой. Ну и если бы у серде стали мажорную версию инкрементировать, то больно стало бы всем.
Ну а так-то чувак тащит на себе кучу крейтов. Ожидаемо на всё времени не хватает, но да, меня тоже расстраивает, что "делиться ответственностью" он не спешит.
Дык, в С++ множество WTF моментов вызваны как раз синтаксисом, который вынужден быть таким из-за совместимости. А это в расте можно понемногу изменять.
Нытьё про хайп тоже. Такая реакция понятна когда расто-фанатики приходят с агитацией в тему про С++. Но тут-то это причём? Новость вполне интересная: показывает и интерес от гугла и любопытно будет посмотреть на результаты.
Мне хаскель тоже нравится, но как сюда добавить лайфтамы?.. Более того, есть подозрение, что те люди, которые на синтаксис раста жалуются, от хаскеля ещё больше взвоют. В конце-концов большинство языков С-подобные, а плюсовиков и треугольными скобками не напугаешь. Основная претензия к кавычкам лайфтаймов.
В том числе. Наверное, зависит от того как смотреть: для "полноценно компилируемых" языков JIT действительно не нужен. Но вроде как ни джава ни C# не считаются интерпретируемыми?..
есть категория программистов, которые не могут жить, чтобы не изучить новый язык за период времени Т. не новую технологию, а именно язык.
Как будто что-то плохое. Да и бывают языки сильно разные и дающие новые абстракции и "технологии". Одно дело изучать Swift/Kotlin/C# один за другим (и то каждый язык даёт доступ к куче библиотек соответствующей платформы) и совсем другое пощупать хаскель или лисп. Да банально С++ после С уже много нового даст. Опять же, если всю жизнь писать на языках с GC, то язык с "ручным" управлением памятью заставит думать иначе.
вот при чем тут жабаскрипт и rust?
Сам не знаю почему, но по ощущениям раст достаточно популярен в среде веб-разработчиков. Подозреваю, что люди просто хотят попробовать что-то новое и я не могу их за это осуждать.
Но вот например авторы salsa решили для своих отменяемых запросов применять подход, сильно напоминающий использование исключений
Любопытный пример, на досуге изучу подробнее. Но пока остаюсь при своём мнении, что это всё же редкость.
И это уж не говоря о ситуациях, когда ошибки и не стараются прокидывать наверх вовсе, а просто пишут unwrap().
В определённых случаях это вполне уместно.
Это пока вам не нужно преобразовать один "не ваш" тип, входящий в состав Result в другой "не ваш" тип для его дальнейшего проброса наверх.
Если преобразовывать надо в чужой тип, значит на это полагается какой-то внешний код. То есть, преобразование и с исключениями нужно будет. И в этом случае бойлерлейта будет даже больше:
Хех, ну судя по рейтингу статьи и каментам, читатель не впечатлился :) Так что так себе пример.
Только сейчас заметил, что дал ссылку на статью в комментариях к которой мы и находимся. ? Переходил к обсуждению из почты, так что не обратил на это внимание. Но вообще подобное нытья я тоже видел неоднократно.
И где там такое? Ещё раз: я про техническую возможность. Да, она есть. Точно так же как технически можно сделать С++ либу с ошибками через подобие errno/GetLastError. И не удивлюсь если даже такие примеры можно найти, но утверждать, что это распространённая практика, которую кое-как сдерживают рекомендации будет весьма странно.
Или вы придрались к слову "повсеместно"?
Нет, я придрался к "такая практика распространена достаточно широко". И то не придрался, а поинтересовался есть ли повод для таких утверждений или это просто гадания основанные на формулировке из документации.
"Повсеместно" народ пишет бойлерплейты по прокидыванию наверх Result'ов
Что ж, я рад, что в этом мы согласны. Ну с поправкой, что все эти ужасные бойлерплейты как правило состоят аж целого вопросительного знака. Ок, нескольких вопросительных знаков по стеку вызовов.
Казалось бы, что плохого в том, чтобы иметь выбор?
Разве это не очевидно? Фрагментация инфраструктуры и неудобства при интеграции библиотек, авторы которых сделали выбор противоположный нашему. Если что, я не собираюсь спорить, что как возможность выбирать в целом, так и исключения в частности имеют свои достоинства.
А потом дженерики добавили в язык, и довольных этим в конечном счете оказалось больше, чем недовольных.
Опять же, любопытно есть ли статистика? И можно ли в принципе её объективно собрать... Так-то мне периодически попадались статьи и жалобы, вот например из недавнего на хабре. Да и что могут сделать недовольные? Максимум не использовать дженерики в своём коде, не форкнуть же язык в самом деле.
GUI в расте нормально (в продакшене) не щупал, поэтому спорить не буду. Хотя мне кажется, что GUI в целом чаще в виде фреймворков реализован. Ну а касательно тоника - коммуникация через каналы кажется вполне себе прямым способом, а не костылём.
Мне кажется, что выборка специфическая. Я не придираюсь, скорее любопытно. Можно список, скажем, из десяти таких библиотек? По моему, это справедливо для веб-фреймворков, но зачем иметь несколько в одной кодовой базе? Ещё можно про асинхронные рантаймы и то практически все используют токио и не парятся.
Так я же не спорю с претензиями к языку. Автор оригинальной статьи поделился ценным опытом, можно быть в чём-то не согласным, но мнение в любом случае полезно. Но после вот этой цитаты:
Мне показалось, что мы обсуждаем конкретно то, что движки делают "не так как надо". Вот и высказался, что пока этим занимаются несколько энтузиастов в свободное время, то такие претензии не совсем по адресу.
Подозреваю, что большинству из тех, кто пилит движки (тот же беви) интересно как раз пилить движок. Учитывая, что это всё делается на добровольных началах, то странно предъявлять претензии к тому как люди тратят своё свободное время.
Да, было бы неплохо, если появился бы конкурент коммерческим движкам на расте, но я не уверен, что есть смысл это требовать от кучки энтузиастов.
А разве это именно ломающее изменение? Вроде, же просто расширение апи? Ну то есть формально да, это нарушение семвер, но не кажется прям большой проблемой. Ну и если бы у серде стали мажорную версию инкрементировать, то больно стало бы всем.
Ну а так-то чувак тащит на себе кучу крейтов. Ожидаемо на всё времени не хватает, но да, меня тоже расстраивает, что "делиться ответственностью" он не спешит.
Предположу, что человека смущает слишком яркая "титульная" картинка проекта.
Yвеличение времени компиляции и IDE с макросами не очень хорошо работают. Хотя в данном случае мне кажется, что от этого никуда не деться.
abi_stable
Дык, в С++ множество WTF моментов вызваны как раз синтаксисом, который вынужден быть таким из-за совместимости. А это в расте можно понемногу изменять.
Разве это правда? По моему, данный жанр определяется походовостью, процедурной генерацией уровней и окончательной смертью.
По моему, rougelike тут используется как синоним убогой игры. Миллионы кабанов - это скорее про ммо.
Это не в защиту смуты, просто не понятно чем совсем жанр провинился, который тут и рядом не стоял.
А что не так с именованием?
Раст всё-таки достаточно низкоуровневый, переходить на него с языков со сборкой мусора есть смысл только если есть понимание зачем.
Нытьё про хайп тоже. Такая реакция понятна когда расто-фанатики приходят с агитацией в тему про С++. Но тут-то это причём? Новость вполне интересная: показывает и интерес от гугла и любопытно будет посмотреть на результаты.
И тем не менее такой стиль часто встречается. Мне лично с
mod.rsтоже больше нравится.Если человек лепит проверки наугад, то шанс, что он забудет что-то "критически важное" наоборот повышается. Ну и плюс мусорный код затрудняет чтение.
Мне хаскель тоже нравится, но как сюда добавить лайфтамы?.. Более того, есть подозрение, что те люди, которые на синтаксис раста жалуются, от хаскеля ещё больше взвоют. В конце-концов большинство языков С-подобные, а плюсовиков и треугольными скобками не напугаешь. Основная претензия к кавычкам лайфтаймов.
В том числе. Наверное, зависит от того как смотреть: для "полноценно компилируемых" языков JIT действительно не нужен. Но вроде как ни джава ни C# не считаются интерпретируемыми?..
Как будто что-то плохое. Да и бывают языки сильно разные и дающие новые абстракции и "технологии". Одно дело изучать Swift/Kotlin/C# один за другим (и то каждый язык даёт доступ к куче библиотек соответствующей платформы) и совсем другое пощупать хаскель или лисп. Да банально С++ после С уже много нового даст. Опять же, если всю жизнь писать на языках с GC, то язык с "ручным" управлением памятью заставит думать иначе.
Сам не знаю почему, но по ощущениям раст достаточно популярен в среде веб-разработчиков. Подозреваю, что люди просто хотят попробовать что-то новое и я не могу их за это осуждать.
Разве?
Любопытный пример, на досуге изучу подробнее. Но пока остаюсь при своём мнении, что это всё же редкость.
В определённых случаях это вполне уместно.
Если преобразовывать надо в чужой тип, значит на это полагается какой-то внешний код. То есть, преобразование и с исключениями нужно будет. И в этом случае бойлерлейта будет даже больше:
Только сейчас заметил, что дал ссылку на статью в комментариях к которой мы и находимся. ? Переходил к обсуждению из почты, так что не обратил на это внимание. Но вообще подобное нытья я тоже видел неоднократно.
И где там такое? Ещё раз: я про техническую возможность. Да, она есть. Точно так же как технически можно сделать С++ либу с ошибками через подобие
errno/GetLastError. И не удивлюсь если даже такие примеры можно найти, но утверждать, что это распространённая практика, которую кое-как сдерживают рекомендации будет весьма странно.Нет, я придрался к "такая практика распространена достаточно широко". И то не придрался, а поинтересовался есть ли повод для таких утверждений или это просто гадания основанные на формулировке из документации.
Что ж, я рад, что в этом мы согласны. Ну с поправкой, что все эти ужасные бойлерплейты как правило состоят аж целого вопросительного знака. Ок, нескольких вопросительных знаков по стеку вызовов.
Разве это не очевидно? Фрагментация инфраструктуры и неудобства при интеграции библиотек, авторы которых сделали выбор противоположный нашему. Если что, я не собираюсь спорить, что как возможность выбирать в целом, так и исключения в частности имеют свои достоинства.
Опять же, любопытно есть ли статистика? И можно ли в принципе её объективно собрать... Так-то мне периодически попадались статьи и жалобы, вот например из недавнего на хабре. Да и что могут сделать недовольные? Максимум не использовать дженерики в своём коде, не форкнуть же язык в самом деле.