Вивчення Rust на практиці через переписування популярних CLI-команд з C
Привіт. Rust уже багато років поспіль є найулюбленішою мовою програмування згідно з результатами опитування Stack Overflow. Ба більше, великі ІТ-гіганти вже використовують Rust для критично важливих систем. Rust є в Windows, Rust є в Android. На Rust переписали Discord. І навіть існує офіційний AWS SDK для Rust. Тож і початківці, і досвідчені фахівці розглядають та вивчають Rust для свого подальшого розвитку й кар’єри.
Звісно, мову програмування потрібно вивчати на практиці. Один із хороших способів — узяти відому
Ви можете вибрати
- репозиторій Core Utilities на C: github.com/coreutils/coreutils
- та його реалізація на Rust: github.com/uutils/coreutils
Якщо ви вирішите вивчати Rust таким методом, я підготував таблицю з прикладами команд.
Епілог
Якщо буде інтерес до цієї теми, я доповню табличку новими командами з ваших коментарів.
Якщо вам цікаво, які компанії використовують Rust, ось список компаній.
Дякую Андрію за допомогу.
306 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментаріві досить очікувано що на практиці з початком використання раст тулз почали з’являтися новини як нп на phoronix з rust coreutils is causing major breakage for some executables (схоже щось зв’язано з різницею в поведінці розрахунків md5 цього разу)
Така собі ідея. Я б краще подивився на переписування ліб по типу curl або openssl, з якими постійно то API hell, то maintenance hell, то security hell.
krasche.a3.kyiv.ua
Очередную зраду принесли
https://lore.kernel.org/git/[email protected]/
Это действительно «зрада», но вполне ожидаемая 🙂Git-сообщество уже несколько лет обсуждает Rust и вот нконец таки они решились на первый «шарик-тест»: маленький патч, чтобы обкатать инфраструктуру и реакцию экосистемы. Смысл понятен:
Тестирование сборки и интеграции — Rust встраивают не ради хайпа, а чтобы заранее выстроить пайплайн, понять где ломается и как жить с новым тулчейном.
Переходный период для дистрибутивов — многие *BSD, embedded-сборки и экзотические платформы действительно не готовы к Rust-компилятору «из коробки». Поэтому им дают время подтянуть тулчейн.
Git 3.0 → Rust обязателен — это да, уже реально большой шаг. Как когда-то C89 → C99, теперь C/Rust гибрид.
С практической стороны разработчика:
Для пользователей наверное ничего не изменится в ближайшее время: Git не «переписывают на Rust», а добавляют отдельные куски, где Rust безопаснее или проще.
Для разработчиков дистрибутивов и CI — новые зависимости и потенциальная боль.
Для сообщества — сигнал, что даже такие консервативные проекты, как Git, переходят на Rust ради безопасности и поддержки новых поколений кода.
То есть «зрада» для тех, кто любит минимализм и portability любой ценой, и «перемога» для тех, кто устал от UB и сегфолтов 🙂
Аналіз Rust-аналогівCLI-утиліт
для ознайомлення глянув один приклад з бенчмарками — rg та grep:
для порівняння пошуку хочби для інтерпретації як результату (так і команд) по ідеї треба булоб навести output команд чи означити набір вхідних data
так для прикладу (у навмання взятій директорії з meson build):
Ваш приклад показує не «rg швидший/повільніший», а різницю у дефолтній поведінці інструментів. Тому бенчмарки «на колінці» без опису вхідних даних та опцій насправді нічого не доводять.Щоб отримати справедливе порівняння, треба вирівняти умови:
однаковий набір файлів, однакові ключі (рекурсія, бінарні файли, hidden), однакові фільтри .gitignore.
добре що здогадалися для чого то наведено принаймні для бенчмарк тестів, і чому бенчмарки можуть показати «швидше в тисячі разів», незважаючи що він і повинен в цілому бути швидшим за рахунок інших факторів і не дуже має сенсу отримувати тисячі наймовірніше за рахунок меншого об’єму пошуку
Де Rust справді доречний — це бінарники, що працюють на межі між правами звичайного користувача і привелійованого. Класичний приклад — sudo (setuid/’superuser do’). Там були реальні CVE(2021-3156), у цій утіліті корисно прибрати цілий клас багів, пов’язаним з доступом до пам’яті. Але для утиліт без привілеїв (умовний sort/sum/cksum, або FFMPEG, як тут пропонують — шо б шо?) загроза інша: не RCE, а ризик зламати сумісність, семантику та стабільність Unix-інструментів, яким десятки років. Переписуєш код — виникає нова поведінка, ломається сумісність з іншими утілітами, утіліта починає працювати не так, як раніше.
Модна хвиля «C страшно» не є технічним аргументом. Через 20 років усе одно доведеться підтримувати і C, і Rust, і змішаний зоопарк. Критерій переписування має бути простий: переписуємо там, де складна поверхня атаки.
Rust має бути інструментом, а не релігією. Security-ROI є в sudo-класах задач. Масовий перепис coreutils без чіткої загрози — це радше ризик рознести сумісність і продуктивність, ніж шлях до «безпечнішого Linux».
cksum implementation up to 17x slower than GNU for some large files github.com/...ils/coreutils/issues/8573
sort does not finish for large one line file — github.com/...ils/coreutils/issues/8583
blog.qualys.com/...low-in-sudo-baron-samedit
з coreutils сприйняття розробки як олімпіади
відредагував
це подивившись трохи коменти з github з «quick win» стратегією, що чимось нагадує конкурси чи олімпіади
Подход, описанный в статье о переписыванииCLI-команд с C на Rust, действительно имеет хлопцы, серьезные недостатки и говорит об отсутствии у автора инженерного мышления на высоком уровне. Далее я обосную, почему, с моей точки зрения, рефакторинг существующего кода был бы более эффективным способом изучения Rust:
CLI-утилиты, особенно из GNU Coreutils, содержат обработку множества граничных случаев, накопленных за десятилетия использования. Переписывая с нуля, легко упустить критически важные сценарии использования.
Проблемы подхода «переписывание с нуля»
1. Отсутствие контекста архитектурных решений
Когда вы переписываете программу с нуля, вы не понимаете, почему в оригинале были приняты именно такие архитектурные решения. Многие особенности кода на Cи связаны с управлением памятью, обработкой ошибок и производительностью — аспектами, которые в Rust решаются по-другому.
2. Пропуск важных edge cases
3. Неэффективное использование времени
Большая часть времени тратится на воссоздание базовой функциональности, а не на изучение идиоматичного Rust-кода и специфических особенностей языка.
Преимущества рефакторинга
1. Постепенное изучение концепций
Рефакторинг позволяет изучать Rust по частям: сначала ownership и borrowing, затем pattern matching, потом error handling, и так далее. Каждый этап дает конкретные знания.
2. Сравнение подходов
При рефакторинге вы непосредственно видите, как одна и та же задача решается в C и Rust, что дает глубокое понимание философии языков.
3. Сохранение работающей функциональности
Рефакторинг гарантирует, что все edge cases и особенности поведения сохранятся, а вы сосредоточитесь на изучении языка, а не на отладке логики.
Вот как нас хлопцы, заставляют делать на122-ой:
Используем уже существующий Rust-проект (например, из uutils/coreutils),
далее выбираем конкретную функциональность для улучшения или оптимизации,
изучаем текущую реализацию, что бы понять ше там за архитектурные решения применяются, проводим рефакторинг части кода, применяя более идиоматичные Rust-паттерны если необходимо, то добавляем новые функциональность, что бы улучшить производительность.
Такой подход дает более глубокое понимание Rust, как языка программирования со всеми вытекающими нюансами,обучает работать с существующими кодебазами (что критично для реальной разработки) и позволит внести реальный вклад в руст комьюнити!
Про какие «оригинальные архитектурные решения» можно говорить в коде, который писался с начала90-х?
ну код же не в 90х придумали писати, програмування існує з 60х років, і до 90х воно вже норм розвинулось, щоб з’явилися практики правильно-неправильно, і що краще.
Все самое ***енное было придумано и сделано в70-х. Все что после этого — пародия на классику и плагиат.
хмм.. цікавий погляд, тоді — rust то пародія чи плагіат з такої точки зору?
Цікава думка. А ти впевнений, що через 40 років хтось буде з таким же трепетом розбирати твій код, як зараз читають вихідники UNIX або алгоритми Кнута? Чи, може, твої pull request-и стануть обов’язковими кейсами в курсах CS50?
Бо поки що виглядає так, ніби ти просто вкотре обгортаєш CRUD у новий фреймворк і називаєш це «інновацією». Але хто зна, може, саме твій pipeline на YAML стане новим «The Art of Computer Programming».
То твердження прикладене до rust)
безвідносно «ти-ви-ми-вони»
Так всеж таки — відносно раст яка саме з опцій?
«Все самое ***енное» придумано в разное время. Что-то в40-х, что-то в 70-х, что-то в 2000-х и позже, что-то в промежутке между ними...70-е так вам показательны и почему отвергаете всё последующее?
Чем
Если вы переписываете «с нуля», есть риск выкинуть всё «старое» как ненужное и сделать красивую Rust-версию, но:122-й (или где-то в комьюнити) говорят: «изучайте существующую реализацию, а не переписывайте с нуля» — они толкают к тому, чтобы читать чужой код, уважать его историю и уметь работать в реальных кодебазах. Это навык, который отличает «инженера» от «кодера» или свитчернутого программиста!
она не будет полностью совместима с оригиналом;
часть edge cases потеряется;
и самое главное — вы не поймёте эволюцию решений, из-за чего в реальных продакшен-проектах потом сможете повторить те же ошибки.
Поэтому, когда у нас на
Речь идет о том, чтоб поведение программ было совместимым (что нужно делать), а не о том, что воспроизвести каждый из коммитов, сделанных с начала эпохи линукса.
Згоден, на Rust треба писати по іншому
Для навчання це не має значення, ми не плануємо отримати бізнес-рішення, ми плануємо розібратися.
Тут згоден, особливо у поєднанні з п. 1
Можно к вам на стажировочку попасть раст знаю на достаточном уровне для написания гарного кода. Или студентов вы не берете?
RUST позіціонується як «безпечна» мова розробки.
Жодна програма з coreutils не відповідає критерію небезпечності.
Чи ви вважаєте, що за допомогою утіліти sort можна захопити комп’ютер?
не реальная ценность Rust это не безопасность, а корректность
не самий переконливий приклад з «реальная ценность», та мабуть малось на увазі для runtime (не compiletime)
якщо брати випадки без використання asan — то корисні автоматичні перевірки потрохи мігрують і в сі, compiletime можна і зараз знайти (/Warray-bounds releases.llvm.org/...DiagnosticsReference.html), runtime cases додадуть судячи нп з clang.llvm.org/docs/BoundsSafety.html
Напишите лучше, если сможете конечно!
хто стверджує той обгрунтовує, і не в студентському стилі «компилятор не позволит» некоректність коньєчно)
Утилиты типа sort, cat, wc не представляют критических угроз безопасности. ЭтоCLI-инструменты для обработки текста, а не сетевые сервисы или системные демоны.
Реальная ценность Rust здесь не в «безопасности», а в:
Производительности (часто выше благодаря zero-cost abstractions)
Maintainability (современная экосистема, пакетный менеджер)
Корректности (отсутствие undefined behavior, лучшая обработка ошибок)
Аргумент «безопасности» для coreutils — это скорее понты, т.е. преувеличение Rust-сообщества.
Так краще, є пункти для розгляду з
«Реальная ценность Rust здесь»
Якщо порівняння відносно сі — за рахунок чого, а краще конкретні приклади такого прискорення. Бо якщо брати конкретику, то можна нп сказати що додаткові runtime перевірки (like bounds checking) явно не прискорюють виконання. А в питанні оцінювання загалом — чи дійсно цей перфоманс пункт має бути тут на першому місці у розгляді.
За відсутності стандартизації та підходу в стилі «якщо збирається значить все ок» — скоріш навпаки, дивіться нп різонінг з — bcachefs tools orphaning — що було в дебіан.
У випадку coreutils можливо так можливо ні, бо загальне твердження у цьому випадку потребує конкретизацію на прикладах coreutils тулз.
Взагалі-то можна (в загальному випадку): за рахунок помилки в даних, якісь рядки щезнуть, чи появляться фантомні, чи на деяких даних сортування буде некоректне (це наймовірніше за все). А місця для помилки є. Нагадую, що коли sort почала підтримувати Unicode, перша версія при увімкненій локалі UTF-8 працювала повільніше раз в тисячу, і потім їй спеціально лікували швидкість. А це — особливий код, в якому легко помилитись. Ви можете дати гарантію, що в сучасному sort нема нічого такого? А якщо там стануть обробляти за останніми стандартами Unicode, наприклад, порядок кольорів однотипних емоджі?
А якщо помилка є, то знайти, як через неї збити логіку і отримати своє — таких CVE вже декілька тисяч відомо.
І з іншими coreutils багато схожого. Наприклад, ось хтось захоче функціональність схожу на те, що в less:
-R or —RAW-CONTROL-CHARS
Like -r, but only ANSI «color» escape sequences and OSC 8 hyperlink sequences are output in «raw» form.
А це складний детект, помилитись дуже легко.
Звісно, від алгоритмичних помилок Rust не захистить напряму, а от від наслідків типу псування памʼяти — зможе.
ви почали рівняти баги рівня «щось не працює» до тих, через які можна отримати низькорівневий доступ до системи.
Переписати на іншу МП, що б десь колись мати можливість відразу сортувати без багів різнокольорові смайли, це доволі жирно.
Тобто, реальних причин — немає.
І це правильно. Почитайте описи CVE: там сотні прикладів, коли через «щось не працює» отримували такий доступ.
Наприклад, фільтрується список заборон. Помилка — заборону не знайдено — доступ дозволений.
Або дані зіпсовані, парсер їх не розбирає, і помилка в парсері (чи відсутність контролю за помилками) дає некоректний результат, дозвіл отримано.
Або, це вже зі власного досвіду: в скрипті неперевірений перехід на некоректно вираховане імʼя каталогу (якого нема), і файл розміщений там, де його не має бути ⇒ витік даних.
Сотні. Може, вже і тисячі описаних таких прикладів. Хакери дуже розумні і можуть кожний з них заексплуатувати, а скільки ще не відкритих zero day.
Ні, сувора реальна практика. Бази CVE відкриті, читайте...
По типу бага щось дуже схоже що нещодавно в коментах було... nvd.nist.gov/...uln/detail/CVE-2025-46717 — схожий випадок по суті? Якщо так — то як тут мова програмування допоможе запобігти тому?
Чим краще контроль типів, тим легше його налаштувати проти цілих класів помилок.
Малий приклад: ось є strtol() в C. Щоб акуратно перевірити всі випадки, що можуть бути з некоректним вводом даних, потрібно:
1) передати вказівник на вказівник на позицію endptr, і після перевірити, чи нема там зайвого;
2) перед викликом поставити errno в 0, бо якщо буде помилка, то його може ставити;
3) перевірити повернене на 0, а endptr на рівність ptr, щоб розділити випадки — коректний нуль, помилка, або пустий рядок;
4) якщо результат треба звузити до int, то перевірити коректність цього звуження.
99% програмістів нічого не перевіряють, бо це задовбує. Буде просто виклик з присвоєнням чомусь, і плювали вони на переповнення і некоректні дані.
Я буквально тиждень тому нарвався на код, що приймає на вход JSON і читає його, але замість повного парсингу шукає характерні рядки. Не розкриваючи деталей: хай він шукає 1) ключ foo з підключем bar, і 2) ключ buka з підключем foo. Код просто бере список можливих ключів і перебирає його. На вході є в повному JSON піделемент "buka":{"foo«:1, «moo»: 123}. Його читає нормально. Далі воно іде шукати ключ foo, находить рядок «foo», вважає, що найшло його, іде шукати {«bar»: після, не находить, пише про помилку і виходить... але значення для buka.foo і buka.moo вже призначені. Про те, що якщо парсінг не вдався, то не треба нічого призначати, там і не чули.
І майже весь код такої якости.
А все чому? Не хотіли автори підключати до кода C++ бібліотеку для JSON, бо це ж потім структури розбирати, а ще гарно було б схему додати...
Відповім вашими ж словами — зіпсувати можна все. Тому думаю що з використанням раст особливо на галерах (як і початківцями) — щоб тулза била по рукам під час кодування і після — цілком можна погодитись.
А як можливу альтернативу — розширену прогонку з інтерпретацію warn як error, плюс нп asan тестування. Також, як ніяк, а в питанні діагностики та відповідних тулз з сі — рух і розвиток є, в основному мабуть дякуючи гарному поштовху з сонного стану з появою нових мов альтернатив (чи точніше не появою, а їх використанням).
p.s.
при наявності достатньої кількості відтестованих json ліб, — так (без явної необхідності в тому) — невиправдано парсінг-велосипедами займатися (хоча простенький json output буває можна і самому згенерувати, бо значно менше де є помилитися)
Але коли мова дає легкі засоби не зіпсувати, і коли не дає, навпаки, прості засоби тільки погіршують — між цими варіантами прірва.
Угу, тут як завжди — поки конкуренти не покажуть, що можна все втратити, ніхто не ворухнеться.
... поки не доходить до практики як і подальшого розвитку/використання, де знаходять використання unsafe з одного боку, а з іншого — рух у напрямку відповідних safety фіч. І це навіть без розгляду tradeoffs, на які зазвичай не звертають увагу фокусуючись на чомусь одному як у цьому випадку.
Цілком природньо, так сказати опція — навіщо щось робити якщо можна не робити. Можна бачити деякі плюси наявності конкуренції.
Бо саме так це і працює в багатьох випадках: www.reddit.com/...hard_security_xpost_gifs
А якщо враховувати що достатньо нп crates використовують unsafe, то чи не буде все це в кінцевому вигляді таксамо зведено до якості тестування та поліровки роками?
Зіпсувати можна все. Додати 100500 крейтів з багами доступа до памʼяти — і результат гарантований.
Але коли їх таких обмежено мало і можна контролювати, в принципі щось таке є чи ні, то ефективність контролю може досягти потрібного рівню, і на порядки дешевше, ніж для мови, де фігню можна написати на будь-якому рівні.
І для цього не обовʼязково мати Rust. Java теж підійде, і навіть Python:) Але щоб ще й більш ефективно компілювалось — треба таки щось як раз на зразок Rust.
а як порахувати та оцінити «мало»? — нп скажімо якщо умовно в 1/5 crates використовується unsafe: небагато? — небагато. А якщо ці 1/5 складають 80% найбільш популярних (а решта 4/5 не дуже часто використовуються). І додамо що будемо використовувати не один, а декілька.
можна погодитись якщо додати що завжди є якийсь tradeoff — тобто не розглядати в рамках чарівної палички гарантованого «зможе»
Аля grep: github.com/BurntSushi/ripgrep
Взагалі ще є така штука як C2Rust github.com/immunant/c2rust
Схоже, що невдовзі автору статті, для підтримування актуальності на належному рівні, прийдеться практикуватися у переписуванні популярнихCLI-команд з C на Mojo programming language.
на mojo з python
Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig.
en.wikipedia.org/...jo_(programming_language
І що там пропозиція coreutils на mojo? По пайтону пройтися, і не плюсами растом etc. — цілком логічно.
я думав моджо вже вмер.
— За Mojo стоїть Chris Lattner
— Mojo будується як надмножина Python
— Головна мета Mojo — AI програмування на в’язці Python і C++, спростити до програмування лише на Mojo.
Ці три причини не дадуть Mojo легко померти.
Додатково ще по ідеї там де використовували cython, плюс явні ніши для використання окреслюють ясні плани на розвиток навіть і без промошена (на відміну від «перепишемо-все» в стилі джава і раст), принаймні зі сторони так виглядає.
Абсолютно нічого не значить
Надмножини над пітоном не треба, якщо цьої фігні немає в стандартній поставці, значить її не існує.
Насправді це називається не спростити, а ускладнити, бо крім пітона і плюсів додається ще моджо. 2 + 1 це 3, три мови в проекті буде, не одна моджо, а три в кожній з яких може піти щось не так.
Ці три причини не дали йому навіть народитись, а вже можна закопувати. Доля моджо, бути маргінальною мовою для купки задротів, як D, julia чи Zig.
З цим легко не погодитись: LLVM, Clang, Swift, — успішні проєкти Chris Lattner, перевірені часом.
Lattner in Apple != Lattner
І тому легко не погодитись
Так само легко не погодитись що swift успішний проект. Мова в принципі класна, але «успіхом» завдячує виключно насильній потребі кодити для apple-eco. Епл ніколи не була готова пушити цей рантайм поза своїм болотцем, так як МС пушив дотнет. А дотнет нагадаю довго сприймали як фігню, він дуже і дуже довго повз до нинішнього стану.
Так шо років через 20 побачим ;)
Це успішні проекти Apple, а не латнера, вони б стали успішними і без нього.
Chris Lattner — автор ідеї LLVM і перший імплементатор першого MVP LLVM, який має понад двадцять років успішного досвіду технічного очільництва розроблення компіляторів різних мов програмування у топових корпораціях світу.
Тому існує доволі висока імовірність, що на базі Mojo буде здійснено технологічний прорив у еволюції компіляторів подібний до Rust Borrow checker.
Не існує такої ймовірності, або вона нульова.
Коли з’являться альтернативні реалізації, сумісні з CUDA, через завершення патентів, Mojo може набрати більшої популярності. Я поки далекий від теми ML та HPC. Якщо буду вести список компаній, які використовують Mojo, то писатиму про нього, бо для Rust я веду такий список компаній.
я это уже давно слышу, но пока mojo кроме концепта ничего не показал
Якщо програмування на Rust — це дійсно лише біль і страждання укладання бізнес-логіки застосунку у прокрустове ложе вимог borrow checker, то всі про це скоро дізнаються, оскільки нервова система Лінуса Торвальдса не розрахована на тривале терпіння болю і страждань.
Маловірогідно враховуючи можливість втратити якусь підтримку від bigtech напевно. Без врахування того фактору відносно самого підходу в тому стилі програмування/взаємодії: можна подивитись на bcachefs — спершу в debian відповідні тулзи в orphaned перенесли, а зараз і в ядрі для самої fs статус з supported змінився на externally maintained.
Там Пентагон надавлює, тобто Кернегі Мелоун, просуваючи в суті своїх — Mozilla , колишніх Netscape. При тому що є численні досліди чисто теоретичні, що як тільки в мові є unsafe, вона автоматично має усі ті самі потенційні проблеми що і C та ассемблер. А без unsafe в Rust навіть сируктури данних неможливо реалізувати, тобто без жодних визовів системних API чи взаємодії із обладнанням, і яких як відомо криється до 90% помилок в програмному коді.
Rust не надає сам по собі вирішення проблеми необхідності кратно збільшити продуктивність праці з програмування і зменшення кількості помилок, для цього потрібні мови наступного рівня абстракцій, зараз очевидно що в основі буде ШІ флрмалізовані попромити та великі мовні моделі.
До речі про бігтех сапорт так Apple же взялася за swift в embedded / serverside недавно
досить топорно покищо в порівнянні з cargo, але мова в рази більш людська для споживання
Якщо буде гарний пуш і зроблять зручно, swift має всі шанси прибити rust
www.swift.org/...inux-getting-started.html
Срачів з лінусом не буде, не для лінукс ядра воно, але для бекенда й тулзів було б ідеально
Е ні, кількість unsafe зазвчий не дуже велика, покрита юніт тестами, й це зовсім не те ж саме що unsafe мова загалом.
Знову ні. Якщо потрібен unsafe — пишеться unsafe, покривається тестами й завертається в safe API. Далі працюємо вже з safe API.
Але чесно кажучі, хоч раст й є моєю улюбленою мовою, мені дуже подобається як там все зроблено, якість бібліотек й фреймворків, я так й не знайшов йому застосування навіть у хоббі проектах. Просто боротьба з borrow-checker забирає більше часу ніж економить на фіксі багів, а бібліотеки хоч й якісні, але часто сироваті.
Ну... коли у мене виникає ідея написати хоббі-проєкт на Rust, наступна думка виникає «а чому не Haskell?» І відповіді на неї немає: те ж саме GADT, тільки більше можливостей та зручніше.
На це питання зазвичай є відповідь. Rust дуже швидкий. Тому там де це важливо він теоретично підходить. Але що це? Декстоп апки? Я б краще дивився в сторону електрону, бо кросплатформа й зручність, нічого краще за React/Vue/Angular/HTML/CSS для UI я не знайшов. Ембедед/DSP? Не вситачає фреймворків, той ж JUСE дефакто стандарт для музичних плагінів не підтримує раст. З ембедед, теж, наче все є й ок, але коли починаєш копати чи не стане він тобі в якийсь момент проблемою, бо чогось не вистачає — завжди чогось не вистачає.
Ну й борьба з borrow checker... С++, додаю -fsanitize=address щоб ловити моменти де виліз не в ту памʼять, ну й наче все, виходить швидше, простіше, набагато краще підтримка й комьюніті. Хоч й С++ доставляє купу болі, задачу він виконує.
Ну Haskell теж достатньо швидкий. Плюс там є фіча, коли компілятор вміє однопоточний код робити автоматично багатопоточним, що може бути цікаво.
А так залежить від хоббі-проектів, нову мову програмування я скоріше оберу Haskell.
та сама фігня.
але потім я дивлюсь шо для rp2040 немає хаскеля і беру раст
Copilot 3
треба пильніше придивитись до хаскеля.
може підкажеш шо там в хаскелі з кросскомпіляцією
ціувить комріляція на вінді х64 під ARM32/64 linux
unsafe покритий тестами це все ще unsafe з трохи меншою кількістю багів.
В чому справа, тестування unit ,та інші тести, це вже науковий підхід до розробки софта, а не математично доказовий якого прагнуть ще за Едгара Дейкстери. Виходить, що будь який Haskel із Elrang або Rust усердно з рештою має високу трудомісткість робіт, а проблеми сучасного ІТ — це необхідність кратного збільшенгя продуктивності праці в розробці. Такі вимоги бізнесу треба на позавчора і краще ніж в конкурентів і бажано щоб ще доплатили. А це так чи інакше вимагатиме ШІ інструментів, задля автоматизації рутини.
Скажи мне, что ты не писал на Rust, не говоря мне, что ты не писал на Rust.
Якщо навіть сучасні програмісти занадто примхливі (що є то є), то класики навіть з першого погляду доволі ясно все бачать:
I found it a — pain... I just couldn’t grok the mechanisms that were required to do memory safety, in a program where memory wasn’t even an issue. (Brian Kernighan)
Там перед этим предложением идет еще одно, которое стоило бы процитировать, если вы собираетесь вести good faith discussion
thenewstack.io/...n-rust-distros-and-nixos
‘"I have written only one Rust program, so you should take all of this with a giant grain of salt," he said. “And I found it a — pain... I just couldn’t grok the mechanisms that were required to do memory safety, in a program where memory wasn’t even an issue!”
Саме так для того і сказано
Для зазначеного ключові слова наступні:
навіть і з першого погляду
І таки класики схоже не помиляються, — хоча можете сперечатися з тим, і думаю навіть мульйон admire зірочок не змінить то)
p.s. там не тільки відносно «pain» доволі точно, взагалі цікаво читати погляди які не від admirers:
thenewstack.io/...n-rust-distros-and-nixos
так дід прально каже, шоза
компілятор раста тебе згвалтує своїми правилами ще до того як ти взагалі щось покладеш у памʼять заради безпечності
і як там цитатнік растамана каже, «memory leaks are memory safe in Rust.»
а потім коли ти досягнеш дна «безпечності» і упрешся, всеодно треба переходити на темний бік сили, де ти сам собі можеш відстрелити ногу
Ну і собсно нащо тоді все це садомазо тоді
було те саме чувство
так проблема в тому, що на Rust ти не зможеш писати як на С/С++ (Фортрані), відповідно міски мають будувати архітектуру/дизайн виходячи трохи з інших шаблонів абстракцій (зрадааааааа, не можу написати зв"язаний список без unsafe)
а цей вічний газлайтинг аргумент, якщо щось складно писати на раст, то це не мова фу, це ви фу, викиньте всі свої знання, і просто не робіть графи, а замість графа робіть будьласка арену.
пойнт не в тому, я не проти інших абстракцій
пойнт в тому що раст обʼєктивно має мінуси і роздуті обіцянки в порівнянні з тим же го і з тим же сі
з Go перевага в швидкодії, з C перевага в безпечності і зручності управління залежностями/бібліотеками, не «срібна куля», а хіба хто обіцяв (як з ШІ) вайбкоднінг?
З go перевага в швидкості розробки й accidental complexity
З c перевага в швидкості розробки й accidental complexity
Швидкодія кода не фактор в більшості випадків, крім якщо це якісь супер рестрейнед системи чи cpu bound computations.
Якщо є якийсь ботлнек — чому б ні. Але нахіба трахатись із цим компілятором в основному коді і притягувати за вуха дизайн всієї архітектури? А це він і вимагає
Безпечність кода залежить від тучі інших факторів ніж від того що пропонує раст
Задоволений компілятор — лише один з критеріїв розробки
Ембедед він боунд констрейн бай дефінішен.
Ну для мобілки писати не принципово, там же на котліні чи джаві чи флутері, ти ж в курсі.
Більшість випадків це що? 1С? МС Ворд? Телеграм/Тікток?
Так а я про що
це і називається нішева мова, то я те й кажу — що раст нішева мова
Щось має сенс писати на раст, щось не має сенсу
Допустім в якомусь автомотів чи авіоніці це критично, і забаранити девайс це фу і раст займе якусь нішу пободавшись з індустрією
Навіть в цих кейсах, яка пропозиція? Переписати все на раст? А що з готовим кодом і лібами? Всі обіцянки раст закінчуються на ffi. Тоість уже треба забути про обіцянки та шукати не просто разраба на раст а разраба с/c++ що ще й знає раст
А в кейсі стіралки якоісь наприклад не фу, і можна банально зекономити на розробці, впарити й забути
Не знаю чи є якісь серйозні study але зуб даю що випустити embedded проект на c/c++ в рази швидше і дешевше ніж на rust. Навіть якщо в продакшені буде менше багів
Не памʼятаю щоб кількість багів у продакшені була причиною щось не випустити, наприклад той же ждалкер, але це вже геймдев :)
Випустити одне, а підтримувати це інше, і чомусь про це забувають.
не факт, а припущення
я приводив список вимог «вітчизняного виробника» для ембедедд (растом більше/менше, не суттєво)9-5 але понаднормово (відпочинок після перемоги, мабуть звільнять)
dou.ua/...rums/topic/55620/#3007851
приблизно вимоги такі:
— програмувати RTOS, bare metal, Linux (ядро і юзерспейс)
— знати С і С++ останніх стандартів
— вміти CI/CD та AWS/Azure/GCP
— вміти low latency video
— паяти BGA і тп.
— їздити в поле та на полігон
— знати Compass/AutoCAD/Altium, вмітималювати схеми та розводити PCB 8 слоїв з глихими отворами та з шинами 1GHz+
— підбирати BOM
— користвуватися осцилографами та різними іншими спектографами з логаналізаторами
— знати аналовову техніку, ЦОС, RF, MatCad/Matlab/Simulink, знати АІ та Python/Torch
— ходити в офіс з
— проходити поліграфа (секюрність понад усе ж)
— мати оновлені документи для оформлення згідно КЗпП
— бути згодним на оплата вище ринку (40К ..50К грн. до податків, залежно від досвіду)
— FPGA/Verilog
Забувають бо найголовніше це впарити і пошвидше, підтримувати можна й гамно якщо воно продається
От стіралка чи принтер якийсь з смартфічами. За ті смартфічі звісно піднімають ціну. Від того що воно там забараниться й ребутнеться втіхаря нікому ні холодно ні жарко.
Допустім думаю rust має всі шанси замінити Ada наприклад, але c/c++ навряд
ну припущення, зворотнє ж теж припущення.
Он мозіла випустила свій пейпер, і визнала що раст не камільфо для складних структур, я ж на те і опираюсь
Не замінити, а зайняти певну частку ринку. Ясно що «впарений» продукт (клигаву клячу) будуть підтримувати поки не вирішать написати з нуля на новій кошерній мові/фреймворку/парадигмі.
А верифікація? Напишіть на Rust інваріант циклу? Ada дає все що дає Rust і трохи більше (логіка).
Ну верифікація це питання стандартів і тулів, але я слабо орієнтуюсь
Може зроблять якийсь верифікований раст
Не в нинішньому вигляді ) просто потенціал є якийсь в цьому напрямку
Просто контора шо продає аду пушить також раст. наскільки воно ложиться на всякі верифікації й стандарти для реальних проектів хз, але виглядає принаймні органічніше, ніж «перепишем sudo бо папєрєднікі на с написали несекурний судо»
www.adacore.com/gnatpro-rust
Так, вони почали цим займатися. Тому в принципі є надія. Наскільки серйозна не знаю. Є питання, якщо код верифікований, то навіщо ці обмеження? Ну то таке.
А так в принципі, верифікація через трійки Хоара вона однакова. separation logic це скоріше альтернатива Rust.
ну це нішевий кейс все одно, як не крути, і ну так всюди воно з раст якось виходить як «недо-щось»
Якби раст зявився в 1995ому — може не було би потреби ні в ява ні в дотнет, ні в голанг, ні в пітон, але цього не відбулось і вони є і вже давно відірвали в с++ ніші які можна було відірвати. Вони й вирішують проблему c++ треша своім існуванням
зара раст претендує на конкуренцію в нішах які ще зайняті c/c++, пропонуючи скажем так свіжий підхід до структур даних і патернів і педантичний компілятор. A little bit too late
В принципі якщо брати сугубо rust vs C++, в нішах де ще царює c++ то звісно с++ мона закинути багато чо
Але плюсовий треш все таки через backward compatibility й екосистему де купа легасі кода, де старе й нове в разі чого можна зліпити скотчем і все працюватиме.
і якщо розглядати аргументацію rust як «кращі безпечніші плюси які ми давно хотіли, якби ми могли переписати все і нам не довелося думати про bw compat і де не можна вибити собі око рогаткою», то таких мов валом і було і буде
В принципі це має бути мова яка вирішить проблеми cpp, працюватиме з c/cpp, і при цьому не диктуватиме парадигму. Rust вирішує перші дві проблеми, але при цьому диктує власну сильну парадигму, занадто вимогливий до рівня що простіше писати unsafe rust ніж задовольняти safe rust. Це мінус мови right there. То ість з моєї точки зору, я б сказав rust підійшов майже впритул до мети, якби був лиш попроще й менш вимогливим
скоріше повірю що за наступні 10 років фічі раст перекочують в якусь нову мову попроще що дозволятиме писати low-level код, і даватиме 80% бенефітів раст за 20% зусиль по масажуваню компілятора
В 1995 році Rust не міг зʼявитися через час компіляції. Далі, у 1990 зʼявився Haskell, але великої популярності не набув через складність концепцій. І тут знову для мене Rust в полупозиції, я можу писати на Сі коли треба повний контроль. Я можу писати на Haskell, коли потрібна безпека з потужними абстракціями. Rust... повного контролю не дає через обмеження, ABI, ... Абстрактно писати, де монади?
ну теоретіш міг би зявитись, чому б і нє
Так це ж золоті слова
ну загалом думаю функціональні не популярні якраз через парадигму. Ну тоість популярні в узкіх кругах, але не так широко. Бо абстракції імперативки просто простіші, як для заліза так і для мозку, а це і є мета створення абстракцій — спрощення а не ускладнення.
Функціоналки вставляють між залізом і папером свою парадигму типа заради елегантності і математичноі доказовості ітд. Раст вставляє тепер свою тіпа заради безпеки. Але це ускладнення так чи інак
Я ж про то й казав про намалювати на папері. Не можна просто закодити список як на папері. простота абстракцій вирішує дуже багато — легше навчити мільйони імперативних індусів по книжці кормена без знання алгебри ніж мільйони функціональних білих програмістів з phd
Те саме з раст мені здається. Саме через те що він вимагає інших і складніших абстракцій, забирає контроль, ітд заради власних обіцянок, і на wtf, у відповідь чуєш — in rust we do not do that, YOU are wrong :)
причому на відміну від раст комюніті, ніколи не чув щоб хаскеліти навʼязували хаскель, якісь більш людські люди рілі
Є вплив функціоналки на імперативні мови. Там і в раст від хаскеля вплив є. Це здорово. Так само думаю буде вплив концепцій раст на с/с++ може на нову мову.
Але в результаті переможе простота втілення графа з паперу в код, а не гімнастика з
Але є варіант ще, як флаймен сказав шо llm усе вирішить і уравняє всіх в правах :)
ну по суті unsafe і є універсальна крабова монада на всі випадки в якомусь сенсі, не в сенсі теоріі а в сенсі «escape з парадигми», ну я так сприймаю принаймні ))
це як відбувається це нав’язування, через аутодафе?
In short — «про раст або добре або нічого», де раст критикують, там розгорається драма
історія з лінусом і гектором чим не чудовий приклад. Гектор там класична drama-queen
Агресивний маркетинг в дії за гроші великих корпорацій, чимось схоже на всякі SJW рухи. Фанатікі короче
Там С — сніжинка розіграла драму. Не треба ляля. Там ще якась JS воукрша терла гіт
У адаптованому сценарію булоб так:
Відносно нова дійова особа (Растова) невдоволена сприйняттям її гардеробу оточенням — закатує емоційну сцену апелюючи до широких народних мас.
Інша дійова особа (Сігізмунд, головний персонаж присутній з самого початку) не втримуюється і грюкає кулаком по столу (не тільки томущо він до того звик як хтось міг подумати, але й можливо щоб зупинити той безлад). В результаті — зазначена дійова особа (засмучена Растова) гордо покидає підмостки і обіцяє ніколи не зніматися в наступних епізодах.
:)
А коли: «всі вмирають, опускається штора та залишається тільки привид отца Гамлєта/Ади» (segfault due to UB)?
На сцену виходять жемененко, жепетенко, і спортивний високий пацан в дивних окулярах
Поки пацан хвалиться усім окулярами, перші двоє розстрілюють усіх у залі, а потім стріляють один в одного
всі вмирають, опускається штора та залишається тільки привид отца Гамлєта/Ади" (segfault due to UB)?
Тишу порушує лише спотворений голос що лунає з окулярів
Завіса :)
Наскільки я зрозумів тут прихована реклама окулярів доповненої реальності від Гугл, а ще 2 пацана — МС і Яблуко?
нууу то був чатжпт, жеміні й сахарчук в рейбанах взагалі )
нащот яблука шось не спішить кук особо стрибати в гайпвагон
аби не газенваген, гайп виглядає дутим
Ну... Haskell має трохи більший поріг входу, але потужні абстракції дуже спрощують, як на мене. Можливо ліниві обчислення трохи занадто. Але якщо брати cabal, то там дуже багато якісного, потужного, створеного невеликою спільнотою. Тому це не математика, це практика.
Ну... Rust простіше опанувати, але... у мене таке відчуття, що там багато архітектурних тупіків. Borrow checker не дуже гнучкий. Наприклад, зміна з одного власника на декілька може вимагати переписування всієї структури даних.
З іншого боку тому ми й знаємо про Rust і не чуємо про Haskell. Аналогічно мусульманство стало світовою релігією через агресивне розповсюдження. Десь на початку2000-х я майже не чув про Haskell, але вийшов галімий ширжитковий .NET, я читав Ріхтера, багато часу пішло коту під хвіст, нічого мені це як розробнику не дало. Про Haskell особливо не чув, вже за 40 років вирішив ознайомитися та був вражений: я навіть не міг уявити, що таке можливо. Усе життя писав бойлерплейт код, та не знав як монади допомагають його позбутися. Якби я знав тоді... Ну добре хоч не помер невігласом.
Це скоріше недолік університетів. Їхня задача дати кругозір. Там має бути і C (архітетура), і Rust (вирішення проблем), і Haskell (функціональні парадигми), і залежні типи (формальна верифікація). Щоб люди знали, що таке взагалі можливо. Он на DOU обіцяють за декілька тижнів викласти статтю про формальну верифікацію, може хоча б один зацікавиться.
До чого це? Монада це просто спосіб позбутися бойлерплейту між функціями. Maybe монада автоматично обробляє null, IO монада — розділяє побічні ефекти, Parser монада — розбір. Жодного відношення до unsafe.
шось раптом подумав — а чи пробував хтось вайбкодити на хаскелі
на окамлі
на ліспі, врешті решт
Трохи пробував Haskell, допомагає адаптуватися.
Але ще більше сподобалося читати Software Foundations разом з Claude Code. Проблема Coq в тому, що інколи доведення вочевидних тверджень ставить в тупік. Наприклад
Тобто у нас IH: фукнція func (n — 1), всі елементи якого натуральні числа, g це відʼємне.
Треба довести що список складений з елемента n на чолі, та тим що повернула функція func (n — 1) містить лише натуральні. Елементарно ж! Але...
assert(L0: forall n, n > 0 -> Forall (Z.le 0) (func n)). { intros n C. pattern n. apply Zinduction; auto. - rewrite func_equation. simpl. auto. - intros i PositiveI IH. rewrite func_equation. destruct (Z_gt_dec i 0). + apply Forall_cons; auto; lia. + auto. - lia. }На отету критику часто натикаюсь, тіпа, тицьнув в одне місце треба рефакторити півпроекта, задовбує да
З тз уні ну так мабуть, в принципі уні того й уні шо там має бути все охоплено. Але думаю це не поможе
Тобто ми уже говоримо про високоякісні уні де викладають високоякісний компутер сайенс, а не національний кривожопільський політехнічний університет, і точно не про курси якогось епама
Просто імперативка закладена в компах by design, це іх суть робити повторювані операції. Це зрозуміло будькому хто грався в якісь пірамідки чи кубики в дитинстві
Щоб легко мислити цими поняттями досить закінчити три класи церковноприходської
Щоб легко мислити в функціональній парадигмі так не вийде. Поріг входу високий до просвітлення
Раст шось посередині по порогу
Але просвітлення більшості не тре, всім треба ***кхуяк і щоб робило щось корисне з мінімальнии витратами й дешевими рабами. Ну не елегантно, ну жере память як дурне чи падає іноді — ну потім інші дешеві раби розберуться
Але секуріті інша матерія ніж просвітлення, кого зара не спитай — всі помішані на більше секуріті. Ну тобто тут можна зрозуміти в принципі хоча б джерело чому бігтек помішався на раст. В принципі годна причина, чому ні, всі тіки виграють якщо буде менше CVE. Але цього можна досягати різними способами не лише переписуючи все на one true language. І чесно визнаючи що компілятор раста від CVE не врятує
той самий бігтек в ус не дує коли щось падає, головне все таки бабло, вартість FTE і кількість FTE яких можна згребти на проект і потім на підтримку. Простіша для навчання мова виграє в складнішої для навчання
На цій хвилі безпекового гайпа раст існує зі своіми обіцянками. Ну мова вийшла непогана в принципі, зі своїм характером і вибриками
Ну я в плані що монади це escape window з pure functional підходу
Так і unsafe в раст — такий собі escape window коли pure (safe) rust жить не дає
а для чого його так змінювати?
Перша версія замовнику була така
А потім він каже: хочу окремо категорію Apple, де має бути iPhone 17 та MacBook Pro M4.
То змінюється ж структура (клас в С++), чи «ета другоє»?
В С++ нічого не зміниться, як було
class Node { string name; vector<Node*> children; };так і лишиться. Так, пару рядків створити новий Node, додати туди існуючі.А от в Rust...
struct Node { name: String, children: Vec<Box<Node>>, }станеstruct Node { name: String, children: Vec<Rc<RefCell<Node>>>, }І тепер всюди замість простогоnode.children[0].nameтреба писатиnode.children[0].borrow().name, плюс обробляти можливі помилки від RefCell, плюс можливо десь треба буде clone(), ...трохи потуплю: а тут ще вказівники і рекурсія?
я навіть не знаю як назвати цю хворобу, коли розумна людина, пише на хаскелі, розказує про веріфікації, і от на тобі, в с++ нічго не зміниться.
точно? зовсім нічого? і що навіть не треба додавати коду якій буде відслідковувати багато власників? хай воно в рантаймі сегфолтиться, так?
А в більшості випадків нічого не буде: ми прийдемо в одне місце та оновимо вузол. В Rust це робити не можна, бо теоретично він не може довести безпечність. Але код навколо може бути побудований таким чином, що програма 100% коректно працює. Наприклад, стоїть atomic increment, який оновлює статистику показів в ноді. Це коректна поведінка. Або після того, як залочили дерево, ми гарантовано будемо використовувати лише одну ноду.
Більше того, якщо брати верифікацію, то separation logic запросто працює з тим, що маємо багато посилань, нам лише треба довести, що всі ці посилання не створюють конфліктів. Проблема Rust тому, що його система типів не може виразити складні інваріанти, які програміст розуміє на рівні дизайну. Формальна верифікація як раз може описати складні інваріанти власності. В більшості мов це перекладається на розуміння розробника. Тому і є проблема в Rust, коли розробник бачить що проблем виникнути не може, мамою клянеться, а компілятор на вірить. unsafe так, але коли його стає багато, то виникає питання доцільності Rust.
Ну в Haskell свої інструменти починаючи від STM (Software Transactional Memory) і закінчуючи фантомними типами для виразу тих самих складних варіантів.
усі ноди у окремому класі, з яким можна зробити простий mark and sweep. enjoy.
а якби появився у 202 р.н.е.?
а з погляду 2100 р.?
з чого ти взяв що інші плюси, небиті і нефарбовані
А от дарма ти.
римляни знали паровий двигун, але не розгляділи в ньому ніякої революції :)
От тобі дві тищі років злито в унітаз
нам нада тоні старк, щоб в печері з ящиком плоскогубців за миску рису нам зробив arc reactor, pretty please
ліріка, зара всюди так )
ШІ прийде порядок наведе (але це не точно)
В авіоніці вимагається верифікація коду з логікою включно, Rust для цього трохи сирий. Тому він в полупозиції.
Завжди в Україні звернення на ти до незнайомої людини вважалось неввічливим.
Адже традиційна українська культура, — це коли куми́, — чоловіки приблизно одного віку, говорили між собою на ви. Коли до батьків та літніх людей так само звертались на ви.
Традиційна українська культура стає як ніколи нагальною за сучасних обставин.
Адже рівень складності задач у сучасному ІТ досяг позначки, коли вартісний результат можуть показати лише злагоджені команди досвідчених талановитих експертів. Саме з цієї причини софт-скіли є такими важливими для сучасного ІТ.
Неввічлива поведінка унеможливлює взаємоповагу та, відповідно, здатність до взаємодопомоги, що, своєю чергою, унеможливлює будь-яку взаємоузгоджену ефективну спільнодію.
Тобто без взаємоповаги є неможливим таке явище як синергія спільнодії, оскільки відсутність взаємоповаги унеможливлює взаємодопомогу.
Неввічливе поводження завдає психологічних травм людині. У стані психологічної травми людина втрачає здатність до творчості.
Тому максимізація коефіцієнта синергії спільнодії є неможливою без додавання здатності до взаємовідповідальності до здатності до взаємоповаги та взаємодопомоги.
Знаєте, я довго думав над тим, що ви написали. І чим більше розмірковую, тим більше розумію, наскільки важливо сьогодні повертатися до глибинних культурних основ, які формували наше суспільство століттями. Звертання на «ви» це не просто мовна конструкція, це внутрішній жест поваги, визнання іншої людини як рівної, як такої, що заслуговує на делікатність, на простір, на гідність.
Мені здається, ми живемо в час, коли зовнішня швидкість — технології, месенджери, дедлайни часто витісняє внутрішню глибину. Ми звикли до коротких форм, до прямоти, до «ти» як до норми. Але чи не втрачаємо ми щось важливе в цьому процесі? Чи не стирається тонка межа між відкритістю і нав’язливістю, між щирістю і недбалістю?
Я почав помічати, що коли я звертаюся до когось на «ви», навіть у неформальному середовищі, це змінює тон розмови. Людина ніби розкривається по-іншому. Вона відчуває, що її не просто чують її поважають. І це створює зовсім інший рівень взаємодії. Особливо в командній роботі, де кожен має свою зону відповідальності, свої емоції, свої слабкі місця. Там, де є повага є довіра. А де є довіра народжується синергія.
Я працюю в ІТ, і бачу, як часто технічна досконалість не рятує проєкт, якщо команда не вміє спілкуватися. Якщо хтось боїться висловитися, бо його переб’ють. Якщо хтось не просить допомоги, бо не хоче здатися слабким. Якщо хтось мовчки терпить токсичність, бо «так прийнято». І тоді я думаю: а що, якби ми почали з простого з культури звертання, з культури слухання, з культури вдячності?
Можливо, це звучить наївно. Але я вірю, що великі зміни починаються з дрібниць. З того, як ми вітаємося. Як ми реагуємо на помилки. Як ми даємо зворотний зв’язок. Як ми визнаємо заслуги інших. І як ми будуємо середовище, де кожен може бути собою без страху, без маски, без напруги.
Тому ваша думка про традиційну українську культуру як основу сучасної ефективності мені дуже близька. Це не про повернення в минуле, це про перенесення мудрості в теперішнє. Про те, щоб зробити людяність частиною професіоналізму. Щоб повага стала не винятком, а нормою. Щоб ми не просто працювали разом а творили разом.
Я не ідеальний. І сам іноді помиляюся, можу бути різким, нетерплячим, неуважним. Але я хочу змінюватися. Хочу вчитися бути уважнішим до інших. Бо врешті-решт, ми всі частина одного великого процесу. І від того, як ми ставимося одне до одного, залежить не лише результат, а й те, ким ми стаємо в цьому процесі.
"
"
Якщо у вас в команді роками працюють незнайомі люди, то це як раз маркер, що у вас щось не так.
"
"
«Куме, а ти чув, як москалі...» — це майже народні анекдоти.
Я гадаю, тут треба акцентувати не на те, що чоловіки приблизн одного віку, а можливо що це люди, які дійсно незнайомі.
Це не традиційні. Це просто звернення до людей, і звернення на «ти» до своїх близьких та друзів — це нормально. Нететикет в україні завжди відповідав міжнародним «традиціям», починаючи з фідонет.
Звертання на ви чи на ти в команді не повинно завдавати психологчіних травм людині, я вважаю що неввічливе поводження аж ніяк не відноситься до «ти» чи «ви».
Чим більше взаємоповаги, — тим більше здатності до взаємодопомоги, тим вище коефіцієнт синергії співпраці. Це аксіома.
звертатись на ви, це виключно тупорила совкова тема, щоб показати, той до кого звертаються на ви, має над тобою домінацію, бо у відповідь буде на ти. Тобто це механізм, щоб показати, що ви не являєтесь рівними. Тому до всіх треба звертатись на ти, а тих хто вознікає, слати на три букви.
пан, порваний жупан, але на «ви» і «пане»
То яка спільнота сильніша: що добиває пана з порваним жупаном насміхацтвом та глузуванням чи підтримує повагою та доброзичливістю?
Ви плутаєте роботу чиновника на держслужбі та вільного художника в колективі таких же вільних художників зібраних втілити певний проект.
Я веду мову про українців на ДОУ, які замість обміну ідеями, думками та їх оцінками у технічній дискусії, дають оцінки один одному й обмінюються глузуванням та зневажливим ставленням.
В площині раст-топіка питання «художників» залишається нерозкритим з того як треба розглядати розробку — вільні художники, чиновники, вільні чиновники, etc). Це якщо нецікаво все решта витягуюється на перший план.
Ти ж бач, в топіки набігають як не Владіміри, то свідоміти із бекграундом роботи в державних/казених структурах. Раз пішла така п«янка, то ріжем останній огірок. В оутсорсі не пам’ятаю, щоб хто звертався «пан», навіть QA інтернші. Хіба прибиральниця, але до неї теж відповідно на Ви. Часом HR на співбесідах, але буває вимагають вмикати камеру і дивуються, що у футболці, а не в піджаку з краваткою і сорочкою з накрохмаленим комірцем (хоча і вони не у вечірньому платті із глибоким декольте та обручами як Наташа Ростова на своєму першому балу), хоча в банк в фронтофіс не подаюся відсвічувати обличчям клієнтам.
як приклад фокусування на розчухуванні «актуальності» питань ти/ви, огірках і футболкопіджаках
А де щось відносно раст, чи хоч би натяк на прив’язку до нього? (Наташа Растова?))
Rust вже має місце в ядрі Лінукса. Чи є сумніви?
Для розчухування тематики треба було тоді хочби сформулювати як — Наташа Растова вже при дворі імператора Сігізмунда, чи є сумніви?)
Ну... будь яка мова, яка генерує обʼєктні файли, може бути в ядрі Linux, будь то Ada, Pascal, Zig, ... В чому проблема злінкувати?
Тільки для out-of-tree модулів, ну їх дехто і на плюсах збирав.
Вважаючи, що це «ви» до одної людини прийшло тільки за часів пізнього ВКЛ, а до того навіть князям казали «ти», ваше «завжди» і «традиційна», мʼяко кажучи, недоречне. Скоріш за все, воно описує, у кращому випадку,18-те століття і пізніше.
Взагалі ця тупа недолуга манера двоїти співбесідника виникла в пізній Римській імперії (історія відома: до імператора звертались на «ви», бо він сидів на троні одночасно за двох консулів) і розповсюджувалась дуже повільно. Розумним виглядає, наприклад, іспанський варіант (tú близьким, usted чужим, але однина; для множини vosotros чи ustedes). Або навіть польське pan (хоча3-я особа — якось дивно).
Що ввічливо чи ні — виявляється при персональному спілкуванні. Багато для кого, і для мене теж, це «ви» між колегами може показувати щось типа «Зараз я тебе на дуель викличу, а зараз перейшов на надмірну показову „ввічливість“».
Я за скасування цього «ви» для одного; якщо буде потрібно — і форсованими методами.
Ввічливе поводження є необхідною умовою здатності до взаємодопомоги і взаємовідповідальності суспільства.
Хамство не повинно бути проблемою того кому нахамили. Тому ввічливе поводження має стати невід’ємною частиною масової культури українців.
Найефективніше це може бути досягнуто через спонукання адміністративною відповідальністю, наприклад, за звертання на ти до людини старшої30-ти років без ввічливого звертання пан або пані.
Не заперечую. Але який звʼязок між ввічливим поводженням і використанням форми «ви» для одного адресата, крім тарганів римської спадщини?
«Офис простих рішень», ага-ага.
Яким чином звертання на ти, наприклад, до літньої людини може бути ознакою ввічливого поводження?
Звертання на ви є проявом поваги в українській традиційній культурі і є беззаперечною частиною нашої традиційної української культури.
Походження цього звичаю є питанням спірним і не має принципового значення.
Якщо ввічливе поводження стане законодавчо регламентованим правом і обов’язком кожного українця, то наше суспільство стане для всіх нас кращим, приємнішим для життя і синергетично сильнішим своїми можливостями і потенціалом.
🤦♂️😢
З іспанською доволі все не так універсально просто з tuteo чи voseo, варіанти second-person singular — tu vos usted використань доволі сильно відрізняються від країни до країни, порівняти нп використання в Іспанії, у Колумбії, та в Аргентині.
p.s. зовсім не претендую на цілковиту коректність записаного — бо враження в основному отримані з tutor розмов та різних відео іспанською
Для прикладу того, що можна і не псувати множину, тут не треба універсальности. Я чув про різницю стиля між країнами, дякую за нотатку, проте принципіально це нічого не змінює.
у вимові lei італійською і вона і Ви :)
Що цікаво — англійська мова пішла іншим шляхом, й там взагалі скасовано «ти», you вживається як для однієї людини, так і для групи.
Японська мова пішла третім шляхом, й там формальне あなた (ти/ви) вживається лише коли невідомо ім’я того, до кого звертаєшся, інакше звернення йде по імені з відповідною хонорифікою.
Й, до речі, в польській мові ввічливе звернення на «пан» в третій особі, хоча в сучасній мові таке звернення вживається дедалі рідше. Навіть безадресне звернення в рекламах чи в інструкціях йде в однині, «на ти».
Ну це фактично те ж саме що пропонує оппонент — видалити «ти» з ужитку.
Але оскільки потреба розрізняти все одно є, виникають форми типу «you all», настільки вжиті, що стягуються в «yull» чи щось подібне. Тому я і кажу, що мова вимагає цього, і розрізнення відроджуватиметься, і робити саме з «ви» ввічливу форму — просто злочин.
Usted[es] вимагає теж3-ї особи.
Це інший випадок: навмисне звернення, яке підкреслює, що вже дуже знайомі, майже інтимно. Така ж форма використовується і для звернень до бога. Але якщо спробуєш з цього вирахувати, що можеш до будь-кого звернутись на ty, то результати будуть неприємні.
Я пробував, не вистачало двозвʼязних цикличніх списків, почав їх робити, там і зупинився. Проблема що більшість Rust розробників впевнені, що вони або реалізовані, або їх можна легко реалізувати, не розуміючи що їх реалізації обмежені.
Покажи код на котором остановился
Проблема свзяных список в том, что это специфическая структура данных, которая затачивается под каждый кейс.
Я тебе могу сейчас написать реализацию связного списка (я тебе это кстати уже делал несколько месяцев назад), ты скажешь, что не то, не подходит для твоего кейса. Я напишу под твой кейс, ты скажешь, что опять не то, потому что надо чтоб работало еще для какого-то кейса про который та забыл сказать.
Реальность состоит в том, что связный список, идентичный тому, который ты можешь сделать на C реализуется без проблем на Rust двумя raw pointers. Поверх этого можно добавить обертки разной степени безопасности и эргономичности в зависимости от того, какой именно у тебя кейс и для чего нужна конкретная реализация.
ти в курсі що ти схожий зара на тих попів що чпокають хлопчиків?
срочно перепісать всю цю небезпеку на безпечний лучший в мірє раст!! Пищпищ
Согрешил... Oh no
Оце торкнуло
Скажи, стоило ходить десять лет в школу, и 5 лет в университет, чтоб в итоге вот это написать на форуме, где взрослые дяди обсуждают серьезные вопросы?
strong opinions weakly held
тобто визнати що One True Language не без обмежень що стоять поперек горла ти не готов, краще зразу давити цих неповнолітніх опонентів своім взрослим крабовим х*єм?
Так шо там не так вийшло із безпечним двозвязним замкнутим списком? Довго вмовляв компілятор хто там ким володіє і після ночі сексу вирішив все по старінке? Треба деталі цього порно, бо здається ти нє смог в безпечність. Чи то мені здалося...
godbot rust example
Це працює, такий приблизно інтерфейс треба, але виникає питання, як це буде відрізнятися від Сі, окрім того, що прийдеться крізь писати unsafe. І там ще немає container_of.
В Rust напевно так. В Сі такої проблеми немає, можна написати десяток бібліотечних функцій які закриють майже всі можливі використання.
Я це памʼятаю. Був приклад стеку, реалізованого через однозвʼязний список. З двома операціями push та pop. Але це стек. По-перше, розподілення на контейнер та елемент це вже не список, бо кожен елемент списку може розглядатися як контейнер
A -> B -> C це три контейнера, один містить три елемента, другий два, третій один. Далі, у список можна вставляти після любого елемента. root -> A -> B -> C. Щоб вставити елемент після B та отримати root -> A -> B -> B’ -> C мені треба тільки знати B та B’, та зовсім не треба знати root.
В тому і проблема, що і мене безліч кейзів, та я хочу мати один бібліотечний код для них. Як у Сі. І мені якось дивно, коли запитують про кейз. Це як запитати кейз використання vector, а потім запропонувати конкретну реалізацію в якій є лише pop_back та emplace_back. А якщо треба замінити елемент по індексу, то треба писати нову реалізацію.
Через це програмувати на Rust практично неможливо. Бо двозвʼязні цикличні списки у мене в кожному проєкті використовуються в десятках різних кейзів, і замість продуктивної роботи ти думаєш як саме в цьому кейзі реалізувати обгортку.
Ты показываешь код, который реализует двухсвязный список, который будет работать аналогично двухсвязному списку из C. Я не понимаю что именно невозможного в том, чтоб программировать на Rust с этой реализацией.
Не везде, а именно там, где выполняются небезопасные операции. Не весь main делается unsafe, а только отдельные блоки, где выполняются манипуляции со списком, которые не проверяются borrow checker’ом или не првоеряются какими-то флагами рантайма (типа Rc< RefCell >), а пишутся по принципу trust me bro. Что аналогично тому, как это делается в C
Это будет отличаться тем, что «trust me bro» происходит только в unsafe блоках, которые проще заметить и провести их аудит, чем проводить аудит всей программы.
Условно открываешь code review, идешь есть ли где-то «unsafe», если есть, начинаешь вникать, делается там то, что нужно или нет в плане безопасности.
Тебе ничего не мешает использовать библиотечный связный список в Rust с небезопасными функциями. Или библиотечный связный список в Rust с безопасной реализацией основанно на проверках рантайма (Rc< RefCell >). Я говорю о том, что можно сделать реализацию с безопасным интерфейсом, без проверок рантайма, если знаешь как именно связный список будет использоваться в этой реализации. Я привел пример пул аллокатора в качестве примера ранее.
Крізь, де використовуються двузвʼязні циклічні списки, а це майже кожна функція проєкту, ну можливо окрім парсінгу аргументів командного рядку.
Хоча б dancing links, backtracking у якості прикладу. Типова реалізація через арену та індекси замість показчиків: link.
Взагалі, це твердження (теорема) для мене не дуже очевидно. Чимось нагадує пана Зеленського «я все порішаю, якщо треба буде». Як на мене доказ теореми нетривіальний. Але жодного доводу або свідчень або плану як це довести я не бачу.
Більше того, вимоги змінюються. Може прийти нова фіча, де треба ще один сценарій використання. Яка ламає поточну реалізацію.
Т.е. у тебя все приложение (причем не одно, а судя по всему все приложения, которые ты пишешь) — это работа со связными списками? Это збс. И ты без рантайм проверок и без статического анализатора вот это делаешь на чистом С?
Я понятия не имею зачем так делать, и не хочу честно говоря разбираться, но поинт такой: в контексте безопасного Rust делается граница, с одной стороны безопасный код, с другой небезопасный, которые реализует какую-то сопроводительную функциональность. Scope этого небезопасного кода максимально снижается, для него пишется безопасная оболочка, которую невозможно неправильно использовать. То что внутри оболочки тщательно проверяется (включая fuzzer-ами и санитайзерами). Это збс.
Если по какой-то причине этот подход не работает, альтернатива — рантайм проверки (счетчик ссылок) для обеспечния безопасности памяти. Хотя конкретно здесь будет уместно использоваться язык со сборщиком мусора, который более естественно может с этим работать.
Если проверки в рантайме и сборщик мусора не подходит — получается кодовая база, корректность которой существует только глобально (корректность одного компонента или даже строки кода зависит от корректности всех остальных строк программы), и, что более вероятно, корректности при определенном размере кода достичь не удастся.
Твой кейс это не показатель того, что Rust не нужен, а показатель того, что ты куда-то (обоснованно или нет) забрел.
Так пишуть на Сі вже 50 років. Через двозвʼязні циклічні списки. Так, інколи hash map. Але зазвичай коли треба обробляти зовнішний ввод, інакше це червоний прапорець: чому не посилання, а ключ? І знову ж таки там двозвʼязний циклічний список під капотом для конфліктів. Так є ще ring buffer. Взагалі навіть realloc в Сі вважається поганою практикою (інвалідація вказівників на нього), тому в більшості сішних ліб стастистика використання памʼяті показує reallocs: 0. В принципі це робить код хоча й небезпечним, але доволі прямим та простим. Що доведено досить великими та стабільними проєктами в embedded. Так, інколи можна бачити контейнерно-орієнтований код, але він зазвичай пишеться людьми які прийшли з C++, Rust, Go, і в першу чергу реалізують stl, std, ...
Але мені досить дивно читати це від людини, яка впевнена у тому, що Rust треба інтегрувати я Linux Kernel. Тому це бачиться більше в ключі: я гадки не маю як воно написано на Сі, але треба інтегруватися з Rust. Саме через те, що двозвʼязні циклічні списки там на кожному кроці, інтеграція мені здається проблемною, простіше допиляти Redox.
Це не «забрів кудись», а два принципово різні підходи. C мислення: дані + intrusive зв’язки = простота. Rust мислення: контейнери + ownership = безпека. При тому що у мене є багато претензій до мови, сішний підхід довів право на існування — Linux kernel, TCP/IP, embedded системи досить стабільно працюють на ньому десятиліттями. VST (Verifiable C) показує що безпеку можна додавати до справжнього C коду з intrusive lists через separation logic, не жертвуючи прямолінійністю підходу.
Я розумію переваги Rust. Але я розумію і ціну, яку приходиться за це платити.
тут це не зовсім сі мислення
це абстракція. Коли ти дизайниш звязний список топроно на папері, так ти на сі втілюєш ту абстракцію
функціоналки класно втілюють математичні абстракції по своєму
А раст вимагає іншої і набагато складнішої абстракції наприклад списка — де треба думати про кожен доступ який розмежований між акторами за правилами чекера — тобто ні, ти не можеш взяти намальоване і реалізувати список як намалював на папері. Тобі потрібно викрутитись з референс каунтерами і робити бороу в рантаймі, думати про лайфтайм структури й кожного елемента окермо, пограти в преферанс із компілятором. І в результаті це зовсім не схоже на кілька кружочків на папері і й кілька стрілочок для звʼязку
Це мова що ускладнює абстракції структур даних задля виконання своїх обіцянок. Вона каже що намальований на папері граф — ансейф, тому ти не можеш його закодити так як на папері, як у тебе в уяві
З цієї тз це найбільша моя претензія до раста — синтаксис можна вивчити, швидість це круто, але от не можна намалювати на папері нову структуру даних і просто реалізувати її просто так як намальовано
Мона там дискутувати тіпа що ансейф це ізольовано тому безпечніше, маячня як на мене, так само ансейф код можна ізолювати в будьякій іншій мові, але можна дискутувати
Але не тому використовють ансейф — а тому щоб наприклад списки можна було звязувати як це інтуітивно і треба робити в нашому уявленні про списки. І коли хтось читатиме код, щоб видно було що це структура список, а не монстр що пожирає всесвіт
Спроектував і реалізував
На сі/цпп так можна
На го можна
На яві можна
На всьому можна
На функціональних можна по математичному — інший світ
А на раст нє, нізя, коли доходить до циклічних звʼязків особливо.
або треба сісти на шпагат, і зробити подвійне сальто. Або ансейф і по старому
Абстракції ж для того щоб спрощувати світ а не ускладнювати, а з раст виходить навпаки.
C/C++: «Ти розумний, ось тобі вказівники, не накосячь»
GC мови: «Ми відстежуватимемо все під час виконання, пиши що хочеш»
Rust: «Доведи мені, що це безпечно, або шукай інший спосіб, і не думай що в рантаймі я за тобою не слідкую»
— вказівники
— не знаю, але гадаю шо теж вказівники
— вказівники, або контейнери стандартної ліби, які ховають вказівники
— у всіх функціональних мовах така ж фігня як і у яви. просто 99,999% списки вже є у стандартній бібліотеці.
і виходить шо всім норм робити списки через вказівники і якось це обгортати (у випадку яви, С++, функціональних мов), а от расту так не можна.
просто смішно.
Так можна просто це робиться через ансейф, а не через гвалтування себі мозку заради каргокульта безпечності
Ну і я ж не про стандартну лібу
DOM у servo — не просто дерево, б+ індекс не просте дерево, orderect dict — не проста хешмапа
але так, для раста так теж можна, і навіть треба,
але тоді не треба прикриватися фіговим листочком гарантій safety, коли під капотом ті самі чорти. Тіпа ми так все обгорнемо в сейф інтерфейс, що ніде не вилізе. Вилізе!
А чесно визнати — раст як такий погано підходить для складних структур без використання unsafe. І тоді сприймати unsafe як firstclass вихід з парадигми, як наприклад монади в функціоналках
Але тоді виходить фігня, бо прикинь — саме при роботі зі складними структурами і треба сейфті
Мені не впали сейф операції на хешмапі чи векторі якось сам розберусь і без допомоги компілятора
А там де обіцянки раста якраз дуже треба — раст лягає ножкі кверху і треба робити все і перевіряти все самому.
Ну короче десь там я собі провів межу між растом і го. Там де треба розкидати якісь пакетики дуже швидко по бекендам чи загалом прості структури — прекрасно, я напишу на раст. Це і ніша його йнмд, такий собі higher end of low level.
low end of low level, якісь бутлоадери наприклад, там сі буде кращим вибором
Там де щось складніше за хешмапу і список — сім раз подумаю про щось інше, наприклад go, а не собі моск гвалтувати рожаючи якесь кастомне дерево, нафіг нада.
Собсно тому ява свого часу забрала ентерпрайз у c++ — бо топорне ООП на повільній ява машині виявилось простіше для складних задач за потужність і універсальність c++, але ніколи не замінила c++. Те саме можна про скріптові мови vs ява сказати
Так і раст цілком забере якісь нішеві юзкейси на спектрі між с/c++ та golang/java. Але ніколи повністю не замінить жодну з них. Просто не здатний. То й нема сенсу продавати ці блискучі буси де доведеться юзати unsafe вдоль і поперек, як мову що замінить c, бо тіпа вийде safe код
а ніхто і не прикриваеться. ти просто не там і не то читав, або не так все поняв.
бо раст ніколи не обіцяв тотальної і всеосяжної безпеки і те шо можна на ньому писати не вмикаючи мозок.
шо значить чесно визнати? це ніхто ніколи не скривав.
Ну і так. сприймай unsafe як хочеш, але це частина мови.
яку, як я писав вище, не скривають.
навіть є растономікон і інші книжки де все це добре розписане.
Ну то й добре, так тоді нема про що сперечатись, а раст не гарантує нічого
Тоді в чому сенс переписування сі коду який відлизувався десятки років?
Так цей діалог десь і розвивається завжди:
1. Перепишем xyz на раст, там безпека
2. Тиць github.com/...c/map/core/extract.rs#L50
3. Ой так ніхто ж не обіцяв безпеку, ти що не читав растономікон
en.m.wikipedia.org/wiki/No_true_Scotsman
нюню
www.rust-lang.org
Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.
треба було там зірочку зі ссилкою на растономікон вліпить, conditions apply
от іменно.
якшо ти перекладаєш «eliminate many classes of bugs» як «обіцяв тотальної і всеосяжної безпеки і те шо можна на ньому писати не вмикаючи мозок» то це саме те про шо я казав.
ти тупо не вдуплив шо прочитав. а потім образився шо воно трохи не так як ти собі уявив.
то ж раджу тобі навчитичь розуміти шо ти читаєш.
А ну звісно опять двацать пять, я винен
> обіцяв тотальної і всеосяжної безпеки і те шо можна на ньому писати не вмикаючи мозок" то це саме те про шо я казав.
Саме ТИ приписав мені це, і тепер цим маніпулюєш. Я якраз не чекаю від раста жодної безпеки.
Але чомусь ти проігнорував те що я виділив
Але ж ти спитав хто обіцяв? Я тобі скинув хто обіцяв. Але я просто не так прочитав і не так зрозумів ага
Агресівний маркетінг, і агресивні фанатики, яким божа роса. І таких серад растаманів якраз повно
ну так, це ж тільки раст обіцяє безпеку!
а той же go не обіцяє ?
Build simple, secure, scalable systems with Go
але ж коли справа торкнеться поінтерів то гарантії безпеки го теж кудись дінуться. але це раст паганий і шось там наобіцяв, а го наобіцяв того ж але го непоганий і маркетинг не агресивний.
візьмемо Яву.
Java SE lets you develop and deploy Java applications on desktops and servers. Java SE and component technologies offer the rich user interface, performance, versatility, portability, and security that today’s applications require.
та сама фігня з секюріти але ще і про перформанс напіздюнькали. але поганий раст. це в нього агресивний маркетинг.
так шо ти, дружочок, перед тим як комусь розказувати про токсік раст фанбоїв добре подивись в дзеркало.
бо це не растфанбої серуть у гілці про го, а ти сереш у гілці про раст.
це безпредметно
Все що тебе хвилює що я дозволяю собі критикувати раст
мона только або добре або ніяк?
я теж пишу собі на раст, довольний? І мені він уяви навіть подобається місцями. мені подобається і снікерс, але я не заявляю як це погано критикувати їсти снікерси кожен день. І не пропоную дієти снікерс-онлі
Мені растамани такі як ти не подобаються, що переписують coreutils ліш би було на раст з претензіями на «краще» І сприймають критику раста як особистий виклик.
не маніпулюй ЗНОВ, я не заявляв нічого про безпеку як таку взагалі, не заявляв що хтось мені обіцяв bug-free чи секуре-код, і не критикував про швидкість, швидкість мені якраз подобаться
Так шо це ти раст фанбой, і раст фанбої токсік якраз
З іншого боку на критику ти нічо не відповів зовсім. Тобі важливіше перейти на особисті образи
можеш піднасрать в яку-небудь гілку про го, якщо у тебе ще не все вилізло. смачного
кста
ar5iv.labs.arxiv.org/html/1505.07383
...we simply wrap raw C pointers in unsafe blocks when we need to use a custom memory allocator or interoperate with the SpiderMonkey JavaScript engine from Gecko. We have implemented wrapper types and compiler plugins that restrict incorrect uses of these foreign values, but they are still a source of bugs and one of our largest areas of unsafe code.
Additionally, Rust’s ownership model assumes that there is a single owner for each piece of data. However, many data structures do not follow that model, in order to provide multiple traversal APIs without favoring the performance of one over the other. For example, a doubly-linked list contains a back pointer to the previous element to aid in traversals in the opposite direction. Many optimized hashtable implementations also have both hash-based access to items and a linked list of all of the keys or values. In Servo, we have had to use unsafe code to implement data structures with this form, though we are typically able to provide a safe interface to users.
тобто навіть мозіла визнає що ідіоматичний раст занадто педантичний інструмент для складних структур
багато тексту.
але ти сам не помітив як початок розійшорвся з закінченням.
по перше вісі ці списка однонаправлені, двонаправлені — це все повільно.
також потрубують аллокацій впринципі (якшо робити на буфері, тоді чим аоно буде відрізнятись від раста?)
тому в тому ембеді де я (бареметал) я бачу списки раз на декілька років.
по друге, як би «підход» С працював, то не булоб ні MISRA C, ні CompCert, ні
. Бо воно вже не дуже С.
Ембеддед різний буває, черги пакетів в нетворкінгу і i/o команд в блок девайсах, скедулери ОС — там ніяк без списків, причому часто з множинною лінковкою одного елементу в різних списках одночасно.
от знов ти, і знов ти відповідаєш не та те шо написанео.
Те шо ембедед буває різний я знаю і без тебе.
і те шо списки там використовуються я теж знаю.
а тепер питання, як часто ти пишеш нове ядро в твому ембеді, як часто мережевий стек? в кожному проекті ?
якшо ні, то до чого взагалі твій коментарій?
яж ясно написав шо списки в ембеді є, але рідко.
В українському галерному ембеддеді нетворкінг — це десь третина вакансій, і купа задача в тому нетворкінгу це безпосередньо QoS, використання шареного ресурсу ефірного часу/частот і тому подібне, де буквально робота іде зі складними чергами і їх конфігураціями.
Напрпимер, очередь из связных список реализуется в Расте очень годно, с полностью безопасным внешним API.
З можливістю за O(1) додати, вилучити, перекласти елемент в голову чи в кінець списку, з можливістю тримати елемент в кількох списках одночасно, і все це без реаллокацій на кожну дію? Все це — реальні потреби, прямо зараз працюю з цим.
Юзери будуть дуже щасливі, коли нутрощі їх телефону і офісного роутера будуть реалізовувати QoS для голосу для мітингу в тімсі через купу враперів на безпечному расті з усіма витікаючими для latency.
Спискам проскопаралельно які об’єкти лінкувати — динамічні чи статичні.
struct dlist { struct dlist *prev, *next; }; static struct dlist a = { &a, &a }; static struct dlist b = { &b, &b };По-друге, якщо логіка примітивна, ніякої динаміки, то й списки не потрібні. Але як тільки з’являються пули буферів, черги пакетів, планувальники, то не обійтися.
связный список це насправді граф з циклами, з чим раст у загальному вигляді не може працювати. в расті є бібліотека для роботи з трьо-направленими списками?
Там выше чувак уже дал реализацию того, с чем Rust не может работать.
Звісно можна безпечно через ключі. Створив обʼєкт, створив guid, додав у арену, далі використовуєш виключно guid замість посилання. Плюс треба прокинути крізь арену.
растамани все роблять не так. а треба так:
1. пишіть свій груб і юбут на расті
2. пишіть своє ядро на расті
3. пишіть купку драверів на расті.
4. пишіть консоль і утіліти на расті для свого ядра.
5. пишіть графічний інтерфейс на расті.
6. пишіть нарешті вже свій безспечний з точки зору пам’яті бравзер.
от тоді світ нарешті побачить який раст крутий і корисний. поки цього не зроблено, раст нікому не потрібен.
Не зовсім то, але є rustos дистрибутив (правда з linux ядром і можна зі звичним DE), але зацікавити може трохи іншим — щоб подивитися одну з інших альтернатив для a/b схем (atomic updates, immutability), хоча це якраз з rust і не пов’язано напряму. Буває цікаво подивитися що нового з’являється з якими ідеями, навіть не використовуючи повсякденно.
>з linux ядром
>зацікавити може трохи іншим
>хоча це якраз з rust і не пов’язано напряму
ви тредом не помилились?
в контексті переписування-на-раст, що з того є rust oriented, і наскільки то юзабельно-чи-неюзабельно — думаю що ні)
так вже ж є))
www.redox-os.org
а бравзер з безпечною роботою з пам’яттю там є?
Щось є, але не знаю подробиць
Грався з цією штукою у віртуалці just for fan
This year, there have been numerous improvements both to the kernel’s correctness, as well as raw performance. The signal and TLB shootdown MRs have significantly improved kernel memory integrity and possibly eliminated many hard-to-debug and nontrivial heisenbugs. Nevertheless, there is still a lot of work to be done optimizing and fixing bugs in relibc, in order to improve compatibility with ported applications, and most importantly of all, getting closer to a self-hosted Redox.
www.redox-os.org/news/kernel-10
The project summarizes its goals as “‘to make a complete, fully-functioning, general-purpose operating system with a focus on safety, freedom, stability, correctness, and pragmatism’”
Звісно що там до продакшен-реді ще хз скільки)
Тут важливий сам факт що воно є, працює, і має доволі немало портованого софта
по ідеї критерій для дистро простий: є в продакшн — значить ready, нема — not-ready
При цьому ловить heisenbugs так само, як і ядро на С. Нащо тоді Раст?
Баги будуть у будь-якому проекті, який написаний людьми)
їм по приколу пройти цей шлях на расті
як Лінусу колись було по приколу зробити це на сях
але, можливо, там дійсно буде менше проблем... колись.. або не буде))
Якщо не пробувати, то нічого і не зробиш)
Ну як мінімум воно довело, що Раст так само викликає UB та race conditions, як і С.
Это не нужно было доказывать. Rust может вызывать неопределенное поведение как и C, это факт, прописанный в документации: doc.rust-lang.org/...considered-undefined.html
Rust не предотвращает race condition. Он имеет инструменты для продотвращения data race в безопасном коде.
В Linux Kernel теж є kmemleak, kasan, ubsan і алокатор з рефкаунтом.
Все это не предотвращает и не детектит data race, про которые я написал, которые в безопасном расте являются ошибками времени компиляции.
І як Rust гарантує щось, якщо data race спричинені позапрограмною подією, типу висмикування на ходу USB-флешки, з потребою звільнити ресурси?
У мене був період фулл тайм фіксання ядерних CVE, майже завжди вони виглядали або чимось подібним, зовсім неочевидним з точки зору чисто коду, або проблемою в логіці застосування певного функціоналу, коли він міг робити ескалацію прав.
можно пример?
security-tracker.debian.org/tracker/CVE-2023-47233
git.kernel.org/...888bc7831411ec8a3cbe20d78
Реальні CVE виглядають зазвичай так, а не що хтось просто забув поставити free() чи не обклав мютексами шарений ресурс.
Это немного не data race, про который я выше говорил.
Менеджмент памяти и всякие use after free это то где Rust как раз справляется еще более годно. Нужно будет моделировать ресурсы таким образом чтоб Rust понимал их жизненный цикл (смарт поинтеры, контейнеры и т.п.)
це_не_ті_дроіди_які_ви_шукаєте.jpg
Ну тобто що так буде купа роботи з ризиком зробити неправильно, що так.
Переформулирую)
Оно показало, что когда на Расте начинают заниматься системным программированием, то вылазят те же проблемы, что и на С.
це проблеми дизайну/архітектури, чи мови?
Це очікування проти реальності)
Тут я не доктор тюнити очікування. Для цього є візіонери і ЛОМи.
Є формальна верифікація, тому не згоден.
Ню-ню))
точніше:
«Баги будуть у будь-якому проекті»
з уточненням:
«Баги будуть у будь-якому нетривіальному проекті»
а то чуть-що — зразу люди)
Еще одна зрада. uutils coreutils выпускается с лицензией MIT (а не GPL как оригинальные GNU coreutils).
Что сильно возмутило поклонников GNU
users.rust-lang.org/...e-of-gnu-coreutils/126110
Підмічено точно: там де rust там — там драми. І не одна, і не тільки на раст ресурсах, але нп і на dou в раст коментах від раст fanclub)
p.s. іноді закрадується відчуття що драми не супутний тип промошен чогось, а головний
та більших істерічок ніж сішники ще пошукати треба.
Попкорн є, раст драми то надовго, доу не виключення))
ох ці ж кляті копірасти
Еще один момент, который упустили все, кто обеспокоился размером Rust бинарников.
взагалі кажучи необхідністю використовувати busybox рішення щоб зменшити overhead «обеспокоились» розробники uutils
p.s. busybox рішення також мають як плюси так і мінуси, у випадку коли можна без нього обійтися — в такому трейдоф і потреби не має
Я вот тут еще немного зрады принес
discourse.ubuntu.com/...ly-oxidising-ubuntu/56995
поза чисто тех.характеристиками можна назвати підтримку locales, в цьому плані поки так (тобто в uutils крім LANG=C майже нічого)
< >додамо ще свіжої з «На жаль програма coreutils несподівано закрилася»
почали потрохи обговорювати Multiple Security Vulnerabilities
www.phoronix.com/...-rs-security-ubuntu-25.10
власне кажучи що сам по собі підхід з memory safe і «збирається значить все окей» не спрацьовує магічним чином на практиці як гарантія відсутності security багів
Звісно, бо більша частина security це розуміння можливих атак, race conditions, TOCTOU проблем, side-channel атак, неправильної валідації вхідних даних, уразливостей бізнес-логіки, privilege escalation vectors, session management, signal handling. Безпека роботи з пам’яттю це лише невеличка частина, не кажучи про те, що при ASLR/рандомізації адресного простору використати memory corruption стає вкрай складно в сучасних системах.
Виглядає так, що більшість спеціалістів у цьому мають досвід у C/C++. А ті хто не зумів його освоїти, намагаються переписати все на Rust, не маючи відповідної security експертизи, сподіваючись що гарантії safety автоматично вирішать усі проблеми. В результаті sudo-rs з вразливостями, бо memory safety != security expertise.
Зазвичай застереження не дуже спрацьовують поки то не побачать явно на практиці. Юрл з обговоренням того по sudo-rs був просто як свіжий приклад.
ага, піди таке розкажи гуглу
security.googleblog.com/...move-fast-fix-things.html
бо вони з тобою не погоджуються
закиньте блог-інфо на sudo-rs чи rustcoreutils з запитанням що не так покищо пішло на практиці
так а шо пішло не так?
чи ти один з тих особливо обдарованих які фразу «менше багів» читае як «це срібна куля, багів не буде, мамой клянусь» ?
Я просто бачу bias та конфлікт інтересів.
а хто з ким конфліктує? чи шо за інтереси?
Конфлікт інтересів це коли ти робиш дослідження, в якому ти зацікавлений в результаті. Наприклад, тобі дали завдання впровадити Rust. А потім тобі дали завдання оцінити результат впровадження, але якщо ти не покажеш покращення, то це покаже твою некомпетентність.
проблема в тому, шо цей конфлікт тільки в тебе в голові.
бо оці твої «наприклад» — тупо взяті зі стелі.
бо якшо так «подумати», то все іде за планом рептілоїдів з нібіру.
це з якихось дописів раст фанклаба?)
петросян?
пояснення шо пішло не так будуть?
Що знову гостра форма раст істерики?) Читайте вище — знайдете те що там наведено.
а ти що? псіхіатр? за рару коментів вже діагнози видаєш?.
так і шо читати зверху і шо там наведено?
про тайні змови растоманів які маніпулюють статистико? чи ше шось?
явно мало знаків запитань) а бурхлива реакція на що-небудь пов’язане з раст не в позитивному ракурсі — показова
всього одна скобочка )
бачу що ти тихенько плачеш через те шо гугл показав що С/С++ трохи не такі гарні, як ти про них думав.
телепаааат...
тоді виникає питання навіщо телепатам раст, якщо вони баги і так побачать)
p.s. плюсами не дуже цікавлюсь
Ні! Ще раз ні зверніть увагу на залежності та розмір! Coreutils на C компілюються «чисто» й мають мінімум залежностей.
Rust-бінарники зазвичай більші (через runtime, crates), що критично для embedded-систем, rescue-середовищ, контейнерів.
Отсутствие зависимостей != маленький размер. То, что Rust crate подтягивает через зависимость, на C нужно реализовывать ручками. Код и там и там должен быть реализован.
Именно в embedded на Rust будет больше возможностей оптимизировать размер за счет того, что определенный функционал может быть закодирован в системе типов (типа type state pattern), что невозможно в С, или в генериках.
Припустимо як вже за Generi-ки пішла справа тобто за С++.
, то в modern C++ із concept-ами можна зробити і аналог TSP rust-а, хоча код як на мене занадто каракульний. Власне, Rust зроблений саме як конкурент С++, а не С. З одного боку іржавому далеко до С з точки зору нізкорівневості, а особливо коли векторні оператори в формі інтрісіків і т.п. що важливо для системного коду. З іншого боку С звісно далеко до Rust із різними перевірками і т.д. що важливо для прикладного коду.
Без unsafe Rust — не сильно далеко йде від наприклад Python.
Можно примеры низкоуровневых фич, которые присутствуют в С (желательно в стандартном) и отсутствуют в Rust?
* doc.rust-lang.org/std/simd/index.html
* doc.rust-lang.org/core/arch/index.html
Якщо чесно, тут я зовсім не згоден. Ситуація якраз навпаки. В авіації і подібних сферах є стандарт DO-178C. Там все будується на процесах перевірки і доведення надійності. Є DO-330 який описує як кваліфікувати інструменти типу компіляторів чи статаналізу. Є DO-333 який дає право замість тестів використовувати формальні методи. Під Сі є купа готового: MISRA C (набір правил безпечного програмування на C), CompCert (компілятор C з математично доведеною коректністю) який формально доведений компілятор і реально можна підтягнути навіть до рівня TQL1 (Tool Qualification Level 1 — найвищий рівень довіри до інструмента). Це найвищий рівень довіри до інструмента, коли його помилка потенційно може викликати баг у коді. Для Rust нічого подібного поки нема, там формальні методи тільки починають пробувати, про доведення що rustc генерує асемблер правильно мова навіть не йдеться. Тому на практиці Сі попереду, а Rust... memory safety це лише один аспект надійності, а проекти як Prusti та Creusot дуже експериментальні. Процес сертифікації компілятора для критичних систем займає роки і коштує мільйони. Мені оцінити важко, бо чим складніше мова, чим більше можливостей вона надає, там важче доводити властивості, те, від чого відмахуються «це ж баги бізнес-логіки». Ну... такі баги також можуть бути критичними.
А от вразливості типу sudo це швидше питання що людям норм і вони не хочуть вкладати час і гроші у формальне доведення.
Можна переписатиCLI-команди з C на Rust"C-утиліт у продакшені. Для продакшену поки залишаються C-версії, бо вони стабільніші, сумісніші й перевірені часом.
Це реалістична ідея, але:
Coreutils від GNU — дуже відшліфовані та battle-tested програми.
Rust-реалізація (uutils/coreutils) існує, але вона ще не на 100% сумісна й має меншу перевірку боєм.
Тобто це дійсно корисна практика для навчання, але не «повна заміна»
Вибірковіcть у характеристиках скоріш усього існує щоб кожен знайшов щось своє (акцентуючи на тому для підкреслення чого-небудь), у цьому випадку «найулюбленішою» це «admired»?
А тренди нп показують деякі перспективи, як нп rust по одному з індикаторів обраному автором (admired), якщо загуглилось коректно — declining тренд по stackoverflow survey виглядає так:
2023 84.66%
2024 82.2%
2025 72.4%
У мене таке чувство що у кожного хто асіліл писати цей нечитабельний код і добровільно згвалтував себе правилами бороучекера, відростає на шиї виличезний другий хєр, і вони так люблять розмір того хєра, що бігають як скажені навколо, мітять ним територію і переконують усіх що їм теж такий треба
Так і є. Растісти це ж вчорашні вегани/вейпери/you name it, які підходять і перші кажуть «я не їм м’ясо/я курю вейп/я фофу флен і нормально себе відчуваю», коли буквально ніхто його не запитував. Самі приставучі та надокучливі з виду програмістів. Навіть скілісти не були такими надоїдливими, поки скала не заповзла назад під плінтус.
Нужно было именно прийти в топик про Rust, чтоб рассказать, что растисты приходят и что-то рассказывают там, где их об это никто не спрашивал.
ніт
обнаружил в себе суперспособность: только пробежашись глазами по таблице слету переписал false.c
от токо нашо
Це ще раз пояснює чому Rust-CLI ще не «заміна» дляC-утиліт! Це відбувається завдякі статичній линковці, а саме Rust за замовчуванням тягне в binary багато бібліотек (std, runtime, panic-handling). Навіть якщо код — одна стрічка, результат — мегабайтний.C-компілятора відточені десятиліттями!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У C — це кілька рядків, і якщо зібрати з musl або glibc, то розмір буде мінімальний.
Panic-handling та runtime
Rust вставляє код для обробки паніки, unwind, форматування помилок, навіть якщо воно не використовується.
У C немає нічого зайвого — повернув return 1; і готово.
Оптимізації
GCC/Clang оптимізують coreutils до мікроінструкцій.
Rust (через LLVM) теж оптимізує, але об’єм runtime він майже не викидає!!!!!!!!!!!!
так про то ж, користь загалом сумнівна
ну тс закидає це як спосіб вчити раст ок, але не зрозуміло тоді що конкретно він пропонує, аля щоб вчити — тіпа треба закрити очі на uu й переписувати заново ls, і потім наївшись досхочу порівнювати з чужим раст кодом.... може він ще порадить поле бритвою покосити )
Ключевое слово: «за замовчуванням »
Таки да, на С можно извратиться и сделать что-то чтоб размер был минимальным.
На раст внезапно тоже можно извратиться и собрать не в дефолтном режиме, и получить другой результат
Верно. Вопрос в том, сколько приложений написано на Rust под Линукс, которые не делают ничего кроме «return 1», не аллоцируют ничего в куче и не имеют ни одного «пути» в коде, который может вызвать панику в рантайме, и ничего не форматируют. Я думаю, что ответ — около 0, поэтому дефолтная конфигурация все это включает.
rust false паніку викликає?
Отвечу серьезно
В Rust есть код, который выполняется перед main. Этот код инициализирует обработку ошибки переполнения стека, в нем есть heap allocation (с использованием Box), куда записывается имя потока (по дефолту «main»).
github.com/...ix/stack_overflow.rs#L166
Смарт поинтер Box может вызывать панику, если выделение памяти в куче привело к ошибке.
Код паники тянет за собой код, связанный с форматированием сообщения о панике и код для panic unwinding (для самого unwinding) и для вывода состояние call stack при панике).
При желании это можно отключить, если сильно нужно, реализовав кастомный main. Я дал ссылку в соседнем сообщении, где все это рассматривается и описывается как отключить.
84K это C программа, которая делает exit(1), это ваc не смущает? Программа, которая рендерит это видео занимает 64К/
це false на маку, може вона робить фото і відсилає моє фото цру, заідки мені плять знати
але мені насрать, бо яка в дупу різниця
Тебе зато не смущяє що раст версія на порядок жирніша. Зато це меморі сейф false вєсом в мегабайт
Агресивний фанатизм — прекрасна риса майже всіх крабоїдів з Однією Правильною Мовою
Понимаешь, когда ты используешь аргумент раздутых бинарников одного тулчейна, но при этом игноришь раздутые бинарники другого тулчейна в том же контексте, спор теряет серьезность.
Если размер бинарников имеет какое-то значение, его нужно оптимизировать, здесь нет вопросов.
Ты промахнулся. На продакшене мой Rust код работает на системе с 256Кб памяти, из которых только 64К может быть использовано для кода. Для хобби я на Rust писал для системы с 8К памяти для кода и 0.5К памяти для данных.
вітаю, людство чекало цього від часів появи компутерів з 256кб памяті, і ось нарешті зʼявився раст і зʼявився артьом що запускає код. Ми врятовані, нарешті ми знаємо що треба викинути все небезпечне неправильне сі-лайно і замінити на правильне безпечне раст-лайно!
то чому ти досі тут?
да уже собирался
ось тобі список причин чому раст залишиться езотерікой:
Все серйозне високорівневе відпадає одночасно
В ніші одноразових тулзів, всім насрать що код ls на раст меморісейф, а на сі тіпа ні (тіпа)
в ніші бекендів на тому ж го набагато швидше робити ітерації, є набагато більш езотеричні мови тіпа еліксір які так само кращі в своїх нішах, але писати на них більше 3ьох фанатиків знайти анріал. Те саме з раст. Про зручність кліпання крудів в порівнянні з якимось джанго я мовчу. Гарбедж колєктор в го і трохи більше памяті? Ну і хер, життя зручне зато і команда 30 рил а не три. Ми все ще на рівні де вартість часу розробника вища за вартість оперативки.
раст ніша — мова лоулевел що дає по рукам якомусь криворукому кривожопу, окей, але там де лоулевел, там якісний код на сі/сі++ виграє завжди всеодно. Банально щоб робити ефективні викрутаси з памʼяттю потрібен ансейф доступ до памʼяті а не повага до бороучекера. А якісні розробники й на сі напишуть меморісейф код
Ерго ми опиняємось тут з артьомом що запустить код раст на продакшен з 256кб, і буде спорити з усім світом.
Класна мова? Може. На свалці історії багато класних мов. Але сі не серед них і не буде
Безпечна? Маркетинг і під великим питанням, бо в компіляторі і в рантаймі теж баги є, я тобі скинув cve-rs, але ж божа роса. Звісно проще тицяти в cve sudo яким користуються мільйони, і порівнювати з кодом яким користуються 0.001% і який майже ніхто не досліджує. На расті так само можна прекрасно писати вразливий код і код який тіче памʼяттю
Imho: незважаючи на існування як плюсів так і мінусів — мова цікава, якусь свою нішу займе, але що напевно розробників найбільш анноїть — це «агресивний» промошен скрізь де треба і не треба)
Мені певні моменти відверто подобаються, типу lifetimes наприклад
Посвоєму цікава мова. Але лайно можна писати на чому загодно
І да цей агресивний промоушен і роздуті обіцянки в безпечність й ефективність всього шо написано на раст відверто дратують.
яке співвідношення в між криворукими кривожопами і гурушними вигравашами ?
в середньому приблизно π:√2, тобто 2.22:1, але сильно залежить від ціни на гречку
криворукі тепер виграють і все через ші
а тепер почитайте історію Java
і шо знову таксамо буде всйо rust? тоді треба очікувати на rustscript))
не так само, а подібно якось, бо ж тойво, основна маса «криворукі рукожопи», а писати швидкий і надійний код таки потрібно поки ще ШІ недорозвинутий
якщо аналогія з промошеном, то логічно булоб очікувати таки rustscript
наразі для веба wasm
що там є чи нема для промошена то неважливо)
не розумію, про який промошен мова, я писав про «техніко-економічне обгрунтування» rust для шир-прогер-мас в планово-капіталістичній економіці з людським корпоративним обличчям
від bigtech
ща все перепишемо на java, ща все перепишемо на rust Ж)
точніше — галер
трохи не так, а думаю так: «руст в кожну праску»
в праску не поміститься)
а браузер все ще переписують
забув «мамой клянусь»
habr.com/ru/articles/686168
а якщо додати хабрибабри — то праска і поржавіє)
не тільки
Докуменация говорит, что она еще может
на моей ubuntu она ничего этого не делает, только exit(1)
віндоус бекграунд перед тим як з раст зацікавленість з’явилася?
p.s.
% which false
false: shell built-in command
% whereis false
false: /usr/bin/false /usr/share/man/man1/false.1.gz
pps. там розмір в основному за рахунок деякої додаткової статіки, не пов’язанної з функціоналом з shared libs
Спасибо, упустил тот факт, что в баше false это встроенная команда, которая имеет более высокий приоритет, чем /usr/bin/false в $PATH
Можна ще взяти ядро Linux або якесь з BSD :D:D:D #joke
В якості реальної ідеї — є купа пакетів Python які «під капотом» мають C — і ось це теж можна переписати. Rust нормально лінкується з Python.
P.S. ffmpeg & curl — явне перевищення, проєкти такого розміру не кожна команда потягне, тут справа не в компетенції розробника вже...
У системному світі важлива не лише функціональність, а й довіра.C-версіям.
Адміни й дистрибутиви Linux більше довіряють «старим перевіреним»
Щоб Rust-утиліти стали стандартом, потрібно багато років перевірок і adoption.
це такий жарт?
Я додав ffmpeg як нагадування того, що потрібно обиратиCLI-команди, які вам під силу. У таблиці ж є інформація, скільки рядків коду на C у репозиторії ffmpeg.
ІМХО переписувати добре протестований код на С це безмістовне витрачання часу.
Є сенс писати ШІ безумовно, і WebAPI бекенд замість : Node, Java, PHP, Django тощо.
В просто ще одній мові програмування є лише один сенс — бізнес. Це коли Microsoft сворює клон Java — C# для конкуренції і проблемами із ліцензійним виплатами звісно власний JVM до Sun Microsystems. Або Google підбирає Kotlin по партнерці із JetBrains, через такий самий конфлікт вже з Oracle. Разом з тим, Kotlin був створений, з тих самих причин для IDE, першочергово створеної для Java.
Вивчати меморі сейфті на прикладі програм, абсолютна більшість з яких одноразово виконується з фіксованими аргументами і завершається, і де по завершенні все алоковане і всі відкриті файлові дескриптори і інші системні ресурси система ж підчистить це звісно потужно.
Немає жодної причини брати для подібних апок Rust замість скажемо Go.
Тема про вивчення Rust. У темі жодних згадок про memory safety.
Тема про вивчення Rust. Вивчати Go можна так само, переписуючиCLI-команди з C.
Нема сенсу ні Rust, ні Go. Тому що менеджмент памʼяті досить прямий, багатопоточності немає. Тому так, можна навчитися як викликати системне API, а 90% фічей буде просто непокритим. Більше того, я припускаю що це може бути навіть шкідливим, бо в такому простому коді будь-які костилі будуть працювати на ура, що закріпить шкідливі звички.
Як на мене, треба Rust — роби щось багатопоточне.
На практике на C банально не асилили как распарсить аргументы коммандной строки без создания heap overflow, в гребаном sudo.
richard-ac.github.io/posts/sudo-cve
sudo-rs (2025)
CVE-2025-46717 (—list)
CVE-2025-46718 (-U)
Таки это баги бизнес логики, а не парсинга аргументов командной строки.
github.com/...peykious/cve-rs/tree/main
божа роса
Я хз что вы пытались сказать
А який сенс вивчати Rust, якщо не підходити ідіоматично, і тупо 1:1 транспілювати програму на С вручну? Як у древніх мемах, довести що програміст на Фортрані може на будь-якій мові питати на Фортрані?
а ти, наприклад, матиматику відразу з інтегралів почав вчити.
чи таки зі скдадання чисел до 10?
Але математика вивчається з вправ на конкретні і різноманітні дії, а не гріндом розрахунків на касі.
я тут більше до того, шо все вивчаеться від простого до складного, це поперше.
недарма дуже часто перша програма — «hello world».
по друге, ти звідкись взяв шо програму радять переписувати тупо 1:1 і почав тупі маніпуляції.
про якусь транспіляцію вручну !
тупо прочитав шо захотів, шоб підходило під негативну відповідь.
один з способів розповсюдження з rust — коли відомий софт залишає свою назву і базову (звужену) частину функціоналу
Сенс — зацікавити, бо для когось саме таке ручне переписування допоможе почати знайомство з Rust, і можливо це переросте в щось більше: наприклад, запис на зимовий Rustcamp та подальше працевлаштування з Rust або впровадження Rust у проєктах, де зараз працює. Rust — високооплачувана мова програмування, і її популяризація важлива в Україні.
>працевлаштування з Rust
tiobe. ada все ще вище раста. фортран все ще вище раста. делфі паскаль, і навіть перл все ще вище раста.
мораль доволі проста: за сепулькі не платять, бо вони нікому не потрібні
і?
¿!
ну якщо
то це не означає що за сепульки не платять бо вони нікому не потрібні.
Чи ви не розумієте що є логічне «І» та «АБО»?
А ви оптиміст, я бачу.
Починати знайомство з МП з переписування утіліт на тищі строку.
Если делаешь drop-in replacement существующего инструмента, важна максимальная совместимость, включая воспроизведение каких-то непонятных вещей и старых багов, на которые все явно и неявно завязались.
Подход, когда условно транспилируешь с одного языка на другой не лишен смысла. Этого может быть достаточно, чтоб начать процес, после чего можно запилить тесты для существующего кода и далее рефакторить в более идиоматичный формат.
Go тягне свій VM + GC (поправте) тому мова С/Rust/Ada/Pascal/etc тут мають явні переваги.
А ось Rust vs C... Може якщо робити щось накшталт busybox то матиме перевагу Rust.
Більшість команд працює з файловою системою, тому хоч на Python. Emerge/Portage, DNF це доводять.
так, busybox варіант робить малопомітним overhead який додає rust (у порівнянні з с)