Как это ни удивительно, но да, вполне может быть. У меня VS Code значительно быстрее индексирует проект и не зависает на одном большом воркспейсе, на котором виснет IntelliJ IDEA. И дело тут, похоже, не в JS vs. Java, а в реализованных алгоритмах работы.
А почему бы и не уйти? Я тоже к VS Code скептически относился, а потом JB объявили, что не будут поддерживать Rust-plugin, а RustRover опенсорсить планов у них нет... Ну и "до свидания" тогда. В VS Code оказалось, что rust-analyzer получше работает, и среда справляется с большими проектами, на которых IDEA зависала. Ну и набор плагинов радует, типа VS Code Speech и Codeium - продуктивность разработки подросла.
Хочу добавить, что многословность кода ведёт и к его усложнению. Приходится сосредотачиваться на чтении "лапши" даже в довольно простых для "богатых" языков случаях. Я думаю никого не нужно убеждать в том, что программу на ассемблере будет сложнее и писать, и читать, чем программу на Си, хотя языки ассемблера очень простые. Бедность языка приводит к тому, что сложную программу приходится выражать в сложном нагромождении простых конструкций, вместо того, чтобы выразить в простом наборе сложных, как это можно сделать в богатых языках.
А что в этом было хорошего? Небрежно изготовленные консервы могут привести к появлению этих бактерий с последующим отравлением. Мои родители, в те времена, когда ещё про компьютеры не знали и жили в деревне, всегда очень тщательно готовили консервы, чтобы не дай Бог.
Вы до сих пор не выделили. Имейте совесть, не распространяйте такую лютую и откровенную дичь про сообщество. Потом же к нам все эти люди приходят (или не приходят) и предъявляют, начитавшись таких "шутников" как вы.
Спасибо, что ваша компания решила выложить в общий доступ исходники Greenplum и свои наработки вокруг него.
Сейчас из-за закрытия апстрима многие пользователи дезориентированы. У нас тут образовалась небольшая инициативная группа по организации форка Greenplum, мы ведём переговоры с компаниями о возможном их участии в развитии форка. Было бы здорово, если бы вы тоже присоединились!
Не факт, что текучка - проблема компании. Это сотрудники могут думать, что текучка - это проблема компании и что опытные старожилы должны на что-то претендовать. Вот и предлагают разное, как снизить текучку и поощрить стариков. Понятно, что компании не это нужно.
У меня похожие идеи вылились в разработку приложения Laplace - платформы для запуска локально-ориентированных веб-приложений: https://github.com/noogen-projects/laplace
Есть бизнесс, а есть работа по созданию нового и лучшего. Понятно, что геймдев экосистема в Rust на голову проигрывает экосистеме C++ и C#. Если вас интересует именно бизнесс и прямо сейчас - кажется, Rust будет не очень хорошим выбором. Это сегодня. А завтра ситуация вполне может измениться на противоположную. Благодаря тем, кто делает не деньги, а дело, кто работает не ради сиюминутной выгоды, а добивается стратегического превосходства. Каждому своё.
Самая фундаментальная проблема заключается в том, что borrow checker вынуждает выполнять рефакторинг в самые неудобные моменты. Разработчики на Rust считают это положительным моментом, потому что это заставляет их «писать хороший код», но чем больше я работаю с языком, тем сильнее сомневаюсь, что это так. Хороший код пишется благодаря итеративной работе с идеями и экспериментам, и хотя borrow checker может заставить увеличить количество итераций, это не означает, что таков желательный способ написания кода. Часто я обнаруживал, что именно невозможность просто пойти дальше, решить свою задачу, а проблему устранить позже, мешает писать хороший код.
Людям, привыкшим к REPL, действительно, бывает сложно не то что использовать Rust, а вообще использовать любой компилируемый язык программирования со статической типизацией. Ну вот не могут они выражать свои идеи в типах и получать обратную связь от компилятора, им обязательно нужно пихнуть результат в строку и распечатать.
Если человек не хочет отказываться от привычного REPL, то ему действительно будет нелегко программировать на Rust. Есть ли области применения, для которых хорошо подходит только такой стиль? Может быть это геймдев, я не настолько опытный в нём, чтобы спорить с автором статьи. Пока то, что я вижу в околоигровой экосистеме раста - это разработка как статического, так и динамического инструментария. Предполагаю, что там делается попытка научиться использовать оба подхода.
Но по сути-то верно: дорожка закручена винтом...
Делают. Причём бесплатно: носят на себе одежду с изображением бренда.
Этот код выглядит как г..но не потому, что открывающая скобка не перенесена на новую строку, а потому, что вы убрали все пробелы перед/после скобочек.
А вообще, как уже сказали, принятый на проекте единый стиль форматирования + автоформаттер у всех решает проблему.
Как это ни удивительно, но да, вполне может быть. У меня VS Code значительно быстрее индексирует проект и не зависает на одном большом воркспейсе, на котором виснет IntelliJ IDEA. И дело тут, похоже, не в JS vs. Java, а в реализованных алгоритмах работы.
Как я понял, это решение - проприетарное. А значит аналогом GitLab не является.
А почему бы и не уйти? Я тоже к VS Code скептически относился, а потом JB объявили, что не будут поддерживать Rust-plugin, а RustRover опенсорсить планов у них нет... Ну и "до свидания" тогда. В VS Code оказалось, что rust-analyzer получше работает, и среда справляется с большими проектами, на которых IDEA зависала. Ну и набор плагинов радует, типа VS Code Speech и Codeium - продуктивность разработки подросла.
Хочу добавить, что многословность кода ведёт и к его усложнению. Приходится сосредотачиваться на чтении "лапши" даже в довольно простых для "богатых" языков случаях. Я думаю никого не нужно убеждать в том, что программу на ассемблере будет сложнее и писать, и читать, чем программу на Си, хотя языки ассемблера очень простые. Бедность языка приводит к тому, что сложную программу приходится выражать в сложном нагромождении простых конструкций, вместо того, чтобы выразить в простом наборе сложных, как это можно сделать в богатых языках.
А что в этом было хорошего? Небрежно изготовленные консервы могут привести к появлению этих бактерий с последующим отравлением. Мои родители, в те времена, когда ещё про компьютеры не знали и жили в деревне, всегда очень тщательно готовили консервы, чтобы не дай Бог.
Вы до сих пор не выделили. Имейте совесть, не распространяйте такую лютую и откровенную дичь про сообщество. Потом же к нам все эти люди приходят (или не приходят) и предъявляют, начитавшись таких "шутников" как вы.
Для Rust в любом случае лучше ставить компилятор через rustup.
Спасибо, что ваша компания решила выложить в общий доступ исходники Greenplum и свои наработки вокруг него.
Сейчас из-за закрытия апстрима многие пользователи дезориентированы. У нас тут образовалась небольшая инициативная группа по организации форка Greenplum, мы ведём переговоры с компаниями о возможном их участии в развитии форка. Было бы здорово, если бы вы тоже присоединились!
Ссылка на группу в Телеграмме "Развитие форка Greenplum": https://t.me/+epF0slohPBNmODdi
А что нужно?
Деплой в прод лучше не называть выбрасыванием на свалку... Даже если по-факту так и есть )
Ну, Роскосмос всёж-таки шевелится, но как-то уж медленно. Подозреваю, что дело не в деньгах. Нужна свежая кровь.
Не факт, что текучка - проблема компании. Это сотрудники могут думать, что текучка - это проблема компании и что опытные старожилы должны на что-то претендовать. Вот и предлагают разное, как снизить текучку и поощрить стариков. Понятно, что компании не это нужно.
У меня похожие идеи вылились в разработку приложения Laplace - платформы для запуска локально-ориентированных веб-приложений: https://github.com/noogen-projects/laplace
Мы с вами точно одну и ту же статью читали?
В том, что это не решает исходную проблему текучки в компании, а наоборот, её усугубляет.
Есть бизнесс, а есть работа по созданию нового и лучшего. Понятно, что геймдев экосистема в Rust на голову проигрывает экосистеме C++ и C#. Если вас интересует именно бизнесс и прямо сейчас - кажется, Rust будет не очень хорошим выбором. Это сегодня. А завтра ситуация вполне может измениться на противоположную. Благодаря тем, кто делает не деньги, а дело, кто работает не ради сиюминутной выгоды, а добивается стратегического превосходства. Каждому своё.
Людям, привыкшим к REPL, действительно, бывает сложно не то что использовать Rust, а вообще использовать любой компилируемый язык программирования со статической типизацией. Ну вот не могут они выражать свои идеи в типах и получать обратную связь от компилятора, им обязательно нужно пихнуть результат в строку и распечатать.
Если человек не хочет отказываться от привычного REPL, то ему действительно будет нелегко программировать на Rust. Есть ли области применения, для которых хорошо подходит только такой стиль? Может быть это геймдев, я не настолько опытный в нём, чтобы спорить с автором статьи. Пока то, что я вижу в околоигровой экосистеме раста - это разработка как статического, так и динамического инструментария. Предполагаю, что там делается попытка научиться использовать оба подхода.