Может быть мой мозг уже глючит, поэтому очень хорошо видет паттерны чатгптшки, которое часто ассоциируется с красными флагами о качестве самой статьи, поэтому меня в этом случае заставило насторожиться.
Да, я понимаю, что сама библиотека написана на расте, но писать "полностью" жирным цветом и говорить как избавление от C++ зависимостей (которые все равно так же под капотом) как фичу я бы не стал, т.к. они всё ещё под капотом и могут попортить жизнь для кросс-компиляции.
Могу посоветовать использовать хотя бы #![doc(include = "README.md")], чтобы там тоже была документация с гитхаба.
К моему большому сожалению, я пока не разбираюсь в этой теме настолько, чтобы судить о вашем коде, поэтому мои притензии насчёт качества вашего кода могут быть необоснованны, так что прошу меня извинить в этом случае.
См пункт 4, но в общем случае писать один такой файл можно, с этим я согласен, если его конечно нельзя поделить на полноценные логические модули
Когда есть возможность написать тесты это всегда плюс для вашей библиотеки ;)
См пункт 3
Я не хочу осуждать или как-то вас оскорблять, это всегда хорошо, когда кто-то пытается что-то сделать и поделиться этим. Возможно мой первый комментарий прозвучал грубовато, но я просто посмотрел на код глазами обычного обывателя и хотел поделиться тем, что мне сразу не понравилось как обычному пользователю библиотек. Считаю хоть ваш проект и мал, но всё-таки имеет шанс на жизнь и дальнейшее улучшение :)
(по крайней мере это не leftpad по смыслу и размеру :) )
P.s. Популярность сложно измерять количеством скачиваний на crates.io, так как у небольших крейтов обычно большое количество загрузок занимает загрузки на альтернативные регистры.
Почему вся статья и комментарий выглядит как будто написана гптшкой? Почему этот крейт выглядит как простой враппер над крейтом opencv, при этом здесь указывается, что крейт написан на чистом расте и без танцами с OpenCV, при этом в гитхабе первое требование это скачать OpenCV зависимость. При этом в самом OpenCV указано, что это просто биндинги с библиотеки на C++. В https://docs.rs/yolo_detector/latest/yolo_detector/ нет никакой документации. Больше выглядит либо как не самая лучшая библиотека, которая может быть просто сгенеренна гптшкой, при том что всё лежит в одном файле без каких-либо тестов без глубокой проработки и нормальной доки. Пойдет для обычного пет проекта для гитхаба, но смысла загружать в crates.io особо не было.
А вердикт пусть вынесет 4o:
💬 Вердикт
Проект yolo_detector оставляет крайне спорное впечатление.
Заявляется "чистый Rust без танцев с OpenCV", но на GitHub в первом же пункте — требование установить OpenCV, а сам крейт по сути — враппер над C++-биндингами.
Структура проекта примитивна: один файл, ни тестов, ни модульности, ни комментариев.
Описание и статья выглядят как автогенерация — не хватает технической глубины и честного раскрытия деталей.
Для pet-проекта — нормально, но выкладывать такой код на crates.io без должной доработки и описания — преждевременно.
Пока это выглядит как черновик или эксперимент, а не как библиотека, пригодная для использования. Хотелось бы увидеть честное позиционирование и улучшения в структуре, документации и тестировании.
Интересно, как будет развиваться тот же blitz — голый рендер HTML и CSS, без JavaScript и браузерных фич, для нативных приложений на Rust. Возможно, веб-приложения всё-таки смогут стать ещё более компактными, практически приблизившись к аналогичной производительности нативных приложений (по скорости исполнения и потреблению памяти), благодаря более совершенным подходам.
Для простоты, можно считать все версии крейтов в 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 сейчас очень быстро развивается и в вебе, и в облачной инфраструктуре.
В Калининградской области, находится город Советск который, на данный момент, имеет только пешеходный пропускной пункт, так как автомобильный закрыли на время строительства нового пункта. Но и до закрытия можно было проехать на автомобиле или пройти пешком.
Может быть мой мозг уже глючит, поэтому очень хорошо видет паттерны чатгптшки, которое часто ассоциируется с красными флагами о качестве самой статьи, поэтому меня в этом случае заставило насторожиться.
Да, я понимаю, что сама библиотека написана на расте, но писать "полностью" жирным цветом и говорить как избавление от C++ зависимостей (которые все равно так же под капотом) как фичу я бы не стал, т.к. они всё ещё под капотом и могут попортить жизнь для кросс-компиляции.
Могу посоветовать использовать хотя бы #![doc(include = "README.md")], чтобы там тоже была документация с гитхаба.
К моему большому сожалению, я пока не разбираюсь в этой теме настолько, чтобы судить о вашем коде, поэтому мои притензии насчёт качества вашего кода могут быть необоснованны, так что прошу меня извинить в этом случае.
См пункт 4, но в общем случае писать один такой файл можно, с этим я согласен, если его конечно нельзя поделить на полноценные логические модули
Когда есть возможность написать тесты это всегда плюс для вашей библиотеки ;)
См пункт 3
Я не хочу осуждать или как-то вас оскорблять, это всегда хорошо, когда кто-то пытается что-то сделать и поделиться этим. Возможно мой первый комментарий прозвучал грубовато, но я просто посмотрел на код глазами обычного обывателя и хотел поделиться тем, что мне сразу не понравилось как обычному пользователю библиотек. Считаю хоть ваш проект и мал, но всё-таки имеет шанс на жизнь и дальнейшее улучшение :)
(по крайней мере это не leftpad по смыслу и размеру :) )
P.s. Популярность сложно измерять количеством скачиваний на crates.io, так как у небольших крейтов обычно большое количество загрузок занимает загрузки на альтернативные регистры.
Почему вся статья и комментарий выглядит как будто написана гптшкой? Почему этот крейт выглядит как простой враппер над крейтом opencv, при этом здесь указывается, что крейт написан на чистом расте и без танцами с OpenCV, при этом в гитхабе первое требование это скачать OpenCV зависимость. При этом в самом OpenCV указано, что это просто биндинги с библиотеки на C++. В https://docs.rs/yolo_detector/latest/yolo_detector/ нет никакой документации. Больше выглядит либо как не самая лучшая библиотека, которая может быть просто сгенеренна гптшкой, при том что всё лежит в одном файле без каких-либо тестов без глубокой проработки и нормальной доки. Пойдет для обычного пет проекта для гитхаба, но смысла загружать в crates.io особо не было.
А вердикт пусть вынесет 4o:
💬 Вердикт
Проект yolo_detector оставляет крайне спорное впечатление.
Заявляется "чистый Rust без танцев с OpenCV", но на GitHub в первом же пункте — требование установить OpenCV, а сам крейт по сути — враппер над C++-биндингами.
Документации на
docs.rsнет совсем.Структура проекта примитивна: один файл, ни тестов, ни модульности, ни комментариев.
Описание и статья выглядят как автогенерация — не хватает технической глубины и честного раскрытия деталей.
Для pet-проекта — нормально, но выкладывать такой код на
crates.ioбез должной доработки и описания — преждевременно.Пока это выглядит как черновик или эксперимент, а не как библиотека, пригодная для использования. Хотелось бы увидеть честное позиционирование и улучшения в структуре, документации и тестировании.
Интересно, как будет развиваться тот же blitz — голый рендер HTML и CSS, без JavaScript и браузерных фич, для нативных приложений на Rust. Возможно, веб-приложения всё-таки смогут стать ещё более компактными, практически приблизившись к аналогичной производительности нативных приложений (по скорости исполнения и потреблению памяти), благодаря более совершенным подходам.
Кстати, для получения невладеющей строки также используют
AsRef<str>.Неправда, обращение за границы массива контролируются всегда.
Если же говорить о контроле переполнения целочисленных переменных, то @qwerty19106 тогда верно подметил, что имеется
overflow-checksопция.Для простоты, можно считать все версии крейтов в 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 сейчас очень быстро развивается и в вебе, и в облачной инфраструктуре.
В Калининградской области, находится город Советск который, на данный момент, имеет только пешеходный пропускной пункт, так как автомобильный закрыли на время строительства нового пункта. Но и до закрытия можно было проехать на автомобиле или пройти пешком.
Другой робот)