Как стать автором
Обновить
30
0
Станислав Ткач @DarkEld3r

Rust developer

Отправить сообщение

Yвеличение времени компиляции и IDE с макросами не очень хорошо работают. Хотя в данном случае мне кажется, что от этого никуда не деться.

Дык, в С++ множество WTF моментов вызваны как раз синтаксисом, который вынужден быть таким из-за совместимости. А это в расте можно понемногу изменять.

У нас rougelike? Там надо по стопиццот раз ударить по шарику слизи, чтобы нанести ему урон.

Разве это правда? По моему, данный жанр определяется походовостью, процедурной генерацией уровней и окончательной смертью.

Но тогда игра превращается в rougelike набор квестов, в которых надо фармить миллион кабанов.

По моему, rougelike тут используется как синоним убогой игры. Миллионы кабанов - это скорее про ммо.

Это не в защиту смуты, просто не понятно чем совсем жанр провинился, который тут и рядом не стоял.

вот эта смесь такого подхода к именованию

А что не так с именованием?

и думаешь, ну нормально же все на typescript пишу. Непреходящее ощущение от Rust, что это как C++ std 2.0

Раст всё-таки достаточно низкоуровневый, переходить на него с языков со сборкой мусора есть смысл только если есть понимание зачем.

Нытьё про хайп тоже. Такая реакция понятна когда расто-фанатики приходят с агитацией в тему про С++. Но тут-то это причём? Новость вполне интересная: показывает и интерес от гугла и любопытно будет посмотреть на результаты.

И тем не менее такой стиль часто встречается. Мне лично с mod.rs тоже больше нравится.

Если человек лепит проверки наугад, то шанс, что он забудет что-то "критически важное" наоборот повышается. Ну и плюс мусорный код затрудняет чтение.

Мне хаскель тоже нравится, но как сюда добавить лайфтамы?.. Более того, есть подозрение, что те люди, которые на синтаксис раста жалуются, от хаскеля ещё больше взвоют. В конце-концов большинство языков С-подобные, а плюсовиков и треугольными скобками не напугаешь. Основная претензия к кавычкам лайфтаймов.

В том числе. Наверное, зависит от того как смотреть: для "полноценно компилируемых" языков JIT действительно не нужен. Но вроде как ни джава ни C# не считаются интерпретируемыми?..

есть категория программистов, которые не могут жить, чтобы не изучить
новый язык за период времени Т. не новую технологию, а именно язык.

Как будто что-то плохое. Да и бывают языки сильно разные и дающие новые абстракции и "технологии". Одно дело изучать Swift/Kotlin/C# один за другим (и то каждый язык даёт доступ к куче библиотек соответствующей платформы) и совсем другое пощупать хаскель или лисп. Да банально С++ после С уже много нового даст. Опять же, если всю жизнь писать на языках с GC, то язык с "ручным" управлением памятью заставит думать иначе.

вот при чем тут жабаскрипт и rust?

Сам не знаю почему, но по ощущениям раст достаточно популярен в среде веб-разработчиков. Подозреваю, что люди просто хотят попробовать что-то новое и я не могу их за это осуждать.

JIT. Это прерогатива интерпретируемых языков.

Разве?

Но вот например авторы salsa решили для своих отменяемых запросов применять подход, сильно напоминающий использование исключений

Любопытный пример, на досуге изучу подробнее. Но пока остаюсь при своём мнении, что это всё же редкость.

И это уж не говоря о ситуациях, когда ошибки и не стараются прокидывать наверх вовсе, а просто пишут unwrap().

В определённых случаях это вполне уместно.

Это пока вам не нужно преобразовать один "не ваш" тип, входящий в состав Result в другой "не ваш" тип для его дальнейшего проброса наверх.

Если преобразовывать надо в чужой тип, значит на это полагается какой-то внешний код. То есть, преобразование и с исключениями нужно будет. И в этом случае бойлерлейта будет даже больше:

foo().map_err(|e| AnotherError(...))?;
try {
    foo();
} catch(SomeException e) {
    throw AnotherException(...);
}

Хех, ну судя по рейтингу статьи и каментам, читатель не впечатлился :) Так что так себе пример.

Только сейчас заметил, что дал ссылку на статью в комментариях к которой мы и находимся. 🙃 Переходил к обсуждению из почты, так что не обратил на это внимание. Но вообще подобное нытья я тоже видел неоднократно.

Вам ссылку на ваш комментарий еще раз прислать?

И где там такое? Ещё раз: я про техническую возможность. Да, она есть. Точно так же как технически можно сделать С++ либу с ошибками через подобие errno/GetLastError. И не удивлюсь если даже такие примеры можно найти, но утверждать, что это распространённая практика, которую кое-как сдерживают рекомендации будет весьма странно.

Или вы придрались к слову "повсеместно"?

Нет, я придрался к "такая практика распространена достаточно широко". И то не придрался, а поинтересовался есть ли повод для таких утверждений или это просто гадания основанные на формулировке из документации.

"Повсеместно" народ пишет бойлерплейты по прокидыванию наверх Result'ов

Что ж, я рад, что в этом мы согласны. Ну с поправкой, что все эти ужасные бойлерплейты как правило состоят аж целого вопросительного знака. Ок, нескольких вопросительных знаков по стеку вызовов.

Казалось бы, что плохого в том, чтобы иметь выбор?

Разве это не очевидно? Фрагментация инфраструктуры и неудобства при интеграции библиотек, авторы которых сделали выбор противоположный нашему. Если что, я не собираюсь спорить, что как возможность выбирать в целом, так и исключения в частности имеют свои достоинства.

А потом дженерики добавили в язык, и довольных этим в конечном счете оказалось больше, чем недовольных.

Опять же, любопытно есть ли статистика? И можно ли в принципе её объективно собрать... Так-то мне периодически попадались статьи и жалобы, вот например из недавнего на хабре. Да и что могут сделать недовольные? Максимум не использовать дженерики в своём коде, не форкнуть же язык в самом деле.

то есть фактически вы рекламировали панику как некий аналог исключений.

Нет, не рекламировал. Я и сейчас считаю, что когда говорят, что в Rust или Go нет исключений, то немного лукавят. В техническом плане паника - это те самые исключения. Разве что немного менее удобные так как сахара для обработки не завезли. Честнее было бы говорить, что строить логику обработки ошибок на паниках не принято. И что характерно рекомендации работают. По крайней мере, я не наблюдаю обратного.

с одной стороны, идеология раста вдалбливает вам, что "исключения - это плохо потому, что потому", а с другой стороны, крутиться как-то надо

Ну так можно показать эту другую сторону? Ту самую, где двуличные растоманы повсеместно используют панику как исключения.

человек выше рекомендовал мне "не мучать себя растом", что ж, я так и делаю, и только рад этому.

Осталось сделать следующий шаг и не читать темы про раст. Может быть тогда фанатики перестанут мерещиться.

Тем не менее такая практика распространена достаточно широко для того, чтобы о ней не поленились упомянуть в официальной документации, пусть и в стиле "not recommended".

Такая формулировка была с момента появления/стабилизации данной функции, так что нет. Или может есть пруфы, что catch_unwind действительно лепят везде?

Звучит как как проблема нового инструмента. В других языках ведь тоже приходится постоянно принимать решения как правильно сделать. Просто когда это уже привычно, то на это тратится меньше времени.

Это главная причина, почему я не люблю раст - приходится думать не над задачей, а над тем, можно ли победить в данной ситуации borrow checker, и если можно, то как.

Ну а это скорее следствие относительной низкоуровневости языка. Если хочется максимально на предметной области сосредоточиться, то язык GC всегда будет лучше так как позволяет игнорировать разные "мелочи". Так-то в С(++) тоже приходится много в голове держать, просто компилятор не бьёт по рукам.

Может да, может нет, если дефолтные настройки удачнее выбраны.

Когда настолько возрастёт, у вас там вы и так бабло будете лопатами в вёдра складывать, с нуля заново перепишете.

Не цеплять сторонние библиотеки, из которых вам надо две-три строчки кода. И даже пять строчек кода.

Вижу здесь противоречие. Если мы хотим как можно сильнее ускорить написание первой версии, но брать библиотеки выгоднее. А уж потом если проект выстрелит и библиотека помрёт, то можно будет писать свой велосипед.

А в чём проблема использовать немного unsafe при необходимости? В реализации на С ведь будет то же самое только неявно.

Информация

В рейтинге
5 056-й
Дата рождения
Зарегистрирован
Активность