Rust изначально создавался как замена C++, решающая его фундаментальные проблемы. Делали его люди, у которых, что называется, накипело. ИМХО ещё мало сравнивают их, сейчас никакого анти-плюсового напора со стороны разработчиков и спонсоров Rust вообще нет практически. А вы всё жалуетесь.
Не факт, что текучка - проблема компании. Это сотрудники могут думать, что текучка - это проблема компании и что опытные старожилы должны на что-то претендовать. Вот и предлагают разное, как снизить текучку и поощрить стариков. Понятно, что компании не это нужно.
У меня похожие идеи вылились в разработку приложения Laplace - платформы для запуска локально-ориентированных веб-приложений: https://github.com/noogen-projects/laplace
Есть бизнесс, а есть работа по созданию нового и лучшего. Понятно, что геймдев экосистема в Rust на голову проигрывает экосистеме C++ и C#. Если вас интересует именно бизнесс и прямо сейчас - кажется, Rust будет не очень хорошим выбором. Это сегодня. А завтра ситуация вполне может измениться на противоположную. Благодаря тем, кто делает не деньги, а дело, кто работает не ради сиюминутной выгоды, а добивается стратегического превосходства. Каждому своё.
Самая фундаментальная проблема заключается в том, что borrow checker вынуждает выполнять рефакторинг в самые неудобные моменты. Разработчики на Rust считают это положительным моментом, потому что это заставляет их «писать хороший код», но чем больше я работаю с языком, тем сильнее сомневаюсь, что это так. Хороший код пишется благодаря итеративной работе с идеями и экспериментам, и хотя borrow checker может заставить увеличить количество итераций, это не означает, что таков желательный способ написания кода. Часто я обнаруживал, что именно невозможность просто пойти дальше, решить свою задачу, а проблему устранить позже, мешает писать хороший код.
Людям, привыкшим к REPL, действительно, бывает сложно не то что использовать Rust, а вообще использовать любой компилируемый язык программирования со статической типизацией. Ну вот не могут они выражать свои идеи в типах и получать обратную связь от компилятора, им обязательно нужно пихнуть результат в строку и распечатать.
Если человек не хочет отказываться от привычного REPL, то ему действительно будет нелегко программировать на Rust. Есть ли области применения, для которых хорошо подходит только такой стиль? Может быть это геймдев, я не настолько опытный в нём, чтобы спорить с автором статьи. Пока то, что я вижу в околоигровой экосистеме раста - это разработка как статического, так и динамического инструментария. Предполагаю, что там делается попытка научиться использовать оба подхода.
То, что Rust прекрасен в рефакторинге, в основном решает его собственные проблемы с borrow checker
А вот и нет. Проблемы с borrow checker на 90% уходят по мере привыкания к нему. А вот то, что Rust прекрасен в рефакторинге, позволяет с меньшими усилиями развивать быстро меняющийся проект. Я на практике в этом убедился: Rust лучше, чем другие популярные языки подходит для "выращивания" проекта, создания MVP и далее его развития малыми силами.
На других языках можно писать код с мыслью «потом я это выкину»; для меня это один из самых полезных подходов для создания хорошего кода.
Вот именно! С иллюзорной мыслью «потом я это выкину»: чаще всего код не выкидывается, а встраивается в проект, особо не меняясь. И тут как раз преимущество Rust в том, что он позволяет управлять гораздо большим проектом, гораздо большей сложностью меньшими силами. Преимущество его строгости, а также экономия сил и времени проявляются не в моменте, а в процессе роста проекта.
Неа. Государство - это "комитет по делам корпораций". А если оно само становится корпорацией, то обретает собственный частный интерес, также оторванный от интересов общества. Потому что использует тот же способ производства, что и другие, основанный на частном интересе.
Для прототипирования - да, будет мешать (если подразумевается выбрасывание прототипа). А вот для "выращивания" проекта, создания MVP с дальнейшей доработкой - подойдёт хорошо.
Я думаю в этой цитате автор статьи говорит о себе самом: это он поддался влиянию и не разобравшись выбрал Rust, когда для его задач и стиля работы он не подходит. Конечно, спустя годы тщетных попыток поменять под себя Rust, он теперь обижен.
P. S. Я более пяти лет профессионально разрабатываю на Rust, поэтому думаю, что имею право полемизировать с автором статьи, особенно в общеязыковых вопросах, а не специфически игровых (хотя тот же Bevy я использовал и свой собственный GUI на Rust писал).
Должна существовать мощная "корпорация", главные интересы которой должны совпадать с интересами благополучия и развития общества. Конкуренция между компаниями со своими собственными, частными интересами, толку никакого не даст.
Как вообще может возникнуть и существовать такая "корпорация"? В рамках капитализма - никак. Только сбоку, в нетоварном сегменте экономики, как следствие развития нового способа производства и новых принципов вовлечения людей в управление.
Можно открыть и самому проверить эти места. Что-то я из своей практики не припоминаю проблем с unsafe в зависимостях. В основном все стремятся минимизировать число использований unsafe в своих библиотеках.
Почему мне не сложно читать код библиотек на Rust? Я профессионально программирую на Rust уже более 5 лет. Но даже в первый год его изучения я прочитал СТОЛЬКО чужого кода в библиотеках, сколько не читал за предыдущие 10 лет. Так что не спешите обобщать свои выводы на всех.
Ну, Роскосмос всёж-таки шевелится, но как-то уж медленно. Подозреваю, что дело не в деньгах. Нужна свежая кровь.
Rust изначально создавался как замена C++, решающая его фундаментальные проблемы. Делали его люди, у которых, что называется, накипело. ИМХО ещё мало сравнивают их, сейчас никакого анти-плюсового напора со стороны разработчиков и спонсоров Rust вообще нет практически. А вы всё жалуетесь.
По-моему вы преувеличиваете. Через пару месяцев практики я принципиально не чувствовал отличий в написании бекэнда на Rust в сравнении с Java.
Не факт, что текучка - проблема компании. Это сотрудники могут думать, что текучка - это проблема компании и что опытные старожилы должны на что-то претендовать. Вот и предлагают разное, как снизить текучку и поощрить стариков. Понятно, что компании не это нужно.
У меня похожие идеи вылились в разработку приложения Laplace - платформы для запуска локально-ориентированных веб-приложений: https://github.com/noogen-projects/laplace
Мы с вами точно одну и ту же статью читали?
В том, что это не решает исходную проблему текучки в компании, а наоборот, её усугубляет.
Есть бизнесс, а есть работа по созданию нового и лучшего. Понятно, что геймдев экосистема в Rust на голову проигрывает экосистеме C++ и C#. Если вас интересует именно бизнесс и прямо сейчас - кажется, Rust будет не очень хорошим выбором. Это сегодня. А завтра ситуация вполне может измениться на противоположную. Благодаря тем, кто делает не деньги, а дело, кто работает не ради сиюминутной выгоды, а добивается стратегического превосходства. Каждому своё.
Людям, привыкшим к REPL, действительно, бывает сложно не то что использовать Rust, а вообще использовать любой компилируемый язык программирования со статической типизацией. Ну вот не могут они выражать свои идеи в типах и получать обратную связь от компилятора, им обязательно нужно пихнуть результат в строку и распечатать.
Если человек не хочет отказываться от привычного REPL, то ему действительно будет нелегко программировать на Rust. Есть ли области применения, для которых хорошо подходит только такой стиль? Может быть это геймдев, я не настолько опытный в нём, чтобы спорить с автором статьи. Пока то, что я вижу в околоигровой экосистеме раста - это разработка как статического, так и динамического инструментария. Предполагаю, что там делается попытка научиться использовать оба подхода.
А вот и нет. Проблемы с borrow checker на 90% уходят по мере привыкания к нему. А вот то, что Rust прекрасен в рефакторинге, позволяет с меньшими усилиями развивать быстро меняющийся проект. Я на практике в этом убедился: Rust лучше, чем другие популярные языки подходит для "выращивания" проекта, создания MVP и далее его развития малыми силами.
Вот именно! С иллюзорной мыслью «потом я это выкину»: чаще всего код не выкидывается, а встраивается в проект, особо не меняясь. И тут как раз преимущество Rust в том, что он позволяет управлять гораздо большим проектом, гораздо большей сложностью меньшими силами. Преимущество его строгости, а также экономия сил и времени проявляются не в моменте, а в процессе роста проекта.
Так как речь про Unity, то полагаю, что на C#.
Это нужно их спрашивать, самих людей, в чём их интерес. Проблема в том, что их об этом не спрашивают.
Неа. Государство - это "комитет по делам корпораций". А если оно само становится корпорацией, то обретает собственный частный интерес, также оторванный от интересов общества. Потому что использует тот же способ производства, что и другие, основанный на частном интересе.
Для прототипирования - да, будет мешать (если подразумевается выбрасывание прототипа). А вот для "выращивания" проекта, создания MVP с дальнейшей доработкой - подойдёт хорошо.
Я думаю в этой цитате автор статьи говорит о себе самом: это он поддался влиянию и не разобравшись выбрал Rust, когда для его задач и стиля работы он не подходит. Конечно, спустя годы тщетных попыток поменять под себя Rust, он теперь обижен.
P. S. Я более пяти лет профессионально разрабатываю на Rust, поэтому думаю, что имею право полемизировать с автором статьи, особенно в общеязыковых вопросах, а не специфически игровых (хотя тот же Bevy я использовал и свой собственный GUI на Rust писал).
Должна существовать мощная "корпорация", главные интересы которой должны совпадать с интересами благополучия и развития общества. Конкуренция между компаниями со своими собственными, частными интересами, толку никакого не даст.
Как вообще может возникнуть и существовать такая "корпорация"? В рамках капитализма - никак. Только сбоку, в нетоварном сегменте экономики, как следствие развития нового способа производства и новых принципов вовлечения людей в управление.
И где же она его "отрыла"? )
Можно открыть и самому проверить эти места. Что-то я из своей практики не припоминаю проблем с unsafe в зависимостях. В основном все стремятся минимизировать число использований unsafe в своих библиотеках.
Почему мне не сложно читать код библиотек на Rust? Я профессионально программирую на Rust уже более 5 лет. Но даже в первый год его изучения я прочитал СТОЛЬКО чужого кода в библиотеках, сколько не читал за предыдущие 10 лет. Так что не спешите обобщать свои выводы на всех.
Вам кажется