Rust всемогущий: ищу истории успеха

Ты сильно удивишься, но в расте всё это тоже можно. Но с страданиями.

• malloc/free - можно как системный вызвать, так и обернуть в аллокатор, но дальше мудохайся сам
• new/delete - в чистом виде всё же нет, за счёт отсутствия явных конструкторов. Но тут могу обмануть, я некоторые детали помню плохо
• raii - Box
• шаредптр - (A)Rc и все-все-все
• арены - пример https://github.com/fitzgen/bumpalo
• гц - https://github.com/Manishearth/rust-gc
• не использовать динамическую память - no_std и поехали. Разницы с си - никакой. А вот плюсам без динамической памяти, на моей памяти было очень плохо, как раз из-за new/delete прибитых гвоздями.

с постоянным переделыванием архитектуры

прототипирование на расте это больно, факт. А вот когда у тебя уже есть MVP и поиск архитектуры в основном закончен, можно уже пилить на расте, не страдая от постоянного перелопачивания.

как раз из-за new/delete прибитых гвоздями.

глобально переопределяешь malloc/free если охота аллокировать извращенными способами.

GPT-4 отвечает.

На языке Rust написано множество open-source проектов. Вот несколько заметных примеров:

• Servo: Экспериментальный веб-движок, разработанный Mozilla Research, который предлагает параллелизм и улучшенную безопасность. (https://github.com/servo/servo)
• RustPython: Реализация интерпретатора Python 3, написанная на Rust, с целью обеспечить высокую производительность и безопасность. (https://github.com/RustPython/RustPython)
• tokio: Событийно-ориентированная платформа для написания асинхронных приложений на Rust. (https://github.com/tokio-rs/tokio)
• actix-web: Мощный, простой в использовании веб-фреймворк, созданный с использованием акторной модели. (https://github.com/actix/actix-web)
• Redox: Операционная система, написанная на Rust, с акцентом на безопасность, устойчивость и простоту. (https://github.com/redox-os/redox)
• ripgrep: Очень быстрый поиск строк с использованием регулярных выражений, который соперничает с утилитами, такими как grep и ag. (https://github.com/BurntSushi/ripgrep)
• Alacritty: Минималистский кросс-платформенный эмулятор терминала с упором на производительность. (https://github.com/alacritty/alacritty)
• wasm-pack: Инструмент для сборки, тестирования и публикации Rust-кода, скомпилированного в WebAssembly. (https://github.com/rustwasm/wasm-pack)
• Amethyst: Игровой движок, написанный на Rust, основанный на компонентной архитектуре и предлагающий различные возможности для создания игр. (https://github.com/amethyst/amethyst)
• deno: Безопасная среда выполнения JavaScript и TypeScript, написанная на Rust и основанная на движке V8. (https://github.com/denoland/deno)

На языке программирования Rust написано множество open-source библиотек, которые предоставляют различные функциональные возможности. Ниже представлены некоторые из них:

• serde (https://github.com/serde-rs/serde) - библиотека для сериализации и десериализации структур данных.
• async-std (https://github.com/async-rs/async-std) - альтернатива Tokio, асинхронная библиотека стандартных функций.
• rocket (https://github.com/SergioBenitez/Rocket) - веб-фреймворк, удобный в использовании и с сильной типизацией.
• diesel (https://github.com/diesel-rs/diesel) - ORM и библиотека для работы с базами данных, поддерживает PostgreSQL, MySQL и SQLite.
• clap (https://github.com/clap-rs/clap) - библиотека для разработки интерфейсов командной строки (CLI). reqwest (https://github.com/seanmonstar/reqwest) - асинхронная HTTP-клиентская библиотека.
• regex (https://github.com/rust-lang/regex) - библиотека для работы с регулярными выражениями.
• mio (https://github.com/tokio-rs/mio) - метаплатформа для низкоуровневой асинхронной ввода/вывода в Rust.

Это только некоторые примеры библиотек на Rust. Сообщество Rust активно развивается, и на GitHub можно найти множество других проектов, которые подходят под различные нужды разработчиков.

Язык Rust используется для написания драйверов, операционных систем и другого низкоуровневого кода. Rust обладает множеством характеристик, которые делают его привлекательным для подобных задач:

• Безопасность памяти: Rust предлагает систему собственности и контроля времени жизни (lifetimes), которая позволяет избегать многих проблем, связанных с памятью, таких как разыменование нулевых указателей и гонки данных.
• Низкий уровень абстракции: Rust обладает возможностью написания кода с низким уровнем абстракции, аналогичным C и C++. Это позволяет разработчикам контролировать системные ресурсы, такие как память и процессорное время, с высокой точностью.
• Встроенная поддержка FFI (Foreign Function Interface): Rust упрощает интеграцию с кодом на других языках, таких как C и C++, что полезно при разработке драйверов и операционных систем, где такой код может быть необходим.
• Отсутствие сборки мусора: Rust не имеет встроенного сборщика мусора, что делает его подходящим для системного программирования, где детерминированное управление ресурсами имеет большое значение.
• Минимальный размер среды выполнения: Rust имеет минимальную среду выполнения, что позволяет создавать компактные и эффективные исполняемые файлы, подходящие для низкоуровневого кода.

Вот несколько примеров проектов и библиотек:

• Redox OS (https://www.redox-os.org/): Операционная система, разрабатываемая полностью на Rust, включая драйверы и ядро операционной системы.
• Tock OS (https://www.tockos.org/): Операционная система для встраиваемых систем на базе микроконтроллеров, написанная на Rust.
• rCore (https://github.com/rcore-os/rCore): Экспериментальное ядро операционной системы, основанное на основе ядра Linux, написанное на Rust.
• Rust Audio (https://github.com/RustAudio): Набор библиотек и инструментов для работы с аудио, включая низкоуровневые драйверы аудиоустройств.
• Rust-HIDAPI (https://github.com/oakey22/rust-hidapi): Библиотека для работы с устройствами, подключаемыми через интерфейс USB HID, такими как мыши, клавиатуры и геймпады.
• Rust-VDPAU (https://github.com/arcnmx/vdpau-rust): Библиотека для работы с драйверами видео ускорения через VDPAU (Video Decode and Presentation API for Unix) на Rust.
• stm32-rs (https://github.com/stm32-rs/stm32-rs): Набор библиотек для работы с микроконтроллерами STM32 на Rust.
• RustHID (https://github.com/rustrli/RustHID): Набор библиотек для разработки драйверов HID-устройств на Rust.

Существуют бенчмарки производительности кода на Rust, которые позволяют оценить его эффективность по сравнению с другими языками программирования. Вот несколько примеров и источников для бенчмарков:

• The Computer Language Benchmarks Game (https://benchmarksgame-team.pages.debian.net/benchmarksgame/): Этот проект предоставляет набор бенчмарков для различных языков программирования, включая Rust, C, C++, Java, Python и других. Он сравнивает производительность, использование памяти и размер исполняемого кода.
• Rust Performance Book (https://nnethercote.github.io/perf-book/): Это онлайн-руководство по оптимизации производительности Rust, написанное Николасом Нетеркотом, одним из ведущих разработчиков Rust. В нем приведены различные примеры и техники оптимизации кода на Rust.
• Criterion.rs (https://github.com/bheisler/criterion.rs): Это библиотека для написания бенчмарков на Rust, которая предоставляет удобный и мощный инструментарий для измерения производительности кода и анализа результатов.
• cargo-bench (https://doc.rust-lang.org/cargo/commands/cargo-bench.html): Встроенная команда cargo для запуска бенчмарков в Rust-проектах. С ее помощью можно написать и запустить бенчмарки для своих Rust-проектов и измерить их производительность.

Важно отметить, что бенчмарки производительности могут варьироваться в зависимости от множества факторов, таких как архитектура процессора, оптимизации компилятора, алгоритмы и т.д. Поэтому результаты бенчмарков следует рассматривать как один из аспектов оценки производительности языка, а не как единственный критерий выбора языка программирования.

Дело не в аллокациях, а что плюсы на тех же контроллерах без вот этого всего просто не летят. Ну то есть хотя бы заглушку, но подсунуть надо.

new/delete - это просто динамическое создание обьектов и их уничтожение. если тебе этого не надо, то не надо и это использовать. создавай обьекты статически или на стеке. динамическое создание нужно если только памяти не хватает создать иными способами все нужные тебе обьекты. в мк обычно можно обойтись и без кучи.

если же ты пользуешь внешние либы которые делают new - тогда malloc/free ты должен дать, каким хочешь способом, или стандартной кучей или своей кучей.

Так, да не так. У тебя new/delete часть языка и даже если под ними malloc/free нет, тебе всё равно нужно притащить за собой немного бойлерплейта под них. Хотя бы панику сделать при их использовании.

Ну и в целом, плюсы в таком окружении в итоге обычно сводятся к си с классами и шаблонами. Это не плохо, можно сильно удобнее чем на голом си писать, но за используемыми фичами приходится следить.

У тебя new/delete часть языка и даже если под ними malloc/free нет, тебе всё равно нужно притащить за собой немного бойлерплейта под них. Хотя бы панику сделать при их использовании.

любой вызов new/delete просто не слинкуется, поскольку нет символа malloc/free (если ты забанил рантайм), поскольку код new вызывает malloc.

тебя линкер ругнет - нет символа malloc, и повернется к лесу передом, к тебе задом.

ЕМНИП у тебя вообще плюсовый код не слинкуется если у тебя нет бойлерплейта под new/delete. Я это трогал очень давно, может с тех пор что-то изменилось, но помню что с этим были небольшие танцы.

Даже без явного вызова.

tinygo - глубоченная альфа,

Да, но попытки (успешные) делались давно, жаль, что гугл выпилил.

причём сам концепт go на контроллеры ложится так себе

Для аппаратуры связи - самое то. Не даром на нём пока ещё поддерживают https://github.com/brocaar/chirpstack-network-server

С другой стороны, более новые версии сделаны на Rust

Для чего было переписывать, - не понятно, и так всё работало…

Adacore как раз занались на пару с Ferrocene пилением раста под mission critical.

https://github.com/ferrocene/rust

https://github.com/ferrocene/specification

Чёт как-то там всё резко оборвалось! Месяцев 5 назад перестали зеркалить Rust, месяца 4 назад перестали пилить стандарт языка…

Очень жаль, в отличии от раст-коммьюнити они пилили именно стандарт языка, который можно было бы протолкнуть в ISO и иметь независимые реализации…

Для аппаратуры связи - самое то.

С ощутимыми нюансами как по мне. Но Lorawan NS - это вообще довольно наркоманская штука так-то, там своя атмосфера.

Для чего было переписывать, - не понятно, и так всё работало…

Тут не знаю, возможно Орне просто упёрся в лимиты го и решил что MVP пора переделывать на rust. Хрен его знает. Растовую версию не видел, гошная была норм.

Чёт как-то там всё резко оборвалось!

Есть подозрение, что они поняли в какую глубину жопы вписались, либо в современных реалиях Adacore решили свернуть непрофильную деятельность.

протолкнуть в ISO и иметь независимые реализации

Как по мне ещё рано, язык ещё ощутимо шатает из стороны в сторону, я уже про это писал. С ненулевой вероятностью, кстати, могли начать пилить что-то вообще отдельное посмотрев на раст и его недостатки.

For ChirpStack v4, it was decided to use Rust rather than Go. This was not an easy choice and the arguments for this decision are debatable. However, as most code was touched during the ChirpStack Application Server and ChirpStack Network Server merge, it was the only moment to re-consider this. The Rust memory management prevents many memory related pitfalls and helps catching
bugs at compile time rather than runtime.

Собственно, походу Орне наелся null reference и решил дать шанс расту. Судя по тому что довёл до полноценного релиза - пока идёт неплохо.

Ну и кстати: «AdaCore joins the Rust foundation Feb 07, 2023» - возможно решили тащить усилия по подготовке спеки не отдельно, а прямиком в Rust foundation.

Ничего подобного. В плюсах можно маллок/фри нью/делит

Т.е. владение с ручным управлением

RAII и юникптр

Владение с автоматическим управлением

шаредптр на всё

Разделяемое владение с автоматическим управлением

арены

Ничем принципиально не отличается от new Foo[N], после которого ты можешь работать с отдельными элементами, даже с указателями на них, но остаётся где-то главный указатель, котоый владеет всем массивом, а массив владеет объектами в нём. Т.е. то же самое владение.

не использовать динамическую память

Вырожденный случай арен с выделением в виде стекфреймов.

гц

Вот это единственный реальный контрпример. Который в плюсах не используется.

Если что, концепция владения подразумевает две вещи:

• существование отношений владения между объектами (включение или особый владеющий указатель)
• все отношения владения составляют ациклический ориентированный граф

все отношения владения составляют ациклический ориентированный граф

double linked list этот стройный концепт как раз ломает. Так что хрен, а не ациклический.

double linked list … Так что хрен, а не ациклический.

все отношения владения

Дык, там не владение. Владеет контейнер, всеми нодами.

У тебя mutable pointer, он за собой владение подразумевает.

Ну либо придётся подумать, как без этого добиться O(1) вставки в середину, для чего собственно списки и нужны.

double linked list этот стройный концепт как раз ломает

Необязательно. Если колхозить из говна и палок интрузивных список, то в двусвязном списке один указатель (например вперёд) делается владеющим, а обратный - не владеющим. Но на практике такое приведет к переполнению стека при вызове дектрукторов нод большого списка, да и операции типа «грохнуть весь оставшийся список» не то что бы очень полезные по сравнению с удалением одного элемента. Поэтому библиотечные реализации делаются в виде контейнера, который владеет всеми нодами.

как в исполняемый файл запихнуть .txt что бы он внутри был а не снаружи?

У тебя mutable pointer, он за собой владение подразумевает.

Raw pointer не подразумевает ничего. О чём Вы?

Но на практике такое приведет к переполнению стека

Ну бред же. Откуда дровишки?

Разве это не очевидно? Деструктор первой ноды вызывает декструктор входящего в его состав unique_ptr, который выполняет delete, который вызвает деструктор второй ноды, при этом стекфрейм деструктора первой ноды всё ещё не освобождён.

Разве это не очевидно? Деструктор первой ноды вызывает декструктор входящего в его состав unique_ptr, который выполняет delete, который вызвает деструктор второй ноды, при этом стекфрейм деструктора первой ноды всё ещё не освобождён.

У Вас каша в голове. Я не шучу.

Отличный способ вести техническую дискуссию.

Отличный способ вести техническую дискуссию.

Что не так? Готов ответить за каждое слово.

Ты не готов, просто хорохоришься. Впрочем, никто тебя к ответу призывать не будет, просто попробуй создать такой интрузивный список на десяток миллионов записей и потом грохни чисто силами дефолтного деструктора

Ты не готов

Готов.

просто хорохоришься.

Нет.

Впрочем, никто тебя к ответу призывать не будет

Конечно нет.

просто попробуй создать такой интрузивный список на десяток миллионов записей

Ха.

и потом грохни чисто силами дефолтного деструктора

Вы не понимаете как оно работает. Я так думаю.

Ещё раз повторяю, отвечальщик, никто за твоей жопой не придет, соответственно и смелость не впечатляет. Просто проверь. Или загугли по linked list unique_ptr stack overflow.

Но на практике такое приведет к переполнению стека при вызове дектрукторов нод большого списка.

Вот сие как раз и говорит о неадекватности модели «владения», реальным моделям данных.

то есть граф «владения» должен быть ациклическим и приемлемой длины, который можно безопасно обойти рекурсивно.

это камень в огород руста и всяких смартпоинтеров.

Просто проверь.

Блин. Почему Вы так стараетесь доказать что Вы, мягко говоря, не в теме? Я не шучу.

Расскажите мне какое отношение имеет single или double linked list к стеку?? Я весь внимания…

Или о неадекватности структуры «связный список». Любое решение имеет ограничения. Проблема стековерфлова решается, нужно просто ручками убрать рекурсию. Что-то типа while(next) next = std::move(next->next);

Расскажите мне какое отношение имеет single или double linked list к стеку??

япона мать! потому что деструктор обьекта содержащего смартпоинтер, сначала косвенно вызовет деструктор того, куда этот смарт указывает, и только потом завершится сам.

и это даже не хвостовая рекурсия,поскольку это делается перед вызовом самого тела деструктора.

Вот сие как раз и говорит о неадекватности

Примеры в студию, плз. Я, на самом деле, не думаю что имеются.

Двусвязный список, как не странно, это частный случай односвязного, в который добавили невладеющий указатель на предыдущую ноду + код для обновления его при изменении списка. Все проблемы характерные для уничтожения односвязного списка характерны и для двусвязного

Примеры в студию, плз.

сначала разберись как функции друг друга вызывают, чувак

япона мать! потому что деструктор обьекта содержащего

Вы в очередной раз, мягко говоря, обосрались. Давайте - Вы меня трогать не будете, а я вас? И будет нам обоим счастье…

чувак

Рекомендую как минимум разобраться что это значит. Чтобы не попадать в просак.

Или о неадекватности структуры «связный список».

неа. это не «связный список», а частный случай циклической ссылки. цикличность могда бы быть и пострашней, типа косвенной через промежуточные ссылки.

что вы все привязались к этому списку

Чтобы не попадать в просак

да уйди ты нахер, йобнутый клоун. хоть бы раз что по делу сказал.

Да, тут только вышел из спячки, форум не читал особо последние лет 5, в гугле тоже забанили и в местном поиске особо ничего не нашёл

Шутка

Какая драма (Шекспир плачет от зависти)!

Удалить не удастся.

ты разобрался как деструктор работает, багсеттер?

тебя забанить надо, чтобы людям не мешал. ты типичный спойлер.

Двусвязный список, как не странно, это частный случай односвязного

Работа с объектами сравнима с алфавитом языка.
Если буквы знаешь (стандартные объекты), то можно из них, создать какое-нибудь слово.
Плохо, когда программист «не умеет читать».

япона мать! потому что деструктор обьекта содержащего смартпоинтер, сначала косвенно вызовет деструктор того, куда этот смарт указывает, и только потом завершится сам

Этот порядок характерен для вызова конструкторов, деструкторы вызываются в обратном. Так что в теории хвостовая оптимизация могла бы помочь. Но для этого необходимо чтоб:

• Компилятор поддерживал хвостовую оптимизацию
• Деструктор смартпоинтера заинлайнился, чтоб компилятор видел что в конце концов деструктор вызывает сам себя
• Деструктор ноды не был бы виртуальным
• Он оказался бы последним, что не факт, так как внутри полезных данных ноды могут быть другие классы с деструктором, те же смартпоинтеры.

В общем надеяться на то что компилятор сам всё разрулит не стоит.

ты типичный спойлер.

От классического неудачника слышу. В спец-топик уже доложили?

Этот порядок характерен для вызова конструкторов, деструкторы вызываются в обратном.

это понятно…это я только проснулся :) , понятно поля после тела. но это не спасает ситуации

ты, класический удачник, без беготни с докладами наверх, жить не можешь… о сколько я таких в жизни перевидал.

по теме говори. ты рекурсию увидел или нет?

да уйди ты нахер, йобнутый клоун.

Слюнкой там не захлебнитесь, а то я переживать начал…

хоть бы раз что по делу сказал.

Не вам с вашим IQ стоит оценивать.

В общем надеяться на то что компилятор сам всё разрулит не стоит.

слабость концепции «владения» в том, что поинтеры в данных отражают не только отношение «владения», но и отношения «порядка» или «логической связи». и это все пытаются запихнуть во «владение», а оно туда не лезет.

между элементами списка существует отношение порядка, но не отношение «владения». тут владение натянуто на глобус. отчего возникают концептуальные проблемы и все эти рекурсии.

Не вижу проблемы вообще. Вот предположим есть у нас аренный аллокатор. Ты заказываешь арену, получаешь её идентификатор, простой инт, потом создаёшь объекты в этой арене и получаешь указатели на них. Всё, у тебя владение осуществляется через арену, в нашем примере через её целочисленный идентификатор, а доступ через указатели. Так же владение может осуществляться через включение в виде поля или элемента массива. Владение - это вообще семантическое понятие, node* ptr; // don't forget to free this - пример владения в сишечке. То что чаще всего владение осуществляется через включение или смартпоинтер - это просто вопрос удобства. Отношение владения просто позволяет декомпозировать сложную структуру на локальные простые кирпичики.