Для простоты, можно считать все версии крейтов в Rust начиная с 0.1.0 (без суффикса -alpha. -beta) готовыми к продакшену. Обычно не только коммьюнити, но и мейнтейнеры считают, что могут еще переписать какую-либо часть проекта, а уже под версиями 1.0.0+ можно считать проекты, которые уже авторы и коммьюнити считают готовыми (и опять же, тут нет строгих рамок, как это считать). Ещё бывает, что когда версия переваливает через 1.0.0, то для каждой последующей начиная с первой (1.*.*, 2.*.*, 3.*.*) объявляют lts, давая еще большие гарантии стабильности для продакшена. А так, если честно, обычно кроме каких-то простых крейтов, где можно один раз написать код, и он будет работать, более сложные крейты требуют доработки в течение длительного времени, потому что часто выходят новые спецификации, делаются багфиксы, обновления зависимостей, поэтому и понятно, почему здесь так распространен ZeroVer (https://0ver.org/), особенно держа в уме, что многие крейты не так уж и давно начали разрабатываться.
В реальной жизни удобно ставить ограничение по мажорной версии, аля `crate_name = "0.6"`, что помогает получать багфиксы, новые фичи, при этом не получая breaking changes, которые возможны только при изменении той самой мажорной версии.
К сожалению, не являюсь экспертом в Rust Embedded, но предполагаю, что теоретически возможно повторить всё то, что можно сделать на C. С таким малым количеством памяти, придется отказаться от std библиотеки раста, а ещё может быть и от core и alloc. Аллокатора либо в принципе не будет, либо какой-нибудь кастомный. Ещё пишут, что llvm должен быть в состоянии скомпилировать под эту платформу, а сам код на Rust можно будет скорректировать по ходу. Есть много информации в интернете, можно узнать информацию по конкретным микроконтроллерам. А вот несколько общих ссылок:
на rust можно написать один и тот же код, кучей разных способов
Слышал и видел обратную версию, из-за того, что нет такого слоя легаси, обычно только один явный способ что-либо сделать. Возможно вы имеете ввиду про функциональный(итераторы) или императивный стили, но тут более или менее понятно, если надо возвращать что-либо из функции, используем обычные конструкции if, match, for, иначе же можем использовать map, for_each(а когда, уже больше зависит от контекста).
количество людей доступных на рынке
Из-за того, что на рынке разработчиков Rust больше желающих на нем работать, чем самой работы, довольно трудно найти себе на нем работу, но если вы хотите нанять кого-нибудь, я думаю, это не составит большого труда. А если что-то пойдет не так, всегда можете заходить в тг чат по rust jobs (https://t.me/rust_jobs), там полно желающих)
количества надежных библиотек вокруг языка
Как говорили и в других комментариях, с этим всё неплохо. Могу добавить, что для тех же веб сервисов есть целая экосистема, тот же крейт Axum, который находится под Tokio, или же actix, который разрабатывается другими людьми. У actix были проблемы с unsafe кодом с предыдущим мейнтейнером, но их уже решили, поэтому теперь там его по-минимуму.
В rust же нужно использовать стороннюю библиотеку tokio.
Tokio де-факто стандартный рантайм для асинхронных приложений на Rust. В основном, люди считают это за плюс, что он не встроен в язык, так как всегда можно выбрать другой, который больше подходит под ваши цели (ну или вообще не использовать райнтайм, если вы пишите что-то низкоуровневое).
В rust насколько я понял используются системные потоки, со всеми вытекающими, а асинхронность Future однопоточная
В Rust вы можете использовать все варианты, которые хотите. Если у вас CPU-bound задачи, используют Rayon (нет overhead'а из-за асинхронности), если же у вас обычный веб-сервис, то используют tokio, который по-дефолту мультипоточный (пул потоков) и асинхронный (еще может перекидывать задачи с одного потока на другой).
Migrating from threads to async or vice versa typically requires major refactoring work
Если вы сразу же начнете писать в асинхронном стиле, проблемы это не составит.
Закон Парето гласит, что во многих случаях 20% усилий дают 80% результата и я не вижу, где я могу применить rust в своей работе, что бы это было оправдано чем-то кроме "а давайте всё перепишем на rust". Надеюсь вы сможете меня переубедить :)
Если у вас есть рабочий код, которые выполняет все, что от него требуется, и не требует постоянного рефакторинга, добавления новых фичей, то лучше его не трогать ?. А если серьезно, то кмк стоит попробовать хотя бы для того, что лучше реализуются на самом Rust'е (микроконтроллеры, крипта, WASM, и т.д.). Возможно, если вам нужен будет супер-пупер производительный веб-сервер, да так, чтобы еще GC не портил статистику (привет, Discord), то это тоже неплохой выбор. Также, в интернете часто пишут, что работать с Rust более приятно, что у него лучше DX, чем у того же Go (обработка ошибок, и т.д.), но конкретно тут тяжелее объяснить преимущество для бизнеса, нужно пробовать самому и оценивать возможность использования по ситуации)
Если мы поддерживаем старое API, то можем сделать это поле опциональным и обрабатывать надлежающим способом. А вот уже другие ситуации, по моему мнению, стоит рассматривать отдельно, иначе можно получить неприятные ошибки.
egui - a simple, fast, and highly portable immediate mode GUI library
slint - a declarative GUI toolkit to build native user interfaces for desktop and embedded applications written in Rust, C++, or JavaScript
iced - a cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm.
dioxus - a Rust library for building apps that run on desktop, web, mobile, and more
и т.д.
Чем, например, эти библиотеки не угодили? Или к чему надо стремиться? Да и в наше время больше распространены веб-приложения, при этом почти все так же умеют компилироваться в WASM и успешно запускаются в браузере.
А для фанатов frontend разработки (где, так же, обходятся без наследования) есть даже свой аналог React SolidJS, leptos, с поддержкой гидрации, ssr, csr, server functions.
Конечно, некоторые из этих крейтов сыроваты, но начало положено, и да, это сделано без наследования.
Можно было ещё рассказать о wasmtime, рантайме для wasm и в принципе про перспективы в этой сфере, например, про то же очень вероятное появление в будущем в компиляторе Rust cranelift, который поможет ускорить сборку дебаг билдов.
Rust имеет Си-подобный синтаксис, с привкусом питона и чего-то ещё (ну мне так кажется), довольно стандартный набор. А так, когда ты привыкаешь к нему, как и к любому другому языку, начинаешь нормально воспринимать его синтаксис, понимать, почему сделаны те же страшные (но очень редко встречающиеся!) конструкции именно таким способом, например lifetimes, которые обычно выводятся сами компилятором. То же самое у меня происходило, когда мне пришлось во время учебы изучать джаву после раста, в первое время были неприятные ощущения, но затем быстро привык )
По ощущениям, он противопоставляется даже большему количеству языков, таких как Java, C#. Наверное, из-за его довольно уникального подхода работы с памятью и неплохой продуманности языка (когда создавали, пытались избегать проблем, которые возникли в других языках). А так, можете хоть fullstack приложение на Rust написать, противопоставляя это fullstack приложению на JavaScript, ничего этому не будет мешать)
Ну всё-таки не на каждую версию серьёзные изменения, выход же версий предопределен. Зато, уже не за горизонтом, виднеется стабилизация тех же async трейтов, что будет довольно масштабным событием для всей асинхронности в расте.
По крайней мере, появились современные фреймворки, например такой как leptos, который позволяет скрыть все детали реализации(прослойку в виде js), и писать на том же расте с leptos так же как на js с реактом. По производительности получается примерно как обычный js, но пишешь на своем языке. Например, на том же leptos'е, уже можно с легкостью писать ssr full-stack приложения, смешивая серверную и клиентскую части сайта, просто вызывая функции. Экосистема связанная с WASM сейчас очень быстро развивается и в вебе, и в облачной инфраструктуре.
В Калининградской области, находится город Советск который, на данный момент, имеет только пешеходный пропускной пункт, так как автомобильный закрыли на время строительства нового пункта. Но и до закрытия можно было проехать на автомобиле или пройти пешком.
Как я заметил, кто-то спокойно пишет на расте, но это больше зависит от скилла и от привычек пишущего кода, а так, самое неприятное это написание gui, но в этом направлении крейты очень неплохо развиваются.
Так Rust же изначально был с green threads, но в дальнейшем от этого отказались в пользу нативных потоков, т.к. green threads не всегда нужны, а это добавляет лишний runtime. Сейчас, взамен, есть крейт tokio, который можно использовать только тогда, когда это нужно.
Для простоты, можно считать все версии крейтов в Rust начиная с 0.1.0 (без суффикса
-alpha.-beta) готовыми к продакшену. Обычно не только коммьюнити, но и мейнтейнеры считают, что могут еще переписать какую-либо часть проекта, а уже под версиями 1.0.0+ можно считать проекты, которые уже авторы и коммьюнити считают готовыми (и опять же, тут нет строгих рамок, как это считать). Ещё бывает, что когда версия переваливает через 1.0.0, то для каждой последующей начиная с первой (1.*.*, 2.*.*, 3.*.*) объявляют lts, давая еще большие гарантии стабильности для продакшена. А так, если честно, обычно кроме каких-то простых крейтов, где можно один раз написать код, и он будет работать, более сложные крейты требуют доработки в течение длительного времени, потому что часто выходят новые спецификации, делаются багфиксы, обновления зависимостей, поэтому и понятно, почему здесь так распространен ZeroVer (https://0ver.org/), особенно держа в уме, что многие крейты не так уж и давно начали разрабатываться.В реальной жизни удобно ставить ограничение по мажорной версии, аля `crate_name = "0.6"`, что помогает получать багфиксы, новые фичи, при этом не получая breaking changes, которые возможны только при изменении той самой мажорной версии.
А, да, верно, перепутал с фичей
fullК сожалению, не являюсь экспертом в Rust Embedded, но предполагаю, что теоретически возможно повторить всё то, что можно сделать на C. С таким малым количеством памяти, придется отказаться от
stdбиблиотеки раста, а ещё может быть и отcoreиalloc. Аллокатора либо в принципе не будет, либо какой-нибудь кастомный. Ещё пишут, что llvm должен быть в состоянии скомпилировать под эту платформу, а сам код на Rust можно будет скорректировать по ходу. Есть много информации в интернете, можно узнать информацию по конкретным микроконтроллерам. А вот несколько общих ссылок:1) Rust Embedded Book: https://docs.rust-embedded.org/book/
2) Is Rust Ready for Microcontrollers?: https://www.elektormagazine.com/articles/is-rust-ready-for-microcontrollers
3) Rust as an alternative to C++ in microcontrollers: https://www.reddit.com/r/rust/comments/fpfmtv/rust_as_an_alternative_to_c_in_microcontrollers/
4) Using
stdin embedded Rust (для микроконтроллеров побольше и посовременней): https://blog.timhutt.co.uk/std-embedded-rust/index.html5) Чат в телеграмме для железяшников Rust'а: https://t.me/embedded_rs <-- думаю, там гораздо лучше разбираются в данной теме и смогут ответить на такие вопросы
Постараюсь ответить на некоторые ваши вопросы
Слышал и видел обратную версию, из-за того, что нет такого слоя легаси, обычно только один явный способ что-либо сделать. Возможно вы имеете ввиду про функциональный(итераторы) или императивный стили, но тут более или менее понятно, если надо возвращать что-либо из функции, используем обычные конструкции
if,match,for, иначе же можем использоватьmap,for_each(а когда, уже больше зависит от контекста).Из-за того, что на рынке разработчиков Rust больше желающих на нем работать, чем самой работы, довольно трудно найти себе на нем работу, но если вы хотите нанять кого-нибудь, я думаю, это не составит большого труда. А если что-то пойдет не так, всегда можете заходить в тг чат по rust jobs (https://t.me/rust_jobs), там полно желающих)
Как говорили и в других комментариях, с этим всё неплохо. Могу добавить, что для тех же веб сервисов есть целая экосистема, тот же крейт Axum, который находится под Tokio, или же actix, который разрабатывается другими людьми. У actix были проблемы с unsafe кодом с предыдущим мейнтейнером, но их уже решили, поэтому теперь там его по-минимуму.
Tokio де-факто стандартный рантайм для асинхронных приложений на Rust. В основном, люди считают это за плюс, что он не встроен в язык, так как всегда можно выбрать другой, который больше подходит под ваши цели (ну или вообще не использовать райнтайм, если вы пишите что-то низкоуровневое).
В Rust вы можете использовать все варианты, которые хотите. Если у вас CPU-bound задачи, используют Rayon (нет overhead'а из-за асинхронности), если же у вас обычный веб-сервис, то используют tokio, который по-дефолту мультипоточный (пул потоков) и асинхронный (еще может перекидывать задачи с одного потока на другой).
Если вы сразу же начнете писать в асинхронном стиле, проблемы это не составит.
Если у вас есть рабочий код, которые выполняет все, что от него требуется, и не требует постоянного рефакторинга, добавления новых фичей, то лучше его не трогать ?. А если серьезно, то кмк стоит попробовать хотя бы для того, что лучше реализуются на самом Rust'е (микроконтроллеры, крипта, WASM, и т.д.). Возможно, если вам нужен будет супер-пупер производительный веб-сервер, да так, чтобы еще GC не портил статистику (привет, Discord), то это тоже неплохой выбор. Также, в интернете часто пишут, что работать с Rust более приятно, что у него лучше DX, чем у того же Go (обработка ошибок, и т.д.), но конкретно тут тяжелее объяснить преимущество для бизнеса, нужно пробовать самому и оценивать возможность использования по ситуации)
Если мы поддерживаем старое API, то можем сделать это поле опциональным и обрабатывать надлежающим способом. А вот уже другие ситуации, по моему мнению, стоит рассматривать отдельно, иначе можно получить неприятные ошибки.
Actix выходит чуть быстрее по бенчмаркам, чем Axum, наверное поэтому его и брал автор оригинала
Тем временем:
egui - a simple, fast, and highly portable immediate mode GUI library
slint - a declarative GUI toolkit to build native user interfaces for desktop and embedded applications written in Rust, C++, or JavaScript
iced - a cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm.
dioxus - a Rust library for building apps that run on desktop, web, mobile, and more
и т.д.
Чем, например, эти библиотеки не угодили? Или к чему надо стремиться? Да и в наше время больше распространены веб-приложения, при этом почти все так же умеют компилироваться в WASM и успешно запускаются в браузере.
А для фанатов frontend разработки (где, так же, обходятся без наследования) есть даже свой аналог
ReactSolidJS, leptos, с поддержкой гидрации, ssr, csr, server functions.Конечно, некоторые из этих крейтов сыроваты, но начало положено, и да, это сделано без наследования.
Можно было ещё рассказать о wasmtime, рантайме для wasm и в принципе про перспективы в этой сфере, например, про то же очень вероятное появление в будущем в компиляторе Rust cranelift, который поможет ускорить сборку дебаг билдов.
В такой ситуации может помочь обычное нажатие клавиши Win на клавиатуре
Rust имеет Си-подобный синтаксис, с привкусом питона и чего-то ещё (ну мне так кажется), довольно стандартный набор. А так, когда ты привыкаешь к нему, как и к любому другому языку, начинаешь нормально воспринимать его синтаксис, понимать, почему сделаны те же страшные (но очень редко встречающиеся!) конструкции именно таким способом, например lifetimes, которые обычно выводятся сами компилятором. То же самое у меня происходило, когда мне пришлось во время учебы изучать джаву после раста, в первое время были неприятные ощущения, но затем быстро привык )
По ощущениям, он противопоставляется даже большему количеству языков, таких как Java, C#. Наверное, из-за его довольно уникального подхода работы с памятью и неплохой продуманности языка (когда создавали, пытались избегать проблем, которые возникли в других языках). А так, можете хоть fullstack приложение на Rust написать, противопоставляя это fullstack приложению на JavaScript, ничего этому не будет мешать)
Ну всё-таки не на каждую версию серьёзные изменения, выход же версий предопределен. Зато, уже не за горизонтом, виднеется стабилизация тех же async трейтов, что будет довольно масштабным событием для всей асинхронности в расте.
По крайней мере, появились современные фреймворки, например такой как leptos, который позволяет скрыть все детали реализации(прослойку в виде js), и писать на том же расте с leptos так же как на js с реактом. По производительности получается примерно как обычный js, но пишешь на своем языке. Например, на том же leptos'е, уже можно с легкостью писать ssr full-stack приложения, смешивая серверную и клиентскую части сайта, просто вызывая функции. Экосистема связанная с WASM сейчас очень быстро развивается и в вебе, и в облачной инфраструктуре.
В Калининградской области, находится город Советск который, на данный момент, имеет только пешеходный пропускной пункт, так как автомобильный закрыли на время строительства нового пункта. Но и до закрытия можно было проехать на автомобиле или пройти пешком.
Другой робот)
RustКак я заметил, кто-то спокойно пишет на расте, но это больше зависит от скилла и от привычек пишущего кода, а так, самое неприятное это написание gui, но в этом направлении крейты очень неплохо развиваются.
Если я верно понимаю, то это они:
Hidden text
Запретить на сервере их легко, так что это не проблема, как я полагаю
Так Rust же изначально был с green threads, но в дальнейшем от этого отказались в пользу нативных потоков, т.к. green threads не всегда нужны, а это добавляет лишний runtime. Сейчас, взамен, есть крейт tokio, который можно использовать только тогда, когда это нужно.