Я на 99% уверен, что люди пишущие на статически типизированных языках поняли этот вопрос сильно по-разному. Насколько ценно моё мнение? Да примерно как этот опрос. Ну и я вижу, что ты не намерен дискутировать или что-то прояснить, а только спорить по удобным тебе моментам, обходя неудобные.
Так ведь это ничего не доказывает. Ну и у ошибок сильно разная цена. Одно дело когда проблема ловится прям сразу компилятором - это просто исправляется мимоходом и всё (хотя и тут бывают особые случаи), другое дело - если проблему поймали тестами и третье если ошибка дошла до пользователей.
Честно говоря, не понял мысль. У меня следующая точка зрения: в строго типизированных языках ситуации когда компилятор бьёт по рукам при попытке сложить строку с числом или передать обычную строку вместо конкретного типа имеющего смысл в нашем домене (пусть будет банальный юзер-нейм) естественно случаются. Но у меня есть большие сомнения, что люди приравнивают эти ошибки, которые, как и прочие ошибки компиляции (вроде незакрытой скобки или забытой точки с запятой), возникают по 100 раз на день, к настоящим багам. Лично я воспринимаю эти вещи как нечто совершенно разное.
Добро пожаловать в ад автосгенерированной документации! Rust-крейты похожи на налоговые кодексы: .. Где примеры? Зарыты где-то между #[derive(Debug)] и impl FromStr. Чтобы понять, как использовать функцию, вам понадобится докторская степень по расшифровке типов.
Ну зачем так нагло врать-то? Смотрю на документацию parse и на описание трейтаFromStr - и там и там примеры есть. Более того, описывать входные параметры и результат в расте не принято. Как раз потому, что мы видим тип, на которой можно нажать и перейти, если что-то не понятно. А "input - входная строка" для параметра типа input: &str писать как-то бессмысленно.
такой кейз не невозможный, но редкий (доказательство - результаты первого опроса под статьёй)
Вот я пишу на языке с типами и на проекте принято использовать "strong typedefs". И как мне голосовать, если ошибки типов не доходят до тестирования и тем более пользователей, но именно благодаря языку и нашим усилиям?
GUI в расте нормально (в продакшене) не щупал, поэтому спорить не буду. Хотя мне кажется, что GUI в целом чаще в виде фреймворков реализован. Ну а касательно тоника - коммуникация через каналы кажется вполне себе прямым способом, а не костылём.
Мне кажется, что выборка специфическая. Я не придираюсь, скорее любопытно. Можно список, скажем, из десяти таких библиотек? По моему, это справедливо для веб-фреймворков, но зачем иметь несколько в одной кодовой базе? Ещё можно про асинхронные рантаймы и то практически все используют токио и не парятся.
Так я же не спорю с претензиями к языку. Автор оригинальной статьи поделился ценным опытом, можно быть в чём-то не согласным, но мнение в любом случае полезно. Но после вот этой цитаты:
Ну человек прав в том, что все rust комьюнити этого не понимает. То есть они пытаются писать движки вместо игр
Мне показалось, что мы обсуждаем конкретно то, что движки делают "не так как надо". Вот и высказался, что пока этим занимаются несколько энтузиастов в свободное время, то такие претензии не совсем по адресу.
Подозреваю, что большинству из тех, кто пилит движки (тот же беви) интересно как раз пилить движок. Учитывая, что это всё делается на добровольных началах, то странно предъявлять претензии к тому как люди тратят своё свободное время.
Да, было бы неплохо, если появился бы конкурент коммерческим движкам на расте, но я не уверен, что есть смысл это требовать от кучки энтузиастов.
Вместо следования semver (что вообще-то является обязательным для проектов cargo, т.к. именно так cargo обрабатывает поле version), автор наперекор всем делает ломающие изменения в патчах
А разве это именно ломающее изменение? Вроде, же просто расширение апи? Ну то есть формально да, это нарушение семвер, но не кажется прям большой проблемой. Ну и если бы у серде стали мажорную версию инкрементировать, то больно стало бы всем.
Ну а так-то чувак тащит на себе кучу крейтов. Ожидаемо на всё времени не хватает, но да, меня тоже расстраивает, что "делиться ответственностью" он не спешит.
Дык, в С++ множество WTF моментов вызваны как раз синтаксисом, который вынужден быть таким из-за совместимости. А это в расте можно понемногу изменять.
Нытьё про хайп тоже. Такая реакция понятна когда расто-фанатики приходят с агитацией в тему про С++. Но тут-то это причём? Новость вполне интересная: показывает и интерес от гугла и любопытно будет посмотреть на результаты.
В комментарии выше не раст.
Я на 99% уверен, что люди пишущие на статически типизированных языках поняли этот вопрос сильно по-разному. Насколько ценно моё мнение? Да примерно как этот опрос. Ну и я вижу, что ты не намерен дискутировать или что-то прояснить, а только спорить по удобным тебе моментам, обходя неудобные.
Так ведь это ничего не доказывает. Ну и у ошибок сильно разная цена. Одно дело когда проблема ловится прям сразу компилятором - это просто исправляется мимоходом и всё (хотя и тут бывают особые случаи), другое дело - если проблему поймали тестами и третье если ошибка дошла до пользователей.
Честно говоря, не понял мысль. У меня следующая точка зрения: в строго типизированных языках ситуации когда компилятор бьёт по рукам при попытке сложить строку с числом или передать обычную строку вместо конкретного типа имеющего смысл в нашем домене (пусть будет банальный юзер-нейм) естественно случаются. Но у меня есть большие сомнения, что люди приравнивают эти ошибки, которые, как и прочие ошибки компиляции (вроде незакрытой скобки или забытой точки с запятой), возникают по 100 раз на день, к настоящим багам. Лично я воспринимаю эти вещи как нечто совершенно разное.
Ну зачем так нагло врать-то? Смотрю на документацию
parseи на описание трейтаFromStr- и там и там примеры есть. Более того, описывать входные параметры и результат в расте не принято. Как раз потому, что мы видим тип, на которой можно нажать и перейти, если что-то не понятно. А "input - входная строка" для параметра типаinput: &strписать как-то бессмысленно.Вот я пишу на языке с типами и на проекте принято использовать "strong typedefs". И как мне голосовать, если ошибки типов не доходят до тестирования и тем более пользователей, но именно благодаря языку и нашим усилиям?
GUI в расте нормально (в продакшене) не щупал, поэтому спорить не буду. Хотя мне кажется, что GUI в целом чаще в виде фреймворков реализован. Ну а касательно тоника - коммуникация через каналы кажется вполне себе прямым способом, а не костылём.
Мне кажется, что выборка специфическая. Я не придираюсь, скорее любопытно. Можно список, скажем, из десяти таких библиотек? По моему, это справедливо для веб-фреймворков, но зачем иметь несколько в одной кодовой базе? Ещё можно про асинхронные рантаймы и то практически все используют токио и не парятся.
Так я же не спорю с претензиями к языку. Автор оригинальной статьи поделился ценным опытом, можно быть в чём-то не согласным, но мнение в любом случае полезно. Но после вот этой цитаты:
Мне показалось, что мы обсуждаем конкретно то, что движки делают "не так как надо". Вот и высказался, что пока этим занимаются несколько энтузиастов в свободное время, то такие претензии не совсем по адресу.
Подозреваю, что большинству из тех, кто пилит движки (тот же беви) интересно как раз пилить движок. Учитывая, что это всё делается на добровольных началах, то странно предъявлять претензии к тому как люди тратят своё свободное время.
Да, было бы неплохо, если появился бы конкурент коммерческим движкам на расте, но я не уверен, что есть смысл это требовать от кучки энтузиастов.
А разве это именно ломающее изменение? Вроде, же просто расширение апи? Ну то есть формально да, это нарушение семвер, но не кажется прям большой проблемой. Ну и если бы у серде стали мажорную версию инкрементировать, то больно стало бы всем.
Ну а так-то чувак тащит на себе кучу крейтов. Ожидаемо на всё времени не хватает, но да, меня тоже расстраивает, что "делиться ответственностью" он не спешит.
Предположу, что человека смущает слишком яркая "титульная" картинка проекта.
Yвеличение времени компиляции и IDE с макросами не очень хорошо работают. Хотя в данном случае мне кажется, что от этого никуда не деться.
abi_stable
Дык, в С++ множество WTF моментов вызваны как раз синтаксисом, который вынужден быть таким из-за совместимости. А это в расте можно понемногу изменять.
Разве это правда? По моему, данный жанр определяется походовостью, процедурной генерацией уровней и окончательной смертью.
По моему, rougelike тут используется как синоним убогой игры. Миллионы кабанов - это скорее про ммо.
Это не в защиту смуты, просто не понятно чем совсем жанр провинился, который тут и рядом не стоял.
А что не так с именованием?
Раст всё-таки достаточно низкоуровневый, переходить на него с языков со сборкой мусора есть смысл только если есть понимание зачем.
Нытьё про хайп тоже. Такая реакция понятна когда расто-фанатики приходят с агитацией в тему про С++. Но тут-то это причём? Новость вполне интересная: показывает и интерес от гугла и любопытно будет посмотреть на результаты.
И тем не менее такой стиль часто встречается. Мне лично с
mod.rsтоже больше нравится.Если человек лепит проверки наугад, то шанс, что он забудет что-то "критически важное" наоборот повышается. Ну и плюс мусорный код затрудняет чтение.