"Простые люди" в данном случае - это не читатели научной литературы подразумеваются. Я-кать в письменной форме - зачастую не лучший вариант, согласен. Поэтому обезличенные обращения - рабочий выход, на мой взгляд. Но опять же - это особенности стилистики текста. Пишите как Вам удобно и привычно - в этом проблемы нет.
Про "мы" вопрос даже не к стилистике был, а чтобы понять "а кто такой автор статьи и с какой позиции эту статью следует рассматривать". Все-таки одно дело - личные впечатления о продукте, другое - статья в корпоративном блоге (или статья о своем же продукте).
Эм... В научных работах возможно так и принято (но в них и понятен контекст для местоимения). А в статьях "для простых людей", на мой взгляд, должно более прозрачно прослеживаться местоимение из контекста, или вообще использоваться обезличенные выражения. Но да ладно, это так, скорее придирка была - особенность стилистики текста.
Я согласен, что тут туториал среднего уровня - быстро прочитал и в закладки (если надо, скорее всего, потом через поиск материал искаться будет). Но это справедливо только для людей "сильно в теме". И на узкоспециализированном профильном ресурсе - я бы сказал "ОК, нет вопросов". Или для документации EDK II / Tianocore - отличная статья, спору нет.
Но в данном случае, для хабра... Не знаю, не знаю... Лично для меня, сработало введение - привлекло внимание, заставило пройти под кат... Интересно стало что за зверь такой "Orange Pi 5" и с чем его едят... А внутри - просто инструкция "как установить EDK II" из множества консольных команд. Которые дают дают пример "как это сделать", но не дают понимания "что мы делаем" и "зачем мы это делаем".
И речь не о технических характеристиках (хотя и они были бы не лишними, если не хотите загромождать статью - их можно убрать под спойлер). Я именно про описание решаемой проблемы, подхода к решению проблемы и т.д. Тут достаточно было бы одного-двух предложений (или абзацев) просто для погружения в контекст.
Нас заинтересовал первый образец серии 5/5B/5+, а именно Orange Pi 5, на предмет того, как на данном устройстве поведет себя EDK II и можно ли его использовать так, как мы привыкли работать с обычными ПК.
Кто такие "мы"? Статья в личном блоге, а не в корпоративном.
Что такое EDK II, зачем он нужен и какие проблемы решает?
Аналогично и с toolchain - начинаем установку с него, но для чего он нужен - непонятно.
И в конце-концов, так и не раскрыта тема - можно ли использовать Orange Pi 5 в роли обычного ПК, как мы привыкли работать с обычными ПК? Самый интересный вопрос на самом деле...
Я скорее к тому, что в ситуации "на все публичное надо писать доки" и "не нужны доки на тесты" есть очень простой выход - не делать тесты публичными классами.
И принцип не нарушается и доки на тесты не надо писать.
Иногда для тестов делается определенный тулчейн, например подменяющий "родные" механики - и этот тулчейн хорошо бы задокументировать (особенно если он часто в тестах используется). А как известно, если доки нужно писать, но можно не писать - то доки не будут писать. И с этим статический анализатор может помочь. Но только в том случае, если анализатор не игнорит все, что в тестах происходит.
Отдельно хотелось бы отметить требование писать документацию на всё публичное – все публичные классы и методы. Это требование кажется логичным, если бы не одно “но”. Юнит-тесты тоже публичные, каждый тест публичный.
jUnit позволяет использовать package-private тестовые классы и методы (т.е. без модификатора доступа).
Согласен. Но я бы не прочь увидеть и специально подобранный пример, где эти заявления более-менее выполняются. Правда именно грамотный пример хотел бы увидеть - скажем, сравнение с alpine-образом и с примерно одинаковыми параметрами компиляции приложения.
Compared with Linux containers, WasmEdge could be 100x faster at start-up and 20% faster at runtime.
A WasmEdge app could take 1/100 of the size of a similar Linux container app.
Заявления с сайта wasmedge. Впрочем, объективность подобных заявлений под большим вопросом. Ни примеров, ни методики измерения не указано.
Максимум - готов поверить, что такие приложения могут занимать значительно меньше места. Впрочем, образы на базе alpine тоже занимают значительно меньше места относительно прочих образов, так что и тут остается открытым вопрос - с чем и как сравнивали.
Лично я считаю - что определенные проблемы у Rust в плане сложности есть. Вы говорите - что не так все плохо. Должен сказать, что эти две позиции ни капли не противоречат друг другу.
Опыт, практика - имеют значение в любом языке и/или стеке технологий. Где-то больше, где-то меньше, только и всего.
По моему, мы уже N комментариев только и говорим, что о том как влияет навороченность языка на (не)очевидность кода. (:
Я тут имел в виду, что запутанный код - явление есть везде и всегда как фактор развития кодовой базы проекта. И язык, в идеале, своими конструкциями, не должен добавлять дополнительных сложностей в читаемость кода.
Выше не стал спорить с этим утверждением, а вот сейчас не удержусь: мне JavaScript простым не кажется.
Именно основы языка, его концепции очень простые (и, на удивление, лаконичные). Немного сложностей в плане ООП, но это все из серии "изучить нюансы и запомнить".
Лично мне в JS не нравится два фактора:
Динамическиая типизация - плохо работает IDE, много ошибок всплывает в рантайме (впрочем, тут спасет TypeScript).
Но TypeScript - это скорее C#, от JavaScript осталось очень мало.
Инфраструктура. Все очень быстро меняется, много кода низкого качества и сама по себе инфраструктура стала очень самобытной (тут TypeScript уже не спасает). Для изучения/погружения требуется очень много времени и сил, а знания очень быстро устаревают.
Для "быстро написать/переписать" раст уж точно не лучший выбор.
Если цель - написать сервис, то лучше привычные инструменты использовать, тут вопросов нет. А если цель - изучить Rust (и оценить его пригодность для других проектов), то вполне рабочий подход. Правда времени займет много (что на изучение Rust, что на использование в первое время).
А я наоборот считаю, что чем больше проект, тем важнее становятся инструменты абстрагирования и сильная/навороченная типизация.
В больших проектах, в больших командах - очень важен фактор читаемости кода. Если все в команде "собаку съели на Rust" - то это один вопрос. Впрочем, опять же, от проекта сильно зависит. Если для веб-сервиса выбор Rust - достаточно специфичный случай (потому как много альтернатив), то для написания прошивки выбор уже не столь неоднозначный (потому как безопасность решает).
И другой фактор, который лично мне не дает рекомендовать Rust для больших проектов - фактор поддерживаемости инфраструктуры. Rust сейчас очень быстро развивается. А это означает, что часто будут возникать проблемы с обновлением зависимостей (а для исправления нужно очень много трудозатрат). Или код сразу после написания будет устаревшим из-за использования устаревших либ (и устаревшей редакции языка).
SQLx. Ну и я всё-таки считаю, что проверка запросов на этапе компиляции того стоит. Кстати, в ридми написано "Compile-time checked queries (if you want)".
Полезная фича, но сорцы начинают зависеть и от схемы в БД, и от используемой СУБД. Будь это чистой кодогенерацией: подключился к БД - нагенерил код - используешь. Я бы сказал - да, мега-фича (особенно если опционально). Но в режиме постоянного подключения - скорее вызывает неудобство. Это может быть удобно в случае, если ты один работаешь надо "домашним" проектом, не заморачиваясь ни версионностью БД, ни CI/CD, ни сборкой Docker-образов и т.д. Подправил БД - подправил запросы - работаешь дальше. А в командной разработке, особенно если БД активно развивается - лучше не надо.
Справедливости ради, на днях обнаружил, что у sqlx есть "Offline Mode" - можно выгрузить представление БД в виде JSON, и если DATABASE_URL в env не задано, то будет использоваться этот файл. Что позволяет успешно работать с проектом без постоянного подключения к БД. И в релизе 0.7 (который сейчас готовится) работа в Offline Mode становится приоритетным подходом, что, на мой взгляд, абсолютно оправдано.
Скажем, хаскель мне достаточно интересен и симпатичен, но я его толком не знаю.
Хаскель помимо активной практики требует и определенного, как бы сказать, состояния разума. И мне удалось это состояние поймать во время обучения в универе. Но это было уже очень давно и текущего опыт разработки у меня еще не было, чтобы адекватно оценить этот опыт. Общее впечатление - да, мне понравилось, было очень интересно. Но понимание хаскеля быстро ушло - сказалось отсутствие практики.
Но если взять обычного сишника или джависта, то "взглянул и сразу понял" и близко не будет. И в рамках этого языка тоже есть продвинутые штуки для которых нужно ещё более углубленное знакомство.
Тут больший вопрос, что это принципиально разные парадигмы программирования. Языки чисто функционального программирования и языки с элементами функционального программирования - это очень большая разница просто в подходах к программированию.
А запутанный код можно писать и городя упоротые иерархии наследования и даже в процедурном стиле.
Запутанный код - это результат в первую очередь истории развития кода и навыков разработчика. Никогда не видел, чтобы специально писали запутанный код. Влияние именно языка тут достаточно вторично.
Думаю мы оба согласны с тем, что больше гибкости — больше возможных проблем. Просто я считаю, что преимущества перевешивают эти потенциальные проблемы.
Да, больше гибкости - больше проблем, с этим сложно спорить. Но тут вопрос не только в гибкости, но и в сложности языка. Есть очень гибкий язык - JavaScript. Но это при этом очень простой язык.
В части Rust преимущества может и перевешивают потенциальные проблемы. Но тут главный вопрос - для кого перевешивают?
Для опытного разработчика - да, перевешивают.
Для начинающего разработчика - нет.
Для соло-разработки - да, возможно.
Для командной разработки - сомневаюсь.
Для небольших проектов - да, перевешивают. Вообще, возможность "быстро переписать если что", может оправдать практически любые эксперименты.
Для больших проектов - опять же сомневаюсь, что перевешивают.
А если учесть, что опыт/размер команды/размер проекта - это независимые и недетерминированные факторы, то получаем трехмерное пространство оценки...
Так что опытному разработчику на небольшом проекте в соло - Rust вполне подойдет. А команде начинающих разработчиков да на большом проекте - лучше выбрать тот же Golang.
Да, искать замену Java в виде Rust - сомнительное занятие в общем случае (пускай частности и могут сыграть). Ниши сильно разные.
Хотя и не сказать, что эти ниши не пересекаются - например, в части написания микросервисов - что Rust, что Java (что куча других языков) чувствуют себя прекрасно.
И я сравниваю не фичи языков, а оцениваю Rust в целом из собственного опыта разработки ПО. И вижу определенные проблемы в Rust. Да, идеал недостижим - чем-то приходится жертвовать в любом случае, и к этому вопросов нет. Но из оценки достоинств и недостатков и строится правильный выбор технологии. И говорить только лишь о достоинствах Rust - не есть хорошо.
P.S. Вопрос сравнимости фич языков в отрыве от их области применения - тема, достойная отдельной дискуссии.
Пусть так, хотя я считаю явное выделение unsafe части тоже очень важным. А вот если говорить не о просто "фича есть в каком-то языке", а "такой набор фич в одном системном языке", то выбор сильно сужается.
Системных языков в целом не так уж и много. И безопасность кода (включая UB) - это типичная проблема именно C/C++, а не Java/C#.
Но да, в части системных языков, Rust - это серьезная альтернатива C/C++.
Тут забавная ситуация: не так уж редко слышно мнение в дуже "хочу раст, но более простой". Вплоть до того, что люди хотят раст со сборкой мусора просто из-за удобств вроде паттерн матчинга, карго и т.д. Меня это несколько удивляет.
Да, в Rust на многие вещи взглянули очень свежим взглядом. И те же enum-ы, которые в других языках, в большинстве своем, считались чуть ли не устаревшими конструкциями, заиграли новыми красками.
И да, рано или поздно этот набор фич разойдется по новым языкам и появится в существующих языках. Пускай не так быстро, как того хотелось бы, но это произойдет.
Это аргумент, что "тупой" код совсем не обязательно проще читать, писать и модифицировать, но разработчику для этого придётся прочитать что-то большее, чем пару страниц про язык.
Я никогда не топил за "тупой" код. Я топлю за читаемость кода. За легко-понимаемый код. Чтобы взглянул и сразу понял, что именно тут творится и как именно это работает. И у Rust-а, на мой взгляд, именно с читаемостью кода есть проблемы. В части "что именно творится" мешают макросы, а в части "как именно это работает" мешает вывод типов. Да, это очень гибкие и мощные инструменты. Но их гибкость и мешает пониманию кода.
То, что код на Rust выглядит достаточно просто (и компактно), не делает его легким для понимания. Да, с опытом и практикой, код станет легче читать и понимать. Но это никогда не станет достаточно простым делом, особенно при знакомстве с новым проектом.
Причем писать код на Rust зачастую даже легче, чем вникать в существующий код. А если его еще и дорабатывать надо... И это серьезный недостаток, на мой взгляд.
Но опять же - это все ИМХО "с моей колокольни", а моя колокольня - это Java/Golang, а не C/C++. С точки зрения разработчика C/C++, Rust может выглядеть совсем по другому.
У меня ощущение (переходящее в уверенность), что это сильно зависит от навороченности предлагаемых языком инструментов/абстракций.
Полностью согласен. Большие возможности языка налагают больше ответственности на разработчика. Если что-то можно написать "не так" - то это напишут "не так".
Впрочем, ту вопрос даже не навороченности языковых конструкций, а вопрос гибкости и возможностей языка в целом. Взять тот же JavaScript. На вскидку - очень простой язык. Но очень и очень гибкий (на вскидку - самый гибкий из известных мне). И вот это сочетание простоты и гибкости, на мой взгляд, не идут JavaScript-у на пользу. Или взять Golang. Простой язык (пусть и сложнее JS-а, на мой взгляд), но и особой гибкости нет. В результате - и говнокода сильно меньше.
Rust именно что навороченный язык. И я тоже не могу сказать, что это идет ему на пользу. Впрочем, открытым остается и вопрос - а мог ли Rust обойтись без этой навороченности? А стал бы он тогда так популярен? Так что тут палка о двух концах.
И вопрос не в тупости кода, а в его поддерживаемости. Тот же skip(...).map(...).filter(...).collect(...) вполне и на Java работает и активно используется (как и во многих других языках), причем синтаксис будет точно такой же. В простых сценариях простая копи-паста такого кода из Rust в Java потребует минимальных правок. Так что это не уникальная фишка Rust-а.
Уникальная фишка Rust-а, на мой взгляд, это концепция владения переменной (и ее последствия - вроде указания времени жизни ссылок и т.д.). Что позволяет иметь GC по факту без GC. Что сильно повышает скорость работы работы и предсказуемость времени выполнения алгоритма (GC не вмешивается в работу). А минимальный рантайм и компилируемость в выполняемый бинарник позволяет говорить о Rust-е как о низкоуровневом языке. Впрочем, не стоит забывать, что низкоуровневость - это не случайный результат (побочная фишка языка), а результат серьезного труда на попадание в эту нишу. Сам по себе язык очень высокоуровневый.
А практически все остальное - так или иначе есть и в других языках.
Кстати, о джаве. Я не специалист по этому языку, но ведь там можно обмазываться аннотациями не хуже, чем макросами в расте?.. Говорю про штуки вроде Lombok. Как там с ошибками и очевидностью?
Есть, но я и в Java не любитель подобных штук. В Java кодогенерация встраивается как часть процесса компиляции, что тоже требует определенных костылей. А в целом аннотации - это просто метки у методов/классов, они ни на что не влияют (если явно не учитывать и не анализировать эти метки в рантайме или при компиляции).
Впрочем, в Java такие вещи крайне редко встречаются, в отличие от Rust-а, где кодогенерация повсеместна (я про кодогенерацию, а аннотации очень часто используются в Java, причем в рантайме, что не идет на пользу скорости выполнения Java).
Я согласен, что кодогенерация - штука очень мощная и полезная, к этому вопросов нет. Другое дело, что нет устоявшихся правил и подходов к кодогенерации. А главное - явных ограничений, чтобы эти правила и подходы были прописаны на уровне языка. Это приводит зачастую к очень сложному коду, что для чтения, что для написания, что для понимания. Впрочем, Rust, как один из первопроходцев в этом вопросе, вполне ожидаемо, что имеет некоторые проблемы в этом (может Rust и не первый, но я не помню других популярных языков с повсеместной кодогенерацией).
Си - тоже очень гибкий язык, я бы даже сказал излишне гибкий. Но Си появился очень и очень давно и дал начало целому классу языков. И сейчас практически все языки Си-подобные (включая Rust).
Так и с кодогенерацией - ее рассвет, на мой взгляд, еще впереди. И Rust послужит серьезной вехой в этом пути.
На мой, взгляд, этим страдает не только Substrate, а все платформы смарт-контрактов на WASM. Пару лет назад специально изучал платформы с контрактами на WebAssembly - именно такое впечатление сложилось.
Разве что wasmd (CosmWasm) мне показался достаточно адекватным (если не брать их Sylvia framework, благо что он опционален).
Выше писал, что по факту мои претензии к Rust скорее связаны с выводом типов и с неочевидностью ошибок, которые этот вывод порождает. Да, в большинстве случаев Rust генерит очень подробные описания ошибок. Да, у Rust в большинстве случаев прекрасная документация. Но на мой взгляд, этого не хватает. Зачастую очень сложно понять, что именно компилятору не нравится в твоем коде, в отличие от других языков (например, Java/Golang), где из скудных описаний хотя бы сразу понятно куда смотреть и что делать (в большинстве случаев, сложные проблемы тоже бывают, но гораздо реже).
С макросами аналогично - очень часто с ними всплывают труднопонимаемые ошибки. Кроме того, макросы очень сильно усложняют чтение и понимание исходного кода используемых библиотек.
Свое очарование у Rust-а есть, с этим сложно спорить. Но сложные для понимания ошибки оставляют не лучшее впечатление. Сюда же накладывается быстрое развитие экосистемы - обновления зависимостей часто порождают дополнительные ошибки. Причем я не могу сказать, что ошибки сложно исправлять - если понял в чем именно ошибка, то исправление в большинстве случаев достаточно тривиальное.
Именно поэтому я и говорю, что впечатление смешанное. Чем Rust хорош - об этом написано много статей. Но у него есть и проблемы - про это тоже не надо забывать.
P.S. часть про макросы писал под впечатлением скорее Sylvia framework, недавно его изучил для расширения кругозора. Впечатление, откровенно говоря, осталось очень не очень. Но опять же - спасибо, что он опционален.
С++ ведь тоже существует и развивается в настоящее время, а с некоторыми вещами до сих пор не очень.
Про C++ мне сложно судить. Как я понимаю, с C++ больше вопрос легаси и вопрос разнообразия инструментария (исторически сложившегося). Проблема скорее в том, что общепринятого единого тулчейна просто нет. А так или иначе "современный" инструментарий есть.
У джетбрейнс свой велосипед, если мы говорим про семейство IDEA.
Хм... Был уверен, что у них плагин на базе RLS, а потом переделали на базе rust-analyzer. Не LSP, это да. Но на базе этих инструментов. Возможно, их плагин функционально сначала был на уровне RLS (или чуть лучше), а потом его догнали до уровня rust-analyzer (чтобы конкурировать с VS Code).
Я VS Code несколько раз с JetBrains сравнивал для Rust. И особой разницы, или не заметил, или она была вообще в пользу VS Code (когда появился rust-analyzer, а в JetBrains еще не обновили плагин).
Про Fleet слышал (но не щупал). Как я понимаю, это скорее попытка повторить VS Code (с их Remote Development) - легкая и расширяемая IDE с возможностью разработки в контейнере или по SSH.
И про совместную разработку они не забыли, хотя я очень плохо представляю, как это выглядит на практике - код это не документ в GDocs, у него должна сохраняться согласованная структура.
И вроде как они работают над своим аналогом LSP (впрочем, не отказываясь от поддержки LSP). И я верю, что у них выйдет хороший продукт - у JetBrains действительно хорошая экспертиза в разработке IDE (правда, если не растеряли ее за последние года - не сильно интересовался как именно у компании идут дела).
Спасибо! Лично мне статья по ссылке показалась намного более целостной.
"Простые люди" в данном случае - это не читатели научной литературы подразумеваются. Я-кать в письменной форме - зачастую не лучший вариант, согласен. Поэтому обезличенные обращения - рабочий выход, на мой взгляд. Но опять же - это особенности стилистики текста. Пишите как Вам удобно и привычно - в этом проблемы нет.
Про "мы" вопрос даже не к стилистике был, а чтобы понять "а кто такой автор статьи и с какой позиции эту статью следует рассматривать". Все-таки одно дело - личные впечатления о продукте, другое - статья в корпоративном блоге (или статья о своем же продукте).
Эм... В научных работах возможно так и принято (но в них и понятен контекст для местоимения). А в статьях "для простых людей", на мой взгляд, должно более прозрачно прослеживаться местоимение из контекста, или вообще использоваться обезличенные выражения. Но да ладно, это так, скорее придирка была - особенность стилистики текста.
Я согласен, что тут туториал среднего уровня - быстро прочитал и в закладки (если надо, скорее всего, потом через поиск материал искаться будет). Но это справедливо только для людей "сильно в теме".
И на узкоспециализированном профильном ресурсе - я бы сказал "ОК, нет вопросов". Или для документации EDK II / Tianocore - отличная статья, спору нет.
Но в данном случае, для хабра... Не знаю, не знаю... Лично для меня, сработало введение - привлекло внимание, заставило пройти под кат... Интересно стало что за зверь такой "Orange Pi 5" и с чем его едят...
А внутри - просто инструкция "как установить EDK II" из множества консольных команд. Которые дают дают пример "как это сделать", но не дают понимания "что мы делаем" и "зачем мы это делаем".
И речь не о технических характеристиках (хотя и они были бы не лишними, если не хотите загромождать статью - их можно убрать под спойлер). Я именно про описание решаемой проблемы, подхода к решению проблемы и т.д. Тут достаточно было бы одного-двух предложений (или абзацев) просто для погружения в контекст.
На мой взгляд, статье сильно не хватает введения.
Кто такие "мы"? Статья в личном блоге, а не в корпоративном.
Что такое EDK II, зачем он нужен и какие проблемы решает?
Аналогично и с toolchain - начинаем установку с него, но для чего он нужен - непонятно.
И в конце-концов, так и не раскрыта тема - можно ли использовать Orange Pi 5 в роли обычного ПК, как мы привыкли работать с обычными ПК? Самый интересный вопрос на самом деле...
Я скорее к тому, что в ситуации "на все публичное надо писать доки" и "не нужны доки на тесты" есть очень простой выход - не делать тесты публичными классами.
И принцип не нарушается и доки на тесты не надо писать.
Иногда для тестов делается определенный тулчейн, например подменяющий "родные" механики - и этот тулчейн хорошо бы задокументировать (особенно если он часто в тестах используется). А как известно, если доки нужно писать, но можно не писать - то доки не будут писать. И с этим статический анализатор может помочь. Но только в том случае, если анализатор не игнорит все, что в тестах происходит.
jUnit позволяет использовать package-private тестовые классы и методы (т.е. без модификатора доступа).
Согласен.
Но я бы не прочь увидеть и специально подобранный пример, где эти заявления более-менее выполняются.
Правда именно грамотный пример хотел бы увидеть - скажем, сравнение с alpine-образом и с примерно одинаковыми параметрами компиляции приложения.
Заявления с сайта wasmedge. Впрочем, объективность подобных заявлений под большим вопросом. Ни примеров, ни методики измерения не указано.
Максимум - готов поверить, что такие приложения могут занимать значительно меньше места. Впрочем, образы на базе alpine тоже занимают значительно меньше места относительно прочих образов, так что и тут остается открытым вопрос - с чем и как сравнивали.
И чем наличие опенсорсных реализаций делает протокол менее проприетарным?
Или вышла какая-то свежая реализация? Xrdp с 2004го года живет потихоньку...
Лично я считаю - что определенные проблемы у Rust в плане сложности есть. Вы говорите - что не так все плохо. Должен сказать, что эти две позиции ни капли не противоречат друг другу.
Опыт, практика - имеют значение в любом языке и/или стеке технологий. Где-то больше, где-то меньше, только и всего.
Я тут имел в виду, что запутанный код - явление есть везде и всегда как фактор развития кодовой базы проекта. И язык, в идеале, своими конструкциями, не должен добавлять дополнительных сложностей в читаемость кода.
Именно основы языка, его концепции очень простые (и, на удивление, лаконичные). Немного сложностей в плане ООП, но это все из серии "изучить нюансы и запомнить".
Лично мне в JS не нравится два фактора:
Динамическиая типизация - плохо работает IDE, много ошибок всплывает в рантайме (впрочем, тут спасет TypeScript).
Но TypeScript - это скорее C#, от JavaScript осталось очень мало.
Инфраструктура. Все очень быстро меняется, много кода низкого качества и сама по себе инфраструктура стала очень самобытной (тут TypeScript уже не спасает). Для изучения/погружения требуется очень много времени и сил, а знания очень быстро устаревают.
Если цель - написать сервис, то лучше привычные инструменты использовать, тут вопросов нет. А если цель - изучить Rust (и оценить его пригодность для других проектов), то вполне рабочий подход. Правда времени займет много (что на изучение Rust, что на использование в первое время).
В больших проектах, в больших командах - очень важен фактор читаемости кода. Если все в команде "собаку съели на Rust" - то это один вопрос. Впрочем, опять же, от проекта сильно зависит. Если для веб-сервиса выбор Rust - достаточно специфичный случай (потому как много альтернатив), то для написания прошивки выбор уже не столь неоднозначный (потому как безопасность решает).
И другой фактор, который лично мне не дает рекомендовать Rust для больших проектов - фактор поддерживаемости инфраструктуры. Rust сейчас очень быстро развивается. А это означает, что часто будут возникать проблемы с обновлением зависимостей (а для исправления нужно очень много трудозатрат). Или код сразу после написания будет устаревшим из-за использования устаревших либ (и устаревшей редакции языка).
Справедливости ради, на днях обнаружил, что у sqlx есть "Offline Mode" - можно выгрузить представление БД в виде JSON, и если DATABASE_URL в env не задано, то будет использоваться этот файл. Что позволяет успешно работать с проектом без постоянного подключения к БД. И в релизе 0.7 (который сейчас готовится) работа в Offline Mode становится приоритетным подходом, что, на мой взгляд, абсолютно оправдано.
Хаскель помимо активной практики требует и определенного, как бы сказать, состояния разума. И мне удалось это состояние поймать во время обучения в универе. Но это было уже очень давно и текущего опыт разработки у меня еще не было, чтобы адекватно оценить этот опыт. Общее впечатление - да, мне понравилось, было очень интересно. Но понимание хаскеля быстро ушло - сказалось отсутствие практики.
Тут больший вопрос, что это принципиально разные парадигмы программирования. Языки чисто функционального программирования и языки с элементами функционального программирования - это очень большая разница просто в подходах к программированию.
Запутанный код - это результат в первую очередь истории развития кода и навыков разработчика. Никогда не видел, чтобы специально писали запутанный код. Влияние именно языка тут достаточно вторично.
Да, больше гибкости - больше проблем, с этим сложно спорить. Но тут вопрос не только в гибкости, но и в сложности языка. Есть очень гибкий язык - JavaScript. Но это при этом очень простой язык.
В части Rust преимущества может и перевешивают потенциальные проблемы. Но тут главный вопрос - для кого перевешивают?
Для опытного разработчика - да, перевешивают.
Для начинающего разработчика - нет.
Для соло-разработки - да, возможно.
Для командной разработки - сомневаюсь.
Для небольших проектов - да, перевешивают. Вообще, возможность "быстро переписать если что", может оправдать практически любые эксперименты.
Для больших проектов - опять же сомневаюсь, что перевешивают.
А если учесть, что опыт/размер команды/размер проекта - это независимые и недетерминированные факторы, то получаем трехмерное пространство оценки...
Так что опытному разработчику на небольшом проекте в соло - Rust вполне подойдет.
А команде начинающих разработчиков да на большом проекте - лучше выбрать тот же Golang.
А во всех остальных случаях есть нюансы...
Да, искать замену Java в виде Rust - сомнительное занятие в общем случае (пускай частности и могут сыграть). Ниши сильно разные.
Хотя и не сказать, что эти ниши не пересекаются - например, в части написания микросервисов - что Rust, что Java (что куча других языков) чувствуют себя прекрасно.
И я сравниваю не фичи языков, а оцениваю Rust в целом из собственного опыта разработки ПО. И вижу определенные проблемы в Rust. Да, идеал недостижим - чем-то приходится жертвовать в любом случае, и к этому вопросов нет. Но из оценки достоинств и недостатков и строится правильный выбор технологии. И говорить только лишь о достоинствах Rust - не есть хорошо.
P.S. Вопрос сравнимости фич языков в отрыве от их области применения - тема, достойная отдельной дискуссии.
.
Системных языков в целом не так уж и много. И безопасность кода (включая UB) - это типичная проблема именно C/C++, а не Java/C#.
Но да, в части системных языков, Rust - это серьезная альтернатива C/C++.
Да, в Rust на многие вещи взглянули очень свежим взглядом. И те же enum-ы, которые в других языках, в большинстве своем, считались чуть ли не устаревшими конструкциями, заиграли новыми красками.
И да, рано или поздно этот набор фич разойдется по новым языкам и появится в существующих языках. Пускай не так быстро, как того хотелось бы, но это произойдет.
Я никогда не топил за "тупой" код. Я топлю за читаемость кода. За легко-понимаемый код. Чтобы взглянул и сразу понял, что именно тут творится и как именно это работает. И у Rust-а, на мой взгляд, именно с читаемостью кода есть проблемы. В части "что именно творится" мешают макросы, а в части "как именно это работает" мешает вывод типов. Да, это очень гибкие и мощные инструменты. Но их гибкость и мешает пониманию кода.
То, что код на Rust выглядит достаточно просто (и компактно), не делает его легким для понимания. Да, с опытом и практикой, код станет легче читать и понимать. Но это никогда не станет достаточно простым делом, особенно при знакомстве с новым проектом.
Причем писать код на Rust зачастую даже легче, чем вникать в существующий код. А если его еще и дорабатывать надо... И это серьезный недостаток, на мой взгляд.
Но опять же - это все ИМХО "с моей колокольни", а моя колокольня - это Java/Golang, а не C/C++. С точки зрения разработчика C/C++, Rust может выглядеть совсем по другому.
Полностью согласен. Большие возможности языка налагают больше ответственности на разработчика. Если что-то можно написать "не так" - то это напишут "не так".
Впрочем, ту вопрос даже не навороченности языковых конструкций, а вопрос гибкости и возможностей языка в целом. Взять тот же JavaScript. На вскидку - очень простой язык. Но очень и очень гибкий (на вскидку - самый гибкий из известных мне). И вот это сочетание простоты и гибкости, на мой взгляд, не идут JavaScript-у на пользу. Или взять Golang. Простой язык (пусть и сложнее JS-а, на мой взгляд), но и особой гибкости нет. В результате - и говнокода сильно меньше.
Rust именно что навороченный язык. И я тоже не могу сказать, что это идет ему на пользу. Впрочем, открытым остается и вопрос - а мог ли Rust обойтись без этой навороченности? А стал бы он тогда так популярен? Так что тут палка о двух концах.
И вопрос не в тупости кода, а в его поддерживаемости. Тот же
skip(...).map(...).filter(...).collect(...)вполне и на Java работает и активно используется (как и во многих других языках), причем синтаксис будет точно такой же. В простых сценариях простая копи-паста такого кода из Rust в Java потребует минимальных правок. Так что это не уникальная фишка Rust-а.Уникальная фишка Rust-а, на мой взгляд, это концепция владения переменной (и ее последствия - вроде указания времени жизни ссылок и т.д.). Что позволяет иметь GC по факту без GC. Что сильно повышает скорость работы работы и предсказуемость времени выполнения алгоритма (GC не вмешивается в работу). А минимальный рантайм и компилируемость в выполняемый бинарник позволяет говорить о Rust-е как о низкоуровневом языке. Впрочем, не стоит забывать, что низкоуровневость - это не случайный результат (побочная фишка языка), а результат серьезного труда на попадание в эту нишу. Сам по себе язык очень высокоуровневый.
А практически все остальное - так или иначе есть и в других языках.
Есть, но я и в Java не любитель подобных штук. В Java кодогенерация встраивается как часть процесса компиляции, что тоже требует определенных костылей. А в целом аннотации - это просто метки у методов/классов, они ни на что не влияют (если явно не учитывать и не анализировать эти метки в рантайме или при компиляции).
Впрочем, в Java такие вещи крайне редко встречаются, в отличие от Rust-а, где кодогенерация повсеместна (я про кодогенерацию, а аннотации очень часто используются в Java, причем в рантайме, что не идет на пользу скорости выполнения Java).
Я согласен, что кодогенерация - штука очень мощная и полезная, к этому вопросов нет. Другое дело, что нет устоявшихся правил и подходов к кодогенерации. А главное - явных ограничений, чтобы эти правила и подходы были прописаны на уровне языка. Это приводит зачастую к очень сложному коду, что для чтения, что для написания, что для понимания. Впрочем, Rust, как один из первопроходцев в этом вопросе, вполне ожидаемо, что имеет некоторые проблемы в этом (может Rust и не первый, но я не помню других популярных языков с повсеместной кодогенерацией).
Си - тоже очень гибкий язык, я бы даже сказал излишне гибкий. Но Си появился очень и очень давно и дал начало целому классу языков. И сейчас практически все языки Си-подобные (включая Rust).
Так и с кодогенерацией - ее рассвет, на мой взгляд, еще впереди. И Rust послужит серьезной вехой в этом пути.
На мой, взгляд, этим страдает не только Substrate, а все платформы смарт-контрактов на WASM. Пару лет назад специально изучал платформы с контрактами на WebAssembly - именно такое впечатление сложилось.
Разве что wasmd (CosmWasm) мне показался достаточно адекватным (если не брать их Sylvia framework, благо что он опционален).
Выше писал, что по факту мои претензии к Rust скорее связаны с выводом типов и с неочевидностью ошибок, которые этот вывод порождает. Да, в большинстве случаев Rust генерит очень подробные описания ошибок. Да, у Rust в большинстве случаев прекрасная документация. Но на мой взгляд, этого не хватает. Зачастую очень сложно понять, что именно компилятору не нравится в твоем коде, в отличие от других языков (например, Java/Golang), где из скудных описаний хотя бы сразу понятно куда смотреть и что делать (в большинстве случаев, сложные проблемы тоже бывают, но гораздо реже).
С макросами аналогично - очень часто с ними всплывают труднопонимаемые ошибки. Кроме того, макросы очень сильно усложняют чтение и понимание исходного кода используемых библиотек.
Свое очарование у Rust-а есть, с этим сложно спорить. Но сложные для понимания ошибки оставляют не лучшее впечатление. Сюда же накладывается быстрое развитие экосистемы - обновления зависимостей часто порождают дополнительные ошибки. Причем я не могу сказать, что ошибки сложно исправлять - если понял в чем именно ошибка, то исправление в большинстве случаев достаточно тривиальное.
Именно поэтому я и говорю, что впечатление смешанное. Чем Rust хорош - об этом написано много статей. Но у него есть и проблемы - про это тоже не надо забывать.
P.S. часть про макросы писал под впечатлением скорее Sylvia framework, недавно его изучил для расширения кругозора. Впечатление, откровенно говоря, осталось очень не очень. Но опять же - спасибо, что он опционален.
Про C++ мне сложно судить. Как я понимаю, с C++ больше вопрос легаси и вопрос разнообразия инструментария (исторически сложившегося). Проблема скорее в том, что общепринятого единого тулчейна просто нет. А так или иначе "современный" инструментарий есть.
Хм... Был уверен, что у них плагин на базе RLS, а потом переделали на базе rust-analyzer. Не LSP, это да. Но на базе этих инструментов. Возможно, их плагин функционально сначала был на уровне RLS (или чуть лучше), а потом его догнали до уровня rust-analyzer (чтобы конкурировать с VS Code).
Я VS Code несколько раз с JetBrains сравнивал для Rust. И особой разницы, или не заметил, или она была вообще в пользу VS Code (когда появился rust-analyzer, а в JetBrains еще не обновили плагин).
Про Fleet слышал (но не щупал). Как я понимаю, это скорее попытка повторить VS Code (с их Remote Development) - легкая и расширяемая IDE с возможностью разработки в контейнере или по SSH.
И про совместную разработку они не забыли, хотя я очень плохо представляю, как это выглядит на практике - код это не документ в GDocs, у него должна сохраняться согласованная структура.
И вроде как они работают над своим аналогом LSP (впрочем, не отказываясь от поддержки LSP). И я верю, что у них выйдет хороший продукт - у JetBrains действительно хорошая экспертиза в разработке IDE (правда, если не растеряли ее за последние года - не сильно интересовался как именно у компании идут дела).