npm install -g nushell установит растовую программу nushell. Опять не "только".
pip install cmake насколько помню, CMake не на питоне написан.
Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
cargo - это образец UX. Некоторые люди на раст пересаживаются только из-за cargo. Подражатель cargo, uv для питона всего лишь год назад появился, а уже дает 10% обращений к PyPI.
nix и vcpkgs - это пакетные менеджеры. Мне как разработчику нужно от них одно: установка зависимостей проекта.
Давно уже не бывает "только C++".
Мне стало интересно, я даже попробовал "vcpkg install что-угодно". Установка все такая же шуточная с клонированием репы и запуском вручную каких-то скриптов, с последующим ручным прописыванием PATH.
Смешно стало с момента когда пакетный менеджер попросил установить зависимости для себя.
Опять вы ошиблись, написав "Непонятно осознаете ли вы, что сравниваете теплое с мягким." к моему "Я даже make и cmake не нашел в репозитории." Не знаете что vcpkg умеет приносить CMake?
Конец простой:
Пакетный менеджер который не может собрать пакет из своего репозитория - это шутка. Но ладно, раз сегодня нам смешно избивать лежачего, поэтому ставим руками autoconf, запускаем:
Окей, еще libtool.
Вот так, всего за полчаса и десяток ручных действий мы смогли собрать программу из репозитория vcpkg.
nix: initial release: June 15, 2003 projects total: 107 989
Кто еще велосипед))
vcpkg, conan - это все запорожцы в мире пакетных менеджеров. Как-то они работают, умеют делать минимальную работу, но шаг влево-вправо и нужен уже другой тулинг.
vcpkg install bash - упс, уже не работает. Даже воспроизводимый bash-скрипт в репозиторий уже не положишь. vcpkg install mdbook - упс, HTML документацию из Markdown без костылей вы уже не сгенерируете. cargo, npm итд в vcpkgs тоже нет, использовать Rust, JS, TS, Python и другие языки без костылей не получится.
Лучше тем, что в языке есть async, причём не прибитый гвоздями, а с возможностью кастомной реализации планировщика, чем и воспользовались embassy.dev
Лучше тем, что легче, меньше кода и полностью пропадает нужна в ОСРВ. А раз нет ОСРВ, то бинарник меньше, а прерывания он обрабатывает быстрее.
loop {
// Timekeeping is globally available, no need to mess with hardware timers.
led.set_high();
Timer::after_millis(150).await;
led.set_low();
Timer::after_millis(150).await;
}
Все изначально так и было. Мейк, симейк и прочее были разработаны в другую эру, когда сложность была совсем другой, а для установки зависимостей хватало системного пакетного менеджера. И вот с функцией пакетника или сложной, многоязыковой сборки они не справляются. И это не лучшее что есть на рынке. Есть bazel, nix, meson. Это для любых языков. Для раста есть cargo который лучше любого на голову, но любой шаг за пределы растовой экосистемы - и ты уже пишешь свой nix или bazel. В 2025 без владения инструментами для современных задач сложной сборки никуда. А попытки натянуть старье на новые задачи, а особенно написать сборку на питоне "потому что он простой, понятный и доступный всем" ВСЕГДА заканчиваются переизобретением nix и bazel, которые работают быстрее и решают задачу в несколько строк кода на своём языке, который изначально спроектирован под управление пакетами. Особенно когда дела доходят до сборки и тестирования в ВМ.
perl никуда не выстрелил, tiobe показывает погоду на луне. Перлисты буквально по приколу накрутили рейтинг, потому что сделать это очень легко, ведь tiobe тупо считает поисковые запросы
The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where readily available alternative memory-safe languages could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.
For existing products written in memory-unsafe languages, not having a published memory safety roadmap is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety. The memory safety roadmap should outline the manufacturer’s prioritized approach to eliminating memory safety vulnerabilities in priority code components written in memory unsafe languages (e.g., network-facing code or code that handles sensitive functions like cryptographic operations). Manufacturers should demonstrate that the memory safety roadmap will lead to a significant, prioritized reduction of memory safety vulnerabilities in the manufacturer’s products and demonstrate they are making a reasonable effort to follow the memory safety roadmap. Publication of a memory safety roadmap does not apply to products that have an announced end-of-support date that is prior to Jan. 1, 2030.
где есть ресурсы и готовность строить весь проект вокруг Rust
Да, Россия - технологически отстающая страна, мы знаем. Только раст, его тулчейны и тем более сертификация тут вообще не при чем.
Большинство реальных промышленных проектов до сих пор пишется на C
Citation needed. В тех же США начиная со следующего года это законодательно запрещено.
JsonX как раз и родился из практики: "староверы на C" сталкиваются не с отсутствием JSON, а с болью интеграции его в RTOS-среды с контролем памяти
Не понимаю про что вы говорите. Эмбеддед - это такой же обычный си, в большинстве случаев собираемый мейнлайновым gcc и остальным гнутым тулчейном. Разница только в реализации принтов, флотов, да аллокатора, которые поддельные из-за того что си никогда не проектировался под эмбеддед, и получились костыли.
cJSON который вы оборачиваете дёргает аллокатор, работа которого на МК нежелательна.
Никогда прошивка с аллокацией на каждый чих не пройдёт никакую строгую сертификацию, так что непонятно зачем вы про серты вообще упоминаете.
Если спрос на такую функциональность окажется высоким - развитие пойдёт в эту сторону
Те, кто просветился и перешёл на json на МК уже давно пишут на Rust с serde. А староверам до вашего джейсона нет дела, а даже если есть - он не умеют подключать библиотеки и напишут свою кривую безаллокационную реализацию
Кристина, огромное вам спасибо за эту статью! Отличные замечания, поправив которые можно сделать продукт лучше. Мне особенно понравилась часть про унификацию нейминга. То что вы даёте примеры - бесценно. Требования к качественному UI везде одинвковые: и в узкоспециализированом продукте и в масс-макете.
Таких статей очень не хватает в русскоязычном сегменте, было бы классно почитать ещё подобные разборы российских разработок.
Не увидел сравнения с nix. Для сборки си/с++ он подходит идеально, потому что в nixpkgs есть все мыслимые и немыслимые библиотеки и зависимости, вероятность того что нужно будет руками пакетировать что-то крайне мала. Повторяемость из коробки.
Я в этом году плотно начал пользоваться nix и всем советую. uv, poetry - все это лишь подделки под часть функционала nix. Главная проблема - они не могут приносить зависимости извне репозитория PyPi. То есть если вам нужно скомпилять что-то на с++ и этого нет в репо, то упс, добро пожаловать в костыли. Или, чаще всего - работа в dev container, что крайне неэргономично.
Nix же не зависит от языка: он может приносить зависимости и собирать что угодно, плюс прекрасно поддерживается direnv + vscode.
Мы не пишем код для машин. Машины понимают практически любой код, даже такой https://www.ioccc.org/
Код, который существует в текстовом виде и тот, который исполняется машиной могут очень сильно отличаться после оптимизации, даже по алгоритму и характеру выполняемой работы.
Удивительным образом "хороший" код, понятный людям без подсказок в подавляющее большинстве случаев - корректный.
А отношение других людей к вашим мыслям и статьям достаточно отражено в комментариях и оценках.
Тоже склоняюсь к такому мнению. Особенно мне нравится часть про идеи, которые обогнали время. Ох, у меня столько идей, которые обогнали время, и повербанки и портативные колонки я изобрёл и даже прототипы делал в нулевых. И телеграм придумал. Только есть нюанс: идеи вообще ничего не стоят. Прототип имеет небольшую ценность. Собрать команду, долго и упорно работать, вывести продукт на рынок, произвести его массово, поддерживать - вот здесь 99% ценности. Таких мамкиных гениев вроде меня тысячи и миллионы.
Обожаю ещё вот эту часть про то как злое начальство заставило копировать IBM/360, вместо своих разработок. Так может просто свои разработки не работали и нам это недоговаривают? Удивительно что с той стороны возможность легально производить копии IBM PC привела к революции домашних ПК.
А троичные вычисления в итоге выстрелили (см. Microsoft BitNet) и сейчас будут делать под это железо. Мы могли быть впереди, но опять что-то помешало.
Почитал всю ветку и так вас и не понял. Что такое теплое и мягкое? Вы пытаетесь что-то сказать, но не можете. Не томите, здесь все свои.
Сможете объяснить в чем неадекватность и какой контекст разговора. На всякий случай, для контекста "vcpkg install что-угодно".
В чем неадекватность? Как vcpkg решает проблему работы clang-format который мне нужен для ежедневной разработки на С++?
Лучше проверять, прежде чем писать. А то может случиться конфуз:
На crates.io живет множество не-Rust проектов. Вы спрашивали про Qt? https://github.com/KDAB/cxx-qt/
npm install -g nushellустановит растовую программу nushell. Опять не "только".pip install cmakeнасколько помню, CMake не на питоне написан.cargo - это образец UX. Некоторые люди на раст пересаживаются только из-за cargo. Подражатель cargo, uv для питона всего лишь год назад появился, а уже дает 10% обращений к PyPI.
nix и vcpkgs - это пакетные менеджеры. Мне как разработчику нужно от них одно: установка зависимостей проекта.
Давно уже не бывает "только C++".
Мне стало интересно, я даже попробовал "vcpkg install что-угодно". Установка все такая же шуточная с клонированием репы и запуском вручную каких-то скриптов, с последующим ручным прописыванием PATH.
Смешно стало с момента когда пакетный менеджер попросил установить зависимости для себя.
Ну ничего, `nix shell nixpkgs#zip` поехали дальше:
Опять вы ошиблись, написав "Непонятно осознаете ли вы, что сравниваете теплое с мягким." к моему "Я даже make и cmake не нашел в репозитории." Не знаете что vcpkg умеет приносить CMake?
Конец простой:
Пакетный менеджер который не может собрать пакет из своего репозитория - это шутка. Но ладно, раз сегодня нам смешно избивать лежачего, поэтому ставим руками autoconf, запускаем:
Окей, еще libtool.
Вот так, всего за полчаса и десяток ручных действий мы смогли собрать программу из репозитория vcpkg.
Конечно, всего этого можно было бы избежать, если установить vcpkg через nix, благо у них есть рецепт со всеми зависимостями прямо в репозитории https://github.com/microsoft/vcpkg/blob/master/shell.nix
"vcpkg install что-угодно, господи"
vcpkgs:
initial release: 2016
projects total: 2 471
nix:
initial release: June 15, 2003
projects total: 107 989
Кто еще велосипед))
vcpkg, conan - это все запорожцы в мире пакетных менеджеров. Как-то они работают, умеют делать минимальную работу, но шаг влево-вправо и нужен уже другой тулинг.
vcpkg install bash- упс, уже не работает. Даже воспроизводимый bash-скрипт в репозиторий уже не положишь.vcpkg install mdbook- упс, HTML документацию из Markdown без костылей вы уже не сгенерируете.cargo, npm итд в vcpkgs тоже нет, использовать Rust, JS, TS, Python и другие языки без костылей не получится.
Хотите указать версию boost? Это уже не так просто https://learn.microsoft.com/en-us/vcpkg/users/examples/modify-baseline-to-pin-old-boost
Используете QEMU? Его тоже нет в vcpkgs, а ведь это стандартный тулинг разработчика и тестировщика.
Я даже make и cmake не нашел в репозитории. Что с компиляторами тоже непонятно.
Что там с бинарным кешировнием?
Лучше тем, что в языке есть async, причём не прибитый гвоздями, а с возможностью кастомной реализации планировщика, чем и воспользовались embassy.dev
Лучше тем, что легче, меньше кода и полностью пропадает нужна в ОСРВ. А раз нет ОСРВ, то бинарник меньше, а прерывания он обрабатывает быстрее.
Все изначально так и было. Мейк, симейк и прочее были разработаны в другую эру, когда сложность была совсем другой, а для установки зависимостей хватало системного пакетного менеджера.
И вот с функцией пакетника или сложной, многоязыковой сборки они не справляются.
И это не лучшее что есть на рынке. Есть bazel, nix, meson. Это для любых языков.
Для раста есть cargo который лучше любого на голову, но любой шаг за пределы растовой экосистемы - и ты уже пишешь свой nix или bazel.
В 2025 без владения инструментами для современных задач сложной сборки никуда. А попытки натянуть старье на новые задачи, а особенно написать сборку на питоне "потому что он простой, понятный и доступный всем" ВСЕГДА заканчиваются переизобретением nix и bazel, которые работают быстрее и решают задачу в несколько строк кода на своём языке, который изначально спроектирован под управление пакетами.
Особенно когда дела доходят до сборки и тестирования в ВМ.
perl никуда не выстрелил, tiobe показывает погоду на луне.
Перлисты буквально по приколу накрутили рейтинг, потому что сделать это очень легко, ведь tiobe тупо считает поисковые запросы
Но у нас уже есть nixos с 20к настроек декларативных https://search.nixos.org/options?
https://www.cisa.gov/resources-tools/resources/product-security-bad-practices#:~:text=manufacturers should avoid.-,Product Properties,safety vulnerabilities in priority code components written in memory unsafe languages.,-CWE (Common%20Weakness
Да, Россия - технологически отстающая страна, мы знаем. Только раст, его тулчейны и тем более сертификация тут вообще не при чем.
Citation needed. В тех же США начиная со следующего года это законодательно запрещено.
Не понимаю про что вы говорите. Эмбеддед - это такой же обычный си, в большинстве случаев собираемый мейнлайновым gcc и остальным гнутым тулчейном. Разница только в реализации принтов, флотов, да аллокатора, которые поддельные из-за того что си никогда не проектировался под эмбеддед, и получились костыли.
cJSON который вы оборачиваете дёргает аллокатор, работа которого на МК нежелательна.
Никогда прошивка с аллокацией на каждый чих не пройдёт никакую строгую сертификацию, так что непонятно зачем вы про серты вообще упоминаете.
Те, кто просветился и перешёл на json на МК уже давно пишут на Rust с serde. А староверам до вашего джейсона нет дела, а даже если есть - он не умеют подключать библиотеки и напишут свою кривую безаллокационную реализацию
Кристина, огромное вам спасибо за эту статью!
Отличные замечания, поправив которые можно сделать продукт лучше. Мне особенно понравилась часть про унификацию нейминга. То что вы даёте примеры - бесценно.
Требования к качественному UI везде одинвковые: и в узкоспециализированом продукте и в масс-макете.
Таких статей очень не хватает в русскоязычном сегменте, было бы классно почитать ещё подобные разборы российских разработок.
Не увидел сравнения с nix.
Для сборки си/с++ он подходит идеально, потому что в nixpkgs есть все мыслимые и немыслимые библиотеки и зависимости, вероятность того что нужно будет руками пакетировать что-то крайне мала. Повторяемость из коробки.
Я в этом году плотно начал пользоваться nix и всем советую.
uv, poetry - все это лишь подделки под часть функционала nix.
Главная проблема - они не могут приносить зависимости извне репозитория PyPi. То есть если вам нужно скомпилять что-то на с++ и этого нет в репо, то упс, добро пожаловать в костыли. Или, чаще всего - работа в dev container, что крайне неэргономично.
Nix же не зависит от языка: он может приносить зависимости и собирать что угодно, плюс прекрасно поддерживается direnv + vscode.
Мы не пишем код для машин. Машины понимают практически любой код, даже такой https://www.ioccc.org/
Код, который существует в текстовом виде и тот, который исполняется машиной могут очень сильно отличаться после оптимизации, даже по алгоритму и характеру выполняемой работы.
Удивительным образом "хороший" код, понятный людям без подсказок в подавляющее большинстве случаев - корректный.
А отношение других людей к вашим мыслям и статьям достаточно отражено в комментариях и оценках.
Ваш комментарий настолько прекрасен, что захотелось с вами работать. Уверен, что раздолбов рядом не было бы)
Почему не подошло принести зависимости через nix, ну или как выше, собрать в докере?
Зумеры переизобрели thread pool? https://en.m.wikipedia.org/wiki/Thread_pool
Вижу что выше коллеги уже написали.
Чем не подошли уже существующие и готовые библиотеки?
Тоже склоняюсь к такому мнению.
Особенно мне нравится часть про идеи, которые обогнали время. Ох, у меня столько идей, которые обогнали время, и повербанки и портативные колонки я изобрёл и даже прототипы делал в нулевых. И телеграм придумал.
Только есть нюанс: идеи вообще ничего не стоят. Прототип имеет небольшую ценность.
Собрать команду, долго и упорно работать, вывести продукт на рынок, произвести его массово, поддерживать - вот здесь 99% ценности.
Таких мамкиных гениев вроде меня тысячи и миллионы.
Обожаю ещё вот эту часть про то как злое начальство заставило копировать IBM/360, вместо своих разработок. Так может просто свои разработки не работали и нам это недоговаривают? Удивительно что с той стороны возможность легально производить копии IBM PC привела к революции домашних ПК.
А троичные вычисления в итоге выстрелили (см. Microsoft BitNet) и сейчас будут делать под это железо. Мы могли быть впереди, но опять что-то помешало.
https://nixos.org/ удовлетворяет всем критериям
Библиотека, о которой вы возможно говорите https://libp2p.io/
Больше похоже на синтаксис объявления множеств в языке nix
set = { a = 1; b = list; }https://habr.com/ru/companies/typeable/articles/550860/