Было что попался мелкий проект, который не важно на каких технологиях. Хотел попробовать Rust, но после прочтения этой статьи передумал: https://habr.com/ru/post/309968/
Вопрос такой — статья написана 7 лет назад то. Изменилось ли что с тех пор в лучшую сторону?
S>Было что попался мелкий проект, который не важно на каких технологиях. Хотел попробовать Rust, но после прочтения этой статьи передумал: https://habr.com/ru/post/309968/ S>Вопрос такой — статья написана 7 лет назад то. Изменилось ли что с тех пор в лучшую сторону?
Чуть посмотрел начало статьи. IMHO вкратце суть такова: кто хочет найти оправдание — тот его найдет.
Rust уже довольно развитый язык со своей обширной инфраструктурой (по количеству библиотек и инструментов давно догнал GoLang). Возможно, в GUI все не так хорошо, но наверняка там ситуация даже лучше, чем в том же Go, про который никто не станет говорить, что он плох.
В общем, если захочешь его освоить и писать на нем — это реально и принесет тебе пользу.
Если же у тебя есть убеждение, что Rust переоценивают, то ты найдешь достаточное количество изъянов, подтверждающих это мнение.
У Rust две неприятности: мало вакансий и много хейтеров. Вакансии постепенно появляются, потому что Rust начинают использовать коммерсанты (но это идет медленно). А хейтеры... Да плевать на них — кроме флейма на форумах они никак не мешают (достаточно на такие форумы не ходить, потому что есть другие с более конструктивным общением).
Пара фактов про Rust, чтобы понять, что это зрелая технология с большим количеством библиотек и развитой инфраструктурой (IDE, онлайн инструменты).
для веб разработки (backend) в Rust есть не меньше фреймворков, чем в GoLang или JS/TS/Node. Фреймворки Rust довольно зрелые, широко используются.
в телеграм канале Rust пользователей всего в 2 раза меньше, чем в C++. Общение на порядок более конструктивное
Здравствуйте, Reset, Вы писали:
R>для веб разработки (backend) в Rust есть не меньше фреймворков, чем в GoLang или JS/TS/Node. Фреймворки Rust довольно зрелые, широко используются.
Посоветуй популярный фреймворк без асинхронности. Он должен пускать в главном потоке цикл accept, для новых соединений запускать новый поток и в этом потоке обрабатывать соединение и в том числе вызывать пользовательский код, который тоже должен в простом однопоточном режиме обработать запрос и записать ответ. В том числе должна быть работа с базой в таком же стиле (без всяких ORM).
vsb>Посоветуй популярный фреймворк без асинхронности.
Я таких не знаю. Я работал с actix, salvo и axum (щас самый быстрорастущий, потому что от создателей tokio и довольно удобный). Я бы поискал в гугле или на crates.io (https://crates.io/search?q=web%20framework)
> Он должен пускать в главном потоке цикл accept, для новых соединений запускать новый поток и в этом потоке обрабатывать соединение и в том числе вызывать пользовательский код, который тоже должен в простом однопоточном режиме обработать запрос и записать ответ. В том числе должна быть работа с базой в таком же стиле (без всяких ORM).
По таким экзотическим требованиям вряд ли есть что-то достаточно зрелое (потому что мало кому надо). Если тебе зачем-то нужно обрабатывать запросы в отдельных потоках, то можно взять асинхронный фреймворк и после получения запроса запускать отдельный поток для обработки (хотя не понятно зачем, потому что с теми же базами в Rust можно отлично работать асинхронно, даже с SQLite). В общем, либо у тебя довольно экзотическая ситуация и тебе это реально нужно. Либо ты думаешь, что хочешь, а на самом деле тебе надо не это.
У меня была ситуация, что я хотел сигналы и слоты как Qt, только в Rust, потому что хотел при добавлении нового компонента подписываться на сигналы уже существующего без изменения кода старого компонента (написал logger, подписался на события от нужных компонентов, а их код никак не меняется). И, даже, что-то нашел. При этом не мог понять, почему в Rust нет обилия библиотек для работы с сигналами. При этом я был уверен, что мне нужны именно сигналы, потому что каналы с сообщениями работают как-то не так... Потом прочитал про broadcast channel и понял, что он решает мою задачу даже проще и удобнее... Я это к тому, чтобы ты подумал, зачем тебе нужна такая архитектура (такое возможно, для поддержки legacy, например, которое не умеет работать на разных потоках, потому что использует thread local). Но, как я сказал, читать и писать в сеть синхронно смысла нет, а после получения запроса можно создать поток и обрабатывать запрос в нем (что-то типа block_on().await в асинхронно обработчике запроса).
P.S. Я сам не так давно начал осваивать Rust, поэтому, если хочешь более грамотного ответа, то есть каналы https://t.me/rustlang_ru и https://t.me/rust_beginners_ru. Отвечают быстро и по делу. По сути оба одинаковые с одним составом пользователей (разделения на новичков и экспертов я там не обнаружил, но сам задаю вопросы в канале новичков).
Здравствуйте, Shmj, Вы писали:
S>Было что попался мелкий проект, который не важно на каких технологиях. Хотел попробовать Rust, но после прочтения этой статьи передумал: https://habr.com/ru/post/309968/
Стоит попробовать. Если Ui фреймворки не изобретать, то вероятно все пройдет гладко.
S>Вопрос такой — статья написана 7 лет назад то.
Статья о том, как человек взял отвертку и попытался ей забить гвозди.
S>Изменилось ли что с тех пор в лучшую сторону?
В целом ничего не изменилось, только появилось куча crate (пакетов) с готовыми реализациями всего, от деревьев до UI и веб-серверов.
Здравствуйте, Shmj, Вы писали:
S>Было что попался мелкий проект, который не важно на каких технологиях. Хотел попробовать Rust, но после прочтения этой статьи передумал: https://habr.com/ru/post/309968/
S>Вопрос такой — статья написана 7 лет назад то. Изменилось ли что с тех пор в лучшую сторону?
некоторое время назад мне показалось отличной идеей иметь в багажнике домкрат(системный язык программирования или СЯП).
СЯПОВ также много как и ПЯПОВ(прикладных).
за rust против плюсов:
cargo — сборка зависимости
функциональность
против раст: чрезмерная когнитивная нагрузка(маленький плюс что сообщения компилятора на уровне).
вообщем раст отстой, жаль если он начнет замещать C.
Остутствие сборщика мусора в расте обходится слишком дорого для программиста.
баланс между надежностью ПО и производительностью труда пока не найден.
но если перестать боятся сборщика мусора или маргинальщины предлагаю на выбор 3
D — самый простой(близок по духу питону). Кстати, чел утверждает что в плюсовики постоянно тырят идеи из ди.
но "получается как всегда"(ц).
zig — ручное управление памятью.
ну или oberon в нем полиморфизм как в расте реализован(или раст скопировал у оберона).
ПС не совсем по теме, но еще бы вот все компиляторы так на опечатки реагировали(F#):
> open System;;
> DateTim;;
DateTim;;
^^^^^^^
stdin(2,1): error FS0039: Значение или конструктор "DateTim" не определены. Возможно, требуется одно из следующих:
DateTime
DateTimeKind
DateTimeOffset
Data
>
vaa>против раст: чрезмерная когнитивная нагрузка(маленький плюс что сообщения компилятора на уровне).
По моим наблюдениям когнитивную нагрузку и borrow checker в Rust упоминают люди, которые на нем нихрена не написали, зато любят поболтать про Rust в стиле "Rust — неоправданно сложен". Upd. Я сам был таким.
Того, кто пишет на Rust borrow checker не только не напрягает — он помогает заранее продумать архитектуру, потому что подскажет, что вот эту переменную ты можешь изменить из двух мест — это не безопасно. А дальше, если оно тебе очень надо — unsafe {} и вперед. Когда прога будет падать, сделаешь grep -r unsafe. unsafe — часть Rust, без него двусвязный список нормально не написать. С unsafe начинается почти вся стандартная библиотека. Впрочем в Rust есть фанатики, которые борются за чистоту кода от unsafe. Такие задолбали автора actix, что он ушел из своего проекта и грохнул репозиторий на github. Но это исключительный случай и обычно они безобидные, пока не начинают участвовать в твоем проекте (а чего они творят в своем — их дело, ты просто делаешь cargo add и насколько там безопасный код — не важно, главное, чтобы проект поддерживался, был популярным и в Readme.md автор не выглядел полным психопатом).
vaa>D — самый простой(близок по духу питону). Кстати, чел утверждает что в плюсовики постоянно тырят идеи из ди.
IMHO, упоминание маргинальщины (D, Haskel, Erlang, SVN, FreeBSD) — это диагноз. Разумные люди от нее избавляются и переходят на более популярные инструменты, потому что так удобнее. С маргинальщиной живут только полные фанатики. И параноики, которым постоянно кажется, что D — центр вселенной и оттуда кто-то что-то тырит. Работают такие фанатики исключительно в одиночку. Ни один разумный человек с маргинальщиной работать не будет, даже при зарплате в разы выше рынка.
Извини, наболело, но все любители маргинальщины, кого я видел — упертые бараны или конченные психопаты с подходом "я прав, я всегда прав, только я всегда прав, поэтому я могу творить, что хочу, ведь я всегда прав, а окружающие могут делать только то, что я разрешу, потому что так правильно". Однако, это уже offtop.
Здравствуйте, Reset, Вы писали:
R>IMHO, упоминание маргинальщины (D, Haskel, Erlang, SVN, FreeBSD) — это диагноз. Разумные люди от нее избавляются и переходят на более популярные инструменты, потому что так удобнее. С маргинальщиной живут только полные фанатики. И параноики, которым постоянно кажется, что D — центр вселенной и оттуда кто-то что-то тырит. Работают такие фанатики исключительно в одиночку. Ни один разумный человек с маргинальщиной работать не будет, даже при зарплате в разы выше рынка.
Elixir-разработчики сгрызли ногти от осознания собственной никчемности и бренности всего сущего.
Здравствуйте, so5team, Вы писали: S>Elixir-разработчики сгрызли ногти от осознания собственной никчемности и бренности всего сущего.
Какие разработчики? Разработчики статю. шума в данных HR выборки?
Здравствуйте, Reset, Вы писали:
R>ты просто делаешь cargo add и насколько там безопасный код — не важно, главное, чтобы проект поддерживался, был популярным и в Readme.md автор не выглядел полным психопатом).
Именно эти слова убедили меня пока не трогать ЭТО.
Здравствуйте, Reset, Вы писали:
R>Лет 10 уже от тебя ничего не слышал кроме провокации флейма и попыток доказать, что у тебя длиннее. R>Ничего полезного.
Звучит как будто вы 10 лет платили-платили за что-то другое, а получили только это.
Заранее оговорюсь, что в основном согласен, но есть несколько возражений.
R> Когда прога будет падать, сделаешь grep -r unsafe.
Просто уточню, что хоть корень проблемы будет в ансейф блоке, но падать может совсем в других местах. То есть явные ансейф блоки безусловно помогают обратить внимание на потенциально опасные моменты, но устроить себе проблемы можно.
R> Впрочем в Rust есть фанатики, которые борются за чистоту кода от unsafe. Такие задолбали автора actix, что он ушел из своего проекта и грохнул репозиторий на github.
Довольно быстро автор одумался и репозиторий вернул. Правда в итоге отошёл от дел, отдал проект "сообществу" и сам пошёл пилить что-то новое. Ну и, насколько я помню, в актиксе были конкретные примеры неопределённого поведения, а не просто "много ансейф, срочно убрать".
R> IMHO, упоминание маргинальщины (D, Haskel, Erlang, SVN, FreeBSD) — это диагноз.
Так-то раст сам где-то на грани маргинальности по сравнению с мейнстримом. И популярность он набирает, в том числе, благодаря людям, которые не побоялись начать на нём писать когда всё было ещё хуже.
Здравствуйте, Doom100500, Вы писали:
D>Именно эти слова убедили меня пока не трогать ЭТО.
А в других языках ты делаешь тщательное ревью всех используемых библиотек или пользуешься только своими велосипедами?.. Так-то велосипеды писать и на расте можно. Плюс в расте есть около-стандартный инструмент для предупреждения об известных уязвимостях в библиотеках (cargo audit). Пожалуй, в большом дереве зависимостей действительно проще пропихнуть зловредный код, но если его кто-то зарепортит, то об этом по крайней мере проще будет узнать.
Здравствуйте, DarkEld3r, Вы писали:
DE>А в других языках ты делаешь тщательное ревью всех используемых библиотек или пользуешься только своими велосипедами?.
Если исключить pet-проекты, то: Нельзя просо так взять и притащить зависимость (картинка с Боромиром) .
Надо обосновать и, естесственно, провести аудит. Версия зависимости обновляется в самом крайнем случае.
DE>для предупреждения об известных уязвимостях в библиотеках (cargo audit) npm audit говорит: "ну попробуй" (тут картинка улыбающегося чувака, которого я не знаю. но сеть переполнена мемами с ним).
DE>Пожалуй, в большом дереве зависимостей действительно проще пропихнуть зловредный код, но если его кто-то зарепортит, то об этом по крайней мере проще будет узнать.
vsb>Посоветуй популярный фреймворк без асинхронности. Он должен пускать в главном потоке цикл accept, для новых соединений запускать новый поток и в этом потоке обрабатывать соединение и в том числе вызывать пользовательский код, который тоже должен в простом однопоточном режиме обработать запрос и записать ответ. В том числе должна быть работа с базой в таком же стиле (без всяких ORM).
Нужно? Напиши сам.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Doom100500, Вы писали:
D>Нельзя просо так взять и притащить зависимость (картинка с Боромиром) . D>Надо обосновать и, естесственно, провести аудит. Версия зависимости обновляется в самом крайнем случае.
Отлично, что мешает делать это в расте?
D>npm audit говорит: "ну попробуй" (тут картинка улыбающегося чувака, которого я не знаю. но сеть переполнена мемами с ним).
Можешь разжевать для тех, кто не в теме, что там с npm audit?
Здравствуйте, vsb, Вы писали:
НС>>Зачем тебе без асинхронности?
vsb>Мне она не нужна и усложняет код.
Синхронность усложняет жизнь программисту
Могу предположить твоё ограничение: синхронный вызов через какое-нибудь кривое API лочит всю асинхронную прилагу. Ну вызови это API через асинхронный адаптер с пулом потоков.
