Опубликован релиз языка программирования общего назначения Rust 1.88, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63485
Они старую ос не дописали, а уже новую начинают.
> Они старую ос не дописали, а уже новую начинают.Расскажи поподробней, кто эти "они"? А заодно, почему другие "они" не дописали Hurd/Syllable/React/Phantom/HelenOS/<куча других хоббиосей> и каким образом "этодругоепониматьнадо!"?
Они это растоманы.
Другие они остальные. В отличии от растоманов не били себя в грудь ни насчёт "линуксу/сишке/делам конец", ни насчёт сверхбезопасности и скорости разработки.
Теперь, когда растоманы облажались, естественно окажется что это другие растоманы говорили и вообще не то имели в виду и они всегда были за линукс. Но 5 лет назад ни один растохлопец не стал опровергать.
> Расскажи поподробней, кто эти "они"Я не он, но предполагаю он имел ввиду - лучше бы дописали первую ось на расте (редокс емнп) общими усилиями, а не распылялись на разные проекты. И "они" это авторы муналос, по моему это очевидно, как ты это не понимаешь, ума не приложу.
> Hurd/Syllable/React/Phantom/HelenOS/<куча других хоббиосей> и каким образом "этодругое
Таким, что новость не о них, а о муналос. О перечисленных тобой осях вообще речи не было, зачем ты их притащил? Не понятно.
> О перечисленных тобой осях вообще речи не было, зачем ты их притащил?Авторы Hurd/Syllable/React/Phantom/... имеют плавно такое же отношение к редокс у, как и авторы муналос.
Почему бы им тоже не подключиться к разработке "общими усилиями"?Теперь тебе отсылка стала понятна?
> Почему бы тоже не подключиться к разработке "общими усилиями"?Так об этом здесь каждый второй кричит, когда выходит новость о каком-нибудь маргинальном/полумаргинальном/совсем-не-маргинальном проекте, особенно связанным с экосистемой linux - "Лучше бы *** пилили...") И чем, в этом смысле, отличаются эти поделия на расте не ведомо. Но (судя по тому, как забомбило) почему-то это оказалось другим.
> судя по тому, как забомбилоТы настолько одинок по жизни, что пару комментариев на своё сообщение называешь "забомбило"?
Кто они? Они сейчас с тобой в одной комнате?Или это абсолютно разные люди пишут разные ОС?
>Кто они?Jeremy Soller, Ribbon, bjorn3, Ron Williams, 4lDO2, Ian Douglas Scott, Anhad Singh, somewhat inactive, Emanuele Antonio Faraone, Nagy Tibor, jD91mZM2, Xavier L'Heureux, Noelle Levy, François Laignel
>>Кто они?
> Jeremy Soller, Ribbon, bjorn3, Ron Williams, 4lDO2, Ian Douglas Scott, Anhad Singh,
> somewhat inactive, Emanuele Antonio Faraone, Nagy Tibor, jD91mZM2, Xavier L'Heureux, Noelle Levy, François LaignelЧестно попытался найти тройку (все проверять мне лень) имен в списке авторов
https://github.com/asterinas/asterinas/graphs/contributors
https://github.com/Askannz/munal-os/graphs/contributors
но - ни одного совпадения.Очередной пу̵с̵к̵ ̵м̵е̵т̵а̵н̵а̵ ̵В̵о̵е̵н̵а̵м̵и̵ ̵С̵у̵п̵р̵о̵т̵и̵в̵ ̵Р̵а̵с̵т̵а̵ коварный заговор Подлых Растаманов?
Чего промямлил-то? Закусывай иногда.
> jD91mZM2Человек умер 4 года назад, тебе он и мёртвый мешает?
Он должен был воскреснуть и подключиться к разработке «общими усилиями»
>>Кто они?
> Jeremy Soller, Ribbon, bjorn3, Ron Williams, 4lDO2, Ian Douglas Scott, Anhad Singh,
> somewhat inactive, Emanuele Antonio Faraone, Nagy Tibor, jD91mZM2, Xavier L'Heureux, Noelle
> Levy, François Laignel"Кто все эти люди?" Даже фараон какой-то затисался :)
у Redox лицензия MIT, у этой - другая
Зачем суперминорные версии так часто?
> Зачем суперминорные версии так часто?Почему суперминорные? Нормальная минорная версия.
И не часто, а ровно раз в 6 недель.
> Зачем суперминорные версии так часто?С 2015 так - назло хейтеркам, они так забавно реагируют на упоминания Раста. Ну и чтобы не накапливать "тех-долги" (но в основном, все же - назло) ;)
И оно вышло вообще-то вчера.
Но! Вчера был четверг!
А расто-сра^W э-э-э, конструктивная-критика-раста-опеннетовцами в четверг и конструктивная-критика-раста-опеннетовцами в пятницу-субботу-воскресенье -- это две совсем разные конструктивные-критики-раста-опеннетовцами!
В общем, летс те срач бегин (хотя вон, выше - уже)!
А как надо? Раз в восемь недель, а не раз в шесть недель? Раз в полгода? Раз в несколько лет?Частые релизы позволяют поставлять фичи по готовности. Это в целом упрощает процесс разработки и поддержки проекта.
Не уверен, что ты имеешь ввиду под суперминорными версиями. В стандарте Semantic Versioning про них ни слова. Там есть мажорная, минорная и патч. Ещё есть пререлизные версии и всякая мета. Но никаких суперминорных версий. Вот полный формат: https://semver.org/#backusnaur-form-grammar-for-valid-semver...
А редакции, те что раз в три года, тогда зачем? Ведь получается, что на расте имеет смысл писать только на самом свежем, и для сборки нужен всегда самый свежий, полная привязка к онлайну и к карго.
> А редакции, те что раз в три года, тогда зачем?На твой вопрос есть весьма подробный ответ: https://doc.rust-lang.org/edition-guide/
Вообще в отличии от подавляющего большинства технологий, для всей экосистемы Rust есть документация. Подробная и качественная. Для того, чтоб найти что-то недокументированное, надо целенаправлено искать. Долго и упорно.
> имеет смысл писать только на самом свежем
Без дополнительного контекста это верно для любой технологии. Обычно нет смысла использовать старьё.
Однако это не значит, что ты обязан использовать самое свежее. Вполне можешь использовать ту версию компилятора и сборочной инфраструктуры, какую тебе хочется. cargo это в первую очередь сборочная инфраструктура. Аналог cmake или ninja или ещё чего-то. Но со встроенным менеджером зависимостей. Почти всегда, делая что-то реальное, ты будешь использовать пакеты, взятые из cargo.io. Но никто не заставляет. Можешь сделать себе офлайн зеркало, либо вручную зависимости подключать даже. Подробности в документации https://doc.rust-lang.org/cargo/
Нет смысла не использовать это всё, но тебя никто не заставляет. Для использования всей инфраструктуры нужно меньше телодвижений, чем для не использования. Но так и должно быть. Стандартный путь по умолчанию обязан быть самым простым путём.
>Вообще в отличии от подавляющего большинства технологий, для всей экосистемы Rust есть документация. Подробная и качественная. Для того, чтоб найти что-то недокументированное, надо целенаправлено искать. Долго и упорно.Пару лет назад было много разговоров про отсутствие формальной спецификации языка, мол достаточно компилятора и его документации. Как с этим дела обстоят?
> Пару лет назад было много разговоров про отсутствие формальной спецификации языка,Так это тут только разговоров было, типа "хотим как в сишечке!"))
А остальным оно не сильно и мешает, даже в gcc добавляются rust без формальной спецификации языка.> достаточно компилятора и его документации. Как с этим дела обстоят?
Таки достаточно!
Но с того времени появился FLS, бывший Ferrocene Language Specification, который они сделали при подготовке к сертификации раста для safety-critical/regulated отраслей, а потом подарили Rust Project. Скорее всего он ляжет в основу спецификации.
PS: они впоследствии сертифицировались по ISO 26262(ASIL-D), IEC 61508(SIL4) и IEC 62304.
Так что "дока" отличная))
Есть https://doc.rust-lang.org/stable/reference/, есть https://rust-lang.github.io/fls/Первое - детальное описание языка для пользователей языка. Второе как раз формальная спецификация. Не очень понятно, зачем оно (fls) нужно, но оно существует. На сколько я понимаю, формальная спецификация является больше юридическим документом. Т.е. это не для программистов, а для юристов. Для программистов есть reference.
> Не очень понятно, зачем оно (fls) нужно, но оно существует.
> это не для программистов, а для юристовСами же ответили))
Это как раз более чем понятно зачем - сертификации.
Без такого их не пройдешь, а они открывают двери в том числе в госконтракты.
Формальная верификация нужна очень редко. Только для очень узкого круга задач. Даже если рассматривать госконтракты, которые сами по себе не частое явление. Для подавляющего большинства программистов на Rust наличие Спецификации ничего не значит. Тем более, что нет смысла использовать спецификацию как документацию при наличии более подходящих вариантов.
>Для подавляющего большинства программистов на Rust наличие Спецификации ничего не значит.Очень даже значит. Это обеспечивает возможность создания альтернативных реализаций компилятора, независимость от не самого эмоцилнально стабильного сообщества, долголетие языка в какой-то степени.
А примеры создания совместимых альтернативных реализаций по спецификациям будут?Ну, кроме Ады, для дериативов которой заранее подготовили прокрустово ложе жёстких ограничений.
Кроме Ada ещё у C++ есть Спецификация. Честно говоря затрудняюсь ответить, у каких ещё языков есть Спецификация. Кроме ECMAScript больше ничего не приходит на ум. Да и не требуется это для большей части языков.
Ключевое слово не "спецификация", а "совместимая".
Что толку от спек С и плюсов, если компиляторов по ним несовместимы?
Альтернативная реализация поверх gcc уже давно делается (не уверен, на сколько успешно, мне попросту не интересно). Отсутствие Спецификации этому не мешает. Упомянутый reference более чем достаточен для этого. Обрати внимание, что fls даже не является частью документации (не на поддомене doc). Как я уже сказал, это больше юридический документ и ценность его только в этом.Так что да, для подавляющего числа программистов не холодно не жарко. Включая и тех, кто делает независимые реализации.
Они там реализовали компиляцию без проверок.Так как стандарта нет. То вполне могут объявить себя полноценной новой реализацией и разрабатывать свой rust - без проверок.
Он не будет соответствовать референсной - ну так на то она и новая. Типа теперь мы референсные для новой реализации.
Понимаю, что вряд будут это делать. Но отстутствие стандарта дает шанс побороться за первенство.
И да разработчики ядра linux могут начать продвигать свою версию - наиболее им подходящую.
У них свои требования к компилятору и они слегка отличаются от требований разработчиков прикладных приложений.
> Они там реализовали компиляцию без проверок.Не, вместо (мучительного, т.к. тема сложная) изобретения своего велосипеда, дождались интеграции Polonius в майнлайн и взяли его:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677874....
> This first set's main change is the addition of the poloniusborrow-checker to the compiler
>
В описании к gcc 15.1 об этом ни слова.Очевидно, пока еще не вошло.
Зато есть вот такое замечательное:
Support for let-else has been added. While this is not used in core 1.49, it is used in the Rust-for-Linux project, our next major objective for gccrs.Сразу видно, кто их целевая аудитория.
Не применяется mmu. Это так надо писать. Как дал uefi direct mapping так и живём. Так ёбта. Я написал свою ось на c++ в которой есть mmap. Там даже acpica прикручена.Знаете в чем проблема с mmap? У вас есть гарантия атомарного выставления флага A но нет D. То есть когда ты обновляешь pte ты должен быть готов к тому что тебе с соседнего ядра прилетит некорректная запись. Чтоб этого не было используется ipi с блокировкой ядер на время этой операции. Спасибо сраный Интел. За то что протокол обновления pte не подразумевает compare-and-exchange.
Растаманы разумеется даже в это не смогли. Но сделано ядро! Воу! Раст вперде! Они ведь даже не понимают что это нахер ненужно
Это точно. Всего-лишь версии 1. Надо как у хромов с файрфоксами - по 169 версий, тогда норм будет.
Администраторы мой клиент стёрли. Напишу заново не триггеря их. Сам виноват.Растаманы не асилили paging в x86. Который сам по себе очень сильно всрат потому что mmu не использует compare-and-exchange операции для обновления флагов A и D при выполнении операций. Это делает операции типа mmap или mremap очень сложными и дорогими.
Так вот. На выходе очередная недоось на расте. Без шансов взлететь вообще.
Там аноним со своей осью на крестах слишком умный. Такой умный, что чирбот его схомячил под кат. Потому что нельзя быть таким умным во здесь. А по факту, что тот аноним с крестной ОС, что эти растовики - ну, норм студенческая движуха. Пусть учатся, а не в пакет в подвале дышать. Я - за.
Не аноним во первых а яВо вторых это не взлетит почему не взлетела моя ось. Дрова. Но допустим что дрова подарят инопланетяне.
Полно других проблем которые вот прямо так не решаются. MMU. Acpi не всегда работает по стандарту. Иногда оно специально сделано так что пытается сломать Линукс. Примеры есть. Drm задолбаешься портировать. Плюс его ещё и переколбашивают постоянно
ну то есть ты не осилил
Ну так растаманы осилят. Их много а я один. Хотя нет, не осилят
>Acpi не всегда работает по стандарту. Иногда оно специально сделано так что пытается сломать Линукс.А винду не ломает? Может стоит её поведение копировать, а не линукса?
> А винду не ломает? Может стоит её поведение копировать, а не линукса?Жила была девочка^W Рекатос, 20+ лет, сама виновата...
Так они все "жили-были". Кто про них всех таких вспомнит через 20 лет? Но это не умаляет их академической ценности для причастных в период разработки.
Всяко лучше чем всё сишное. Вон Торвальдс прогнулся под натиском солидных корпораций - разработчиков Раста, значит Раст - это будущее человечества! УРА!
Будущее человечества - TWW. Future. No future.
> Вон Торвальдс прогнулся под натиском солидных корпорацийКак вы поняли, что он именно прогнулся? Я к тому, что слово "прогнулся" обычно означает, что кто-то упорно сопротивлялся, но его всё-таки сломили и заставили. Так вот, ещё раз, как вы поняли, что Торвальдс именно прогнулся? Из каких его сообщений это следует?
> Ядро и приложения выполняются в одном адресном пространствеЗдравствуй, ms-dos!
> с применением модели безопасности на базе sandbox-изоляции WASM (в состав входит движок wasmi для запуска приложений в форме байткода WebAssembly).
Ладно, не совсем ms-dos, но все равно криво.
Почему DOS, а не, скажем, vxWorks?А! этодругоепониматьнадо, марсоходам можно, а растаманам низя
> Почему DOS, а не, скажем, vxWorks?
> А! этодругоепониматьнадо, марсоходам можно, а растаманам низяПотому что на марсоходе не выполняется произвольный хер пойми от кого код.
Помнится, один их pathfinder на vxworks на Марсе вдруг начал без конца перезагружаться. Еле его в чувство привели.
> а безопасность достигается на уровне логического разделения безопасного кода и кода, в котором не исключено возникновение проблем с безопасностьюА опять эта система, которая имела бы смысл, если бы без унсейфа нельзя было поломать. Но rust дает защиту, он дает защиту от дураков.
Для такой архитектуры нужен другой язык.
Ты как всегда прав, друг мой.
crates.io с мобильной связи у всех открывается?
Т2, без того-что-нельзя-называть совсем лежит. При попытке оживить, оживляется, но не полностью. Вот уже неделю пытаюсь найти рабочий конфиг, чтобы исправить.
В репозитариях debian и РедОс есть штук 100-200 самых популярных крейтов Rust
> Добавлена возможность указания нескольких выражений "let" внутри условных блоков "if" и "while"Это полезно. Реально напрягает местами писать вложенные if-let.
> В пакетном менеджере Cargo включён автоматический запуск сборщика мусора для очистки кэша в домашнем каталоге
Ну наконец-то! Столько места жрёт, что прям никаких терабайтов не напасёшься.
> Признак "const" применён в функциях:
Прикиньте, я тут споткнулся о то, что f64::log2 не const.
>Код распространяется под лицензией MPL 2.0.Ну хоть лицензия более-менее, хоть это хорошо.
Мне абсолютно понятно, какую цель преследовали авторы языка: хотелось и скорости, и безопасности. Но получилось что-то сильно замысловатое, увы. Порог вхождения очень высокий. Может не такой высокий, как у Плюсов, но всё же намного выше, чем у Си или, прости господи, Go. Про LLM модели знаю. Они, конечно, существенно упрощают понимание кода, но хотелось бы обходиться без их помощи. А без постоянной практики с этим языком это, мне кажется, невозможно, постоянно вылетают из головы те или иные концепции языка или особенности инфраструктуры. Сам язык мне нравится, но полноценно освоить как-то не получается.Не знаю, в чем причина этой сложности. То ли потому, что железо такое несовершенное, то ли много подводных камней в современном программировании, которые надо учитывать. Однако хотелось бы чего попроще. Про Zig знаю. Но его нельзя назвать полноценной заменой Rust. Как и многие другие подобные языки.
> Не знаю, в чем причина этой сложности.В том, что до них еще не дошло, что нельзя написать "умный" компилятор не расширяя синтаксис.
>Про Zig знаю. Но его нельзя назвать полноценной заменой Rust.Он замена си. Раст ближе к плюсам, чем к си.
>Он замена си.Zig не замена Си. Zig по душе тем кому, по тем или иным причинам, не подошёл чистый Си.
>Раст ближе к плюсам, чем к си.
Да это так. Язык Си очень простой. Те кто раньше освоил высокоуровневые языки, попробовав Си говорят, что в Си ничего нет, и что всё делать приходится самому.
По философии и концепции Раст ближе к C++. Потому-что та терминология, которая присутствует в Расте, в чистом Си отсутствует как класс, в С++ присутствует.
Линус Торвальдс пустил Раст в ядро из-за того, что у Раста нет ООП. Я сишник разговаривая с растаманами я их не понимаю. Они такими терминами козыряют, что я просто теряюсь
> Линус Торвальдс пустил Раст в ядро из-за того, что у Раста нет ООПА можно пруф, что однозначно из-за этого?
Так-то в расте есть динамические трейты, работают через vtable как и плюсовые классы. В чем разница?
О тода надо Раст из ядра гнать. Срочно и немедленно.
В раст vtable хранится отдельно от самого объекта. Объект идентичен СИшной структуре если #[repr(C)]. Плюс vtable создается только при dyn Trait (явно)
В крестах vtable хранится рядом с каждым объектом, что может сломать ABI, поскольку его позиция/формат зависят от компилятора. Т.е. не POD по определению. Понятно, почему это для ядра не очень.Только объектно-безопасные методы могут находиться в дин-трейтах (к примеру, обобщенный метод не может), также нет неявных деструкторов/конструкторов. Соотв. vtable хранит только ссылки на методы, без RTTI или метаданных типа. Тогда как в С++ любой класс содержащий virtual метод автоматом получает vtable, даже если динамическая диспетчеризация не используется. Там таблицы содержат RTTI, оффсеты деструкторов и оффсеты при множественном наследовании. Нет проверок на безопасность объектов - каждый виртуальный метод динамически диспетчеризуется (UB через tempalte<>)
Создание-удаление объектов в раст проще - нет скрытых конструкторв/деструкторов. Удаление определяется явно, через impl Drop (если надо явно), и не пишется в vtable.
vtable в раст нельзя передать между юнитами компиляции. В С++ это можно сделать через заголовочные файлы. Так же все общие ядру стуктуры требуют совместимости с Си что в Раст обеспечивается через #[repr(C)], тогда как в .cpp можно потом случайно virtual метод добавить.Драйверы и модули в ядре инициализируются в случайной последовательности, там нет main() одна инициализация вне очереди может крашнуть систему. А в С++ можно будет встретить глобальные конструторы/деструкторы, которые могут там присутствовать неявно. И проблема уже встречалась и в линухе и винде. То что в расте запрещено, в С++ присутствует в style-гайдах.
В общем, выгода в том, что растовые структуры могут спокойно пересекать границы Си/ядра, тогда как полиморфные типы крестов не могут. И нет скрытых control-flow связанных с конструкторами/деструкторами. dyn используется только внутри юнита компиляции. То есть даже если скомпилить отдельный модуль другим раст компилятором, то у него просто будет своя внутренняя реализация vtable, которая не просочится наружу.
>В общем, выгода в том, что растовые структуры могут спокойно пересекать границы Си/ядра, тогда как полиморфные типы крестов не могутЭто имеет значение только в отсутствии нормального апи для драйверов. Но это думать надо, проэктировать, програмировать под это уже будет не fun.
Вот а в сишке всё и без проектирования работает.
> Вот а в сишке всё и без проектирования работает.Угу, оно и видно. Х-к, х-к и в прод. А потом дрова на патч обновлении ядра отваливаются.
Вот что у сишников хорошо получается, так это дырени без проектирования делать))
Спасибо, очень полезный коммент!
Вот минусы по реализации. Трейт-объект весит 2x USIZE + неявные вызовы + отсутствует девиртуализация между крейтами. В С++ один vptr==usize и полноценная девиртуализация. В расте Result<(), Error> заметно срёт в глубоком call-stack, а в С++ такое тривиально инлейнится (не все можно представить как Option<&T>, который оптимизирован)
panic_handler добавляет ~2кб оверхеда на модуль(!), а таблицы размотки (unwind) забанили в ядре. У крестов в ядре нет эксепшенов, что сделает его zer-cost в этом отношении к расту.
То что для MMIO/UAFIO в С++ простой volatile в расте портянка на 30 символов ансейфа.
В расте нет битфилдов (:X) соотв. надо ручками маски-сдвиги писать.
макро asm! в расте урезанный, например не может забиндить %gs операнду. Может это уже пофиксили.
unsafe в расте требует больше внимания чем простой сишный код, из-за Раст-специфичных инвариантов.
Все это терпят из-за приятных гарантий о CVE по памяти.
Вопрос, возможно, наивен, но: почему Haiku (а до нее BeOS) написана на C++ чуть менее чем полностью, ничуть по этому поводу не переживает и вполне себе работает, а вот для ядра Linux C++ и ООП внезапно неприемлемы?
Это как ребёнок спрашивает почему у человека два глаза, два уха, а рот только один.Windows, Beos, Macos - это фирменные ОС для дела, а Linux - just for fun для любителей программирования. C++ слишком сложный, от него fun не получишь
Это совершенно не так. Там вообще нечего учить, по-сути.Не знаю кто пишет что "нужно бороться с borrow checker", наверное какие-нибудь говнокодеры , которых тыкают в их код.
Я вообще ни разу не получил ни одного сообщения о проблемах с заимствованиями.
У меня в коде нет ни одного lifetime явного - всё "просто работает". Да и там всё просто на самом деле.
И нужно учитывать что там где бы ты это использовал + unsafe уже есть какие-то библиотеки готовые (которые сделали эту работу).
Например лично я работаю напрямую с битами и смещениями - куда уж более низкоуровневые операции (пишу свой тип bignum).
Так берёшь библиотеку bitvec и ни одного явного unsafe в коде.
Но чтобы это понять НУЖНО ПРОСТО ПИСАТЬ КОД.
И да, он лучше Zig - безопаснее, надёжнее, больше библиотек и т.п. На Zig ничего сложного не напишешь просто ввиду отсутствия библиотек.
Не будешь же ты свой http реализовывать с нуля по стандарту.
дай ссылку на свой гитхаб
Не дам.
> На Zig ничего сложного не напишешь просто ввиду отсутствия библиотекРеалии современных кодеров
>> На Zig ничего сложного не напишешь просто ввиду отсутствия библиотек
> Реалии современных кодеровРеалии современного мира. "На плечах гигантов" (с)
Время, когда было достаточно утилитки на 10к строк прошло.
Пока ты будешь велосипедить свои реализации для всего нужного, другой воспользуется уже готовым и выйдет в релиз.Экосистема это не пустой звук. Раст смог сделать "достаточное" кол-во либ переписыванием их с других языков. Это дало хорошую проверку жизнеспособности языка на старте и создание базового набора библиотек. А зиг... а зиг нет.
Так растаманы и занимались переписыванием этих утилиток на 10 тыс строк.
> Так растаманы и занимались переписыванием этих утилиток на 10 тыс строк.Да. Поэтому и писать научились, и либы нужные реализовали.
И идея языка провалидировали в реальных проектах и допилили.
> Время, когда было достаточно утилитки на 10к строк прошло.Сказки венского леса. Никуда это время не ушло. Смотря что и смотря где писать.
> другой воспользуется уже готовым и выйдет в релиз.
Смотря что и в какой области. Что этот другой накодит? Никому ненужное очередное похожее на всех других приложение? Нах с такими вообще соревноваться? Пусть пишут свои быдлоподелия и конкурируют между собой за 1.5 пользователя. Если ты делаешь приложухи однодневки, что бы туда рекламы напихать и бегом в магазин приложений выложить, то тебе нужно всё это безоб бесспорно.
> Сказки венского леса. Никуда это время не ушло. Смотря что и смотря где писать.Да что угодно писать.
Пока ты будешь с нуля реализовывать серриализацию или httpRequest, сосед уже предоставит готовую софитину.> Если ты делаешь приложухи однодневки, что бы туда рекламы напихать и
> бегом в магазин приложений выложить, то тебе нужно всё это безоб бесспорно.Ты вообще кажется не вдупляешь о чем речь.
На реализацию ненужного тратится время, а время - деньги. И это не только зп разработчиков.
Сколько было хороших проектов, которые провалились потому что вышли поздно. Если ты не застолбил пользователей, то потом фиг отобъешь часть рынка. Это будет в разы дороже.
> Пока ты будешь с нуля реализовыватьпока ты будешь не реализовывать свой лефт-пад, автор оригинального проснется не стой ноги и повертит вас на своем конце. Когда нет собственного достоинства, нужно всегда равняться на соседа, только не надо забывать, что есть вещи которые мужик должен делать сам, а не доверять это дело соседу, думаю поняли мой посыл, если нет - клиника.
> На реализацию ненужного тратится время, а время - деньги.
А тебе за что платят?
> Сколько было хороших проектов, которые провалились потому что вышли поздно.
пример
>> Сколько было хороших проектов, которые провалились потому что вышли поздно.
>примерWindows Mobile
:)
> Windows Mobile:)
Мимо.
> Пока ты будешь велосипедить свои реализации для всего нужного, другой воспользуется уже готовым и выйдет в релиз.ну я могу также подождать того другого и сцап-царапаю у него, в чем проблема? Дармоед и в Африке дармоед.
> Раст смог сделать "достаточное" кол-во либ переписыванием их с других языков.
Для вас достаточно для меня нет. Я подожду пока на нем будут созданы все средства необходимые допустим для кодирования ОС :)
В Zig нет нормального аллокатора (проверенного, надежного, быстрого).И нет реализации протокола http.
Ну на программируй, в чем дело?
" - Я краснодеревщик, а вы мне, уважаемый Работодатель, пустое рабочее место предоставили. Где хотя бы массив из которого мебель делать?
- Бери топор и вон шуруй в соседний лес, за горой, там полно всяких деревьев...
- Но нам же ценные породы нужны...
- Просто потом цену на шкафы-стулья поднимем и станут для покупателя ценными.
- Но здесь и топора нет, чтобы в лес идти. Да и всех других инструментов. Где пилы, стамески, рубанки?
- Ты что как маленький. Сам сделай. Железную руду для железа вон в той горе накопай, по пути к лесу. И глины по пути не забудь набрать - печку для плавки железа надо будет слепить.
- А для электролобзика, циркулярки, фрезера и шлифовальной машинки, которых я здесь тоже не вижу, электромотор и электричество нужны, кроме стали. Это что же, мне самому и мотор делать? Добывать медь для обмотки? Проволоку тянуть? Дамбу и гидрогенераторы строить? Верно понимаю?
- Верно... Но знаете что, я вижу, у Вас возникает много вопросов и проблем на пустом месте. Мы вообще-то ищем настоящего Профессионала Краснодеревщика, который все проблемы решает самостоятельно и с нуля. Вы нам не подходите, Вы не похожи на профессионала..."
> Где хотя бы массив из которого мебель делать?Нет массива? значит алгоритмическая проблема, которую надо решить.
> - Бери топор и вон шуруй в соседний лес, за горой, там полно всяких деревьев...
А как иначе, вот вам ЯП (топор) и предметная область (лес) - вот и решайте алгоритмическую проблему.
> - Но нам же ценные породы нужны...
Это уже требования к проекту, топор то тут причем?
> - Просто потом цену на шкафы-стулья поднимем и станут для покупателя ценными.
Программировай давай, а за цены - финансисты подумают, а не краснодеревщики.
> - Но здесь и топора нет, чтобы в лес идти. Да и всех других инструментов. Где пилы, стамески, рубанки?
Как нет? ЯП это что? Если бы был бы один ЯП и не было бы машины (ЦПУ) то можно было согласиться, но инструмент ведь рабочее пространство, ресурс, предметная область все доступно. Делай не хочу.
> - Ты что как маленький. Сам сделай
Если для решения тебе не достаточно топора - делай, в чем проблема? Или ты сапожник без сапог?
> Сам сделай. Железную руду для железа вон в той горе накопай, по пути к лесу. И глины по пути не забудь набрать - печку для плавки железа надо будет слепить.
Ну знаешь ведь, что надо делать, так в чем же дело?
> Верно понимаю?
Ну да раз это тебе поможет решить поставленную проблему. А для чего человек собственно создавал все эти инструменты? Придумал электричество и т.д., а шо от отверток отказался в пользу шуруповертов?
> - Верно... Но знаете что, я вижу, у Вас возникает много вопросов и проблем на пустом месте.
Проблемы создают люди себе сами, порой создавая, что либо не понимают зачем они это делают. Кашу из топора можно сварить, а вам электрический инструмент подавай. Да вы даже хижины на необитаемом острове своим электрическим инструментом не построите, а вот топором даже на Марсе, где нет деревьев - построите.
> Мы вообще-то ищем настоящего Профессионала Краснодеревщика, который все проблемы решает самостоятельно и с нуля.
Иначе бы, я давно купил бы мебель в ИКЕИ и по инструкции собери сам с одной отверткой собрал бы мебель.
Какое же глупое словоблудие ты накропал. У тебя даже троллить тупо получается.Ладно, снизойду. Еще одна аналогия, может тебе понятнее станет. Ты застройщик. Для каждой новой многоэтажки ты создаешь новые инструменты и материалы, с нуля, начиная с добычи ископаемых и разработки материалов. Причем инструменты добычи тоже создаешь заново. Старые придуманные сорта пластсмасс и стали использовать нельзя! Только новое для каждого нового дома. Старые краны/лебедки/экскаваторы/бульдозеры/шпателя/молотки и даже каски рабочих не используешь, выбрасываешь после каждого завершенного строительства. Т.е. заново проектируешь и создаешь новые краны, лебедки и т.д. Также не используешь всякие сторонние поделки, особенно всякие зарубежные Комацу и Макиту. Если же ты возьмешь в работу даже не сам кран, а его старую, разработанную тобой же, проектную документацию для создания нового крана, то, поздравляю, ты как раз "используешь библиотеку", против чего ты тут пытаешься, как тебе кажется искромётно, троллить.
Ну, дальше уже развлекай себя сам, ведь и так всё понятно. Бисер я метать устал.
А, не, метну еще немного бисера. Забыл дописать в предыдущем посту: а рядом другой застройщик штампует свои высотки, используя уже готовые краны, бульдозеры комацу и инструменты макита, по типовым проверенным и вылизанным проектам. И работают у него строители по специализациям, с многолетними экспертизами у каждого в своем деле. Т.е. маляр, электрик и т.д. каждый в своей кухне варится годами. Вопрос - у кого быстрее, дешевле, а главное, качественнее получатся дома? У какого маляра-штукатура качественнее будет наложена штукатурка - у того, кто двадцать лет только ее кладет и красит или у того, кто двадцать лет бегает в гору копать глину, добывать железо для шпателя, выплавлять этот шпатель, добывать полезные ископаемые для производства шпатлевки, производит ее (ага, в гараже и лучше химических компаний, которые на этом специализируются) и только потом приступает к оштукатуриванию и покраске (и так для каждого нового дома)?
> Какое же глупое словоблудие ты накропал. У тебя даже троллить тупо получается.топор научись в руках держать, девелоппер ты наш застройщик, ты геологоразведку, сейсморазведку и прочее провел? Коматсу ему подавай, пирамиды либхеры строили ага.
> Ну, дальше уже развлекай себя сам, ведь и так всё понятно. Бисер я метать устал.
успехов в дармоедстве
> Это совершенно не так. Там вообще нечего учить, по-сути.Мне-то рассказывать не надо. Там МНОГО чего надо осваивать и осмысливать:
- странно-замысловатая модель ООП (я привык к ООП в стиле того же Python, которая намного проще, чем в Rust. Разумеется, субъективно);
- ассоциативные типы (в том числе GAT);
- жёсткие области видимости переменных - понимаю, зачем они нужны, объяснять не надо, но простоты это не добавляет;
- lifetimes;
- borrow checking;
- типы из стандартной библиотеки, которые, по сути, являются чуть ли не частью языка, например, в таких областях, как обработка ошибок;
- асинхронное программирование - просто кладезь сложности - пересмотрел несколько статей и несколько роликов, которые пытаются её объяснить, но получилось только у одного автора, который показал, как можно писать асинхронный код не прибегая к ключевому слову async. И то пришлось "курить" его код с помощью LLM, потому что все аспекты, до самых азов (до уровня ОС и железа), автор решил не раскрывать почему-то, хотя это было бы и крайне полезно для понимания;
- многопоточное программирование;
- все навороты cargo;
- все опции компилятора;
- возможные варианты структуры проекта (см., например, исходные код ripgrep, чтобы убедиться, что файлика lib.rs для библиотек может быть недостаточно для организации библиотек).Может ещё что пропустил. Но это не такой уж простой язык, как может показаться после первого с ним ознакомления.
> Но чтобы это понять НУЖНО ПРОСТО ПИСАТЬ КОД.
Зачем вы повторяете то, что я уже и так сказал в своём первом сообщении?
Если вы до сих пор не поняли. Мой первый пост - это сугубо моё индивидуальное мнение, МОЯ оценка языка и его инфраструктуры. Поэтому спорить со мной в данном конкретном случае - абсолютно бесполезная затея. Я не охаиваю этот ЯП, уже сказал, он мне нравится. Но от того, что он мне нравится, он не становится простым для изучения.
Когда в последний раз ты писал многопоточный масштабируемый код? А с современными конструкциями, вроде генераторов? Отладка этого добра в расте удовольствие ещё то. Начинаешь понимать, откуда столько поклонников у додиеза.
Как насчёт Nim?
https://nimble.directory/
Есть такое. Синтаксис раста и так не подарок, а они ещё завозят в него новые фишки. Посмотрим, что будет через пару лет, но уже понятно что это и отпугивает людей.
> получилось что-то сильно замысловатое, увыRust это С++, который почистили от легаси, добавили обязательные строгие проверки по памяти и присыпали пачку современных концепций и подходов, типа работы с модулями (крейтами).
Если знаешь С++, разобраться в расте – изи.> Не знаю, в чем причина этой сложности.
Потому что все современные системы сложные!
И Раст эту сложность не скрывает от разработчика, заставляя обрабатывать все возможные краевые случаи и ошибки. В отличии от других языков, которые пытаются сложность скрыть, что повышает удобство и снижает порог вхождения, но бьёт по надёжности. Го как пример.
Чтобы вырасти нормальному плюсисту, т.е. это основные библиотеки и умение обходить все разнооборазие подводных камней и мин, нужно от 5-7 лет. И то некоторым этого мало. А Rust обычный миддл с опытом дотнет/C# или тайпскрипт осваивает за 2-3 месяца максимум.И в этом проблема. Люди инвестировали годы своей жизни в плюсы, чтобы достичь мастерского уровня. А теперь это все обесценивается более подходящим инструментом, который по факту оказался продуктивнее, легче в сопровождении и быстрее в освоении. Потому наблюдается такое вот сопротивление плюсовой тусовки, т.к. теряется аура крутости и элитарности.
> Если знаешь С++, разобраться в расте – изи.Когда-то меня сильно отпугнула сложность C++. И я тогда бросил разбираться с ним. В принципе, не жалею ни разу об этом.
> Потому что все современные системы сложные!
Думаю, не только в этом дело. А ещё в кривой архитектуре железа, которую в итоге вынуждены "выпрямлять" автора разных языков программирования.
Ну хорошо. Если знаешь питон, разобраться в цпп -- изи. А дальше ты знаешь. Если ты знаешь только лисп, то разберёшься в питоне. Разве что если только паскаль знаешь. то разберёшься разве что в бейсике. Ну а дальше открыта дорога в жс и там по обстоятельствам. Вот чему тебя в школе учили, у тебя российское образование?
> Если знаешь питон, разобраться в цпп -- изи.Ну, не только Питон. На Assembler когда-то простенький софт доводилось писать (забавы ради, не за деньги), на C, на Turbo Pascal, FoxPro (и DOS-овский и Visual), Perl, shell, SQL, PL/SQL. C++ ни разу в жизни не потребовался. А вот ближе к старости почему-то захотелось чего-то новенького, более-менее универсального.
> Вот чему тебя в школе учили, у тебя российское образование?
Нет, у меня советское образование. Я родом из СССР.
А тут такое, чтобы понимать плюсы, желательно иметь опыт работы с ооп-языками, или хотя бы с функциональными. Перечисленное ими не является, это процедурные языки, и все концепции иные (хотя и можно провести определённые параллели). Отсюда и сложности. Раст не является ооп языком в полной мере, что бы там ни говорили, однако, концепции воплощает ровно те же.
> А тут такое, чтобы понимать плюсы, желательно иметь опыт работы с ооп-языками, или хотя бы с функциональными. Перечисленное ими не является, это процедурные языкиПохоже, вы просто не в курсе, что Visual Foxpro - это ООП. Python - это 100%-ое ООП с элементами функциональности. Perl - мультипарадигменный ЯП (в том числе там есть поддержка и ООП и функциональщины). Так что у меня есть опыт работы с обеими парадигмами.
Rust, кстати, тоже мультипарадигменный ЯП. Там есть и ООП, и функциональщина местами. Просто Rust намного более навороченный и требует понимания гораздо большего количества нюансов, на которые в других ЯП не требуется обращать никакого внимания, что, в общем, понятно, потому что он гораздо ближе к железу, чем всё перечисленное (ну, кроме C, конечно же).
Так то оно так, насчёт foxpro не в курсе, но то, какой ООП в перл -- лучше не надо. ООП это что-то вроде c++ или java/c#. Так они все императивные конечно, но ООП вполне конкретно характеризуется. Скажем, лисп ООП. И в расте вместо наследования какая-то шляпа, вот и не взлетает никак. А ведь как раз одна из причин успеха многих ЯП. От фунциональщины там понятное дело кое что есть, он поверх принципов функциональшины и построен.
> И в расте вместо наследования какая-то шляпа, вот и не взлетает никак.Это утверждение далеко от реальности. Взлетел уже. И летает достаточно высоко, во всяком случае крупные производители софта давно его уже приняли и начали использовать.
Но причина того, что не повсеместно взлетел в том, что слишком много в отрасли развелось программистов типа меня, которые напрягаться не хотят, вдумываясь в детали, как оно всё работает (мой опыт с Ассемблером и Си помогает, конечно, но его явно недостаточно). А Раст заставляет думать. Не всем это нравится (что вполне естественно и объяснимо).
То есть, причина не очень большой распространённости Раст не в том, что там наследования нет (которое, как видим, особо и не нужно, Раст прекрасно без него обходится). А в сложности ЯП и его инфраструктуры. То есть, для программирования на Раст квалификация должна быть достаточно высокой. Такие люди обычно хотят достойную компенсацию, на что многие работодатели просто не готовы, у них ведь и на Питоне (Джаваскрипте, Джаве, Голэнг, нужное подчеркнуть) всё работает, зачем платить больше.
Взлетел он ровно так же, как и го. Железной рукой запихнули во все корпоративные щели. Го на фоторамке с фуксией особенно уместно выглядело. Но из успешных программ у раста только пара кусков веббраузера до сих пор, да и с теми больно иметь дело. Только сейчас все программы пишет чатгпт, если с растом у него будет меньше проблем, уже победа. Я так понимаю, это -- основная причина заинтересованности мс в ржавом линуксе, т.е. желание выкинуть кадры с высокой квалификацией на мороз -- они очень дорого обходятся.
> Железной рукой запихнули во все корпоративные щели.Прям запихнули? Народ радостные отчёты пишет, что, де, производительность труда выросла, количество ошибок при этом уменьшилось.
> Но из успешных программ у раста только пара кусков веббраузера
Это неправда. Часть Андроида, часть Винды, прокси-сервер Клаудфлэр, Дискорд, Дропбокс, куча веб-фреймворков (бьющих рекорды по производительности), текстовый редактор Zed, утилита ripgrep и куча другого софта - все используют Rust.
> Только сейчас все программы пишет чатгпт
И это неправда. Не все, а наиболее хорошо изученные (читай, скучные) части программ. Да и те приходится проверять из-за ненадёжности LLM (хотя они и хорошеют со временем).
> Я так понимаю, это -- основная причина заинтересованности мс в ржавом линуксе, т.е. желание выкинуть кадры с высокой квалификацией на мороз -- они очень дорого обходятся.
У вас какая-то очень искажённая картина мира. Основная причина заинтересованности любого программостроителя в Rust - меньшая стоимость разработки и последующего сопровождения. И нет, никуда эти кадры никто выкидывать не собирается, потому что высококвалифицированного программиста заменить LLM на сегодняшний день нельзя. Но изобретать из проекта в проект свой собственный велосипед (как это часто делают программисты на Си, увы) - слишком дорогое удовольствие для сверхсложного современного ПО.
Престарелые программисты самые дорогие, вот их и заменяют. Вполне успешно. А что до восторженных отчётов, так их тоже чатпгт пишет уже давно. Реальные результаты прекрасно можно наблюдать. Это всё видимость. К примеру, есть люди, которые всерьёз считают, что генеративные сети значительно повышают их производительность. На практике это не так, а, кроме того, подобная работа ещё и приводит к определённому отуплению (хотя я тоже очень доволен и чатгпт пишет на awk за меня).
> Престарелые программисты самые дорогие, вот их и заменяют. Вполне успешно.Ещё одно распространённое заблуждение. Не возраст ценится, а квалификация. Квалифицированным можно стать и в 30. И в то же время оставаться низкоквалифицированным даже в 50.
> А что до восторженных отчётов, так их тоже чатпгт пишет уже давно.
Те, которые мне доводилось читать, писали люди.
> К примеру, есть люди, которые всерьёз считают, что генеративные сети значительно повышают их производительность. На практике это не так, а, кроме того, подобная работа ещё и приводит к определённому отуплению
То есть, вы сами с собою решили подискутировать? Не буду вам препятствовать, но мне такое времяпрепровождение не особо интересно.
Если не поддаваться очередному хайпу, то вполне очевидно, что прикладные программы на расте писать невозможно (не более можно, чем на го). Те, что есть, представляют собой исключительно жалкое зрелище, а популярность языка вполне заслуженная и занимает последние строчки рейтингов. На практике раст исключительно дорого и неэффективно, конкуренты съедят (что уже неоднократно было проверено). Какой-то шанс только у корпораций, и корпорации могут позволить хоть на прологе писать весь код. Как раз то, что новички записывают в достоинства раста (cargo и crates) является основным и главным его недостатком. Через десятки лет, возможно, и будет не хуже альтернатив, но к тому времени могут и плюсы до ума довести. А сейчас код писать некому, корпорации всегда будут изобретать свои велосипеды по 10 кругу.
> то вполне очевидно, что прикладные программы на расте писать невозможноДля меня это не очевидно, потому что факты говорят о противоположном.
> Те, что есть, представляют собой исключительно жалкое зрелище
Редактор ZED, например, считается мощным функционально богатым редактором, который ничуть не хуже конкурентов. Утилита ripgrep на голову выше оригинальной grep.
> а популярность языка вполне заслуженная и занимает последние строчки рейтингов
В известных мне рейтингах фигурирует не менее полсотни языков. Rust занимает в них примерно 20-е. 20-е место - это выше середины, а не "последние строчки рейтингов", как вы зачем-то лжёте (зачем?).
> На практике раст исключительно дорого и неэффективно
Google, Microsoft, Cloudflare, Discord, Dropbox говорят что на практике эффективно и дешевле, чем на Си или Плюсах. Я склонен больше доверять им, чем вам. Почему? Потому что с их софтом я имею дело каждый день. А вас... я даже не знаю, как вас зовут. Вы, разумеется, можете иметь своё собственное мнение, ваше безусловное право. Но мне оно неинтересно, потому что совершенно не соответствует реальности. Поэтому прошу вас остановиться и найти другого собеседника, с кем вы сможете разделить свои взгляды.
> Как раз то, что новички записывают в достоинства раста (cargo и crates) является основным и главным его недостатком.
Обе функциональные возможности, на самом деле, конечно же являются достоинством. Почему? Потому что вам не надо рыскать в поисках всего Интернета в поисках необходимой библиотеки или инструментария. У вас для вашего "Hello, world" всегда всё под рукой, причём в достойном исполнении и с богатой функциональностью (cargo - это не только менеджер пакетов, вдруг вы не знаете, это полноценная система сборки + линтер). Если же вы пишете нечто более требовательное к безопасности или вам претят плохо контролируемые зависимости, вы проводите аудит кода той библиотеки, которая вам интересна, фиксируете её версию и дальше используете только её в вашем сверхбезопасном ПО. Также никто не запрещает вам создать свой собственный локальный репозитарий и пользоваться только им, cargo поддерживает и такой режим работы.
> но к тому времени могут и плюсы до ума довести
Скорее, рак на горе свистнет. Плюсы тянут за собой тяжёлый багаж предыдущей совместимости, что является фундаментальной причиной, почему "довести их до ума" не представляется возможным с нынешним морально устаревшим подходом к разработке этого ЯП. Спасти от этого багажа этот ЯП может только схожий с Раст механизм редакций. Но я пока не слышал даже намёка на разговоры об этом.
Всё это очень напоминает аргументацию любителей exbsd. Поживём -- увидим, но пока что ржавчина доставляет только боль, когда проникает в любые существующие проекты. Качество батареек куда ниже, чем у питона, из коробки никакой базовой функциональности нет, даже регулярочки одни кривее других. Тут не о чем говорить, го в этом отношении куда достойнее.
> Просто Rust намного более навороченный и требует понимания гораздо большего количества нюансовежу-ужу приделали крылья, зачем себя мучать, если для "понимания нюансов" есть дракон (асм)?
Затем, что интересно. И полезно для общего развития. Для моей текущей работы мне Rust особо не нужен. Во всяком случае пока. А там, глядишь, найду какое применение со временем, когда начну себя чувствовать более уверенно.
> Затем, что интересно.Ну вот за такой интерес коментом ниже отписал в 4.151, Аноним (90), результат - вот лежит на полу какая-то условно "конфетка", вот интерес взять и попробовать на вкус, а потом (тут смайлик блеющий) буээээээ - "к*кашка". Мораль сей басни такова: хоть и на вкус она "к*кашка", но закинутая в печь, даст вам тепла :) Так что, в "топку" сразу, чтобы греть планету.
Ничего не понял из того, что вы пытались сказать.Каждый сам для себя определяет, что ему интересно. Я вот для себя определил изучение Rust интересным занятием. И нет, я не считаю, что это - к*кашка, как вы ошибочно подумали.
> Ничего не понял из того, что вы пытались сказать.Я пытался донести, что значит "Затем, что интересно."
> Каждый сам для себя определяет, что ему интересно.
Никто с этим не спорит, вообще процесс познания (изучения) чего-либо нового - всегда полезно.
> И нет, я не считаю, что это - к*кашка, как вы ошибочно подумали.
Я не делал этого вывода :) вы мораль басни прочтите.
>> И нет, я не считаю, что это - к*кашка, как вы ошибочно подумали.
> Я не делал этого вывода :) вы мораль басни прочтите.Вот цитата из вашей "морали басни": "... хоть и на вкус она "к*кашка"..."
ну вот это те чувства которые испытывают многие кто решил попытать свой интерес к расту, но от этого раст "к*кашкой" не стал, он в контексте басни - дает тепло :)
> Когда-то меня сильно отпугнула сложность C++А в чем заключалась сложность? Вероятно подача материала неподходящая. Вот меня черт дёрнул пару дней назад, интереса ради, отрыть документации по ocaml (ocaml-5.3-refman.pdf), после первой главы, жесть как хотелось плеваться, нет не из-за того что винегрета парадигм, нет не из-за синтаксиса делай пятью разными способами одно и тоже, а тупо подача материала - отвратительная, и после этого они хотят, чтобы молодежь программировало на этом?
> А ещё в кривой архитектуре железа, которую в итоге вынуждены "выпрямлять" автора разных языков программирования.
ЯП "высокого уровня" должно абстрагироваться от архитектуры, и программисту по сути должно быть пофиг, на какой архитектуре будет исполнение, он же на другом уровне абстракции, а нет, на деле без знаний аппаратной архитектуры далеко не уедешь, поэтому я считаю все ЯП излишними, кроме мнемоник машинных команд.
>подача материала - отвратительнаяПро Rust можно сказать то же. Неправильно про него рассказывают
> Про Rust можно сказать то же. Неправильно про него рассказываютИ что делать новичкам? Правильно, повременить с этим растом, а с возрастом и опытом он станет просто им не нужен, вон некоторые ждут пока язык не обрастет лефт-падами им пользоваться нельзя :)
> И что делать новичкам? Правильно, повременить с этим растомИменно новичкам в первую очередь я бы рекомендовал Rust (вторым или даже третьим языком, начинать, всё же, надо с чего-то попроще) - далее осваивать любой другой язык (кроме C++ и, возможно, ещё нескольких из мира функционального программирования) окажется проще пареной репы.
> а с возрастом и опытом он станет просто им не нужен
Смотря для какой предметной области. Очевидно, что для скриптов Rust не особо подходит. Но для высокопроизводительных приложений с хорошей надёжностью Rust - очень даже годный ЯП. Не идеальный. Но очень достойный.
> вон некоторые ждут пока язык не обрастет лефт-падами им пользоваться нельзя
Без готовых библиотек можно использовать любой ЯП, но не в тех областях, где для разработки выделяются ограниченные ресурсы (а это справедливо для ЛЮБОЙ коммерческой разработки).
> Именно новичкам в первую очередьДетям до школьного возраста не язык необходимо преподавать, а объяснять, что такое язык и для чего он необходим. Потом уже проходят алфавит и т.д. То же самое и с математикой, сначала учат счету, потом всяким числам и цифрам.
> далее осваивать любой другой язык
Все это может и работает, когда есть у кого спросить, когда возникнут 1000500 вопросов, особенно когда в языке одну вещь можно делать 1000500 разными способами, и резонный вопрос - зачем? А если в книге нет на это ответа, то спрашивать надо у автора языка, вот поди и спроси. Многие программисты - самоучки, отсюда - им не у кого спросить, а если материал по языку оставляет после прочтения 1000500 вопросов, тут два варианта - либо материал плохо подан, либо язык реально такой "поханый". Реальность такова, что в большинстве случаях если язык "поханый", то и подача материала будет такая же. Что значит "поханый" - лишенный простоты, избыточный, скрещенный (разные парадигмы), в угоду компилятору и прочие недоконструкции. Тут можно со многим поспорить и расширить это определение. Ну и конечно же это сугубо мое мнение.
> Очевидно, что для скриптов Rust не особо подходит.
Я просто не пойму зачем вы цепляетесь к термину скрипт, это что не программа такая же которая исполняется? Скрипт разве не такой же алгоритм и т.д.? Линукс кернель на джаваскрипте и на брейнфаке можно написать. Может вы имеете ввиду понятие быстрого прототипирования алгоритмов? Язык Си нужен будет тем кто захочет реализовать линукс кернель для платформ, которые поддерживает тот же гцц, а джаваскрипт тем допустим кто захочет запусть его в браузере и т.д. Язык скриптовый или какой-то не скриптовы - не играет никакой роли.
> Но для высокопроизводительных приложений с хорошей надёжностью Rust - очень даже годный ЯП.
ЯП не дает никакой высокой производительности и надежности, это все свойства вашего алгоритма который вы реализуете, и главное в какой среде будет исполнение. Сравнивать компилируемые и интерпретируемые ЯП - бред, и говорить вот моя программа быстрее твоей - бред. Всякий алгоритм имеет единственную оптимальную как по времени так и по пространству версию. Тут сравнивать нечего.
> Без готовых библиотек можно использовать любой ЯП, но не в тех областях, где для разработки выделяются ограниченные ресурсы (а это справедливо для ЛЮБОЙ коммерческой разработки).
В природе всегда существовали дармоеды, куда же бе них. Готовые библиотеки должны пониматься в рамках наименьшей единицы общности, допустим конторы где вы работаете. Брать код "чужой" (от другой конторы, или опенсурс) и использовать его в своих проектах - равносильно "запустить лису в курятник". Кто в итоге будет нести ответственность за "чужой" код? Вопрос доверия всегда открыт. А открыт потому-что, нет нормальных механизмов "доверяй, но проверяй". И за место того, чтобы "доверять и проверять" (тратить ресурсы), думаю легче сконцентрироваться на создании "собственного".
> Детям до школьного возраста не язык необходимо преподаватьДетям дошкольного возраста программирование преподавать рано. Я к тому, что вы подобрали неудачную аналогию.
> Все это может и работает, когда есть у кого спросить
Откройте для себя мир поисковых систем, сайт stackoverflow и LLM (вполне рабочий вариант на сегодняшний день, работает в большинстве случаев прекрасно без необходимости использования первых двух).
> Многие программисты - самоучки
Это, в некотором роде, беда отрасли, к сожалению. Многие берутся за программирование, не понимая на старте, насколько это непростое занятие (при первом условии, что пишется ПО сложнее тысячи строк кода, и при втором условии - что это не ПО-однодневка).
> Я просто не пойму зачем вы цепляетесь к термину скрипт, это что не программа такая же которая исполняется?
Я просто не пойму, почему вам кажется, что я цепляюсь к этому термину. Скрипт - это нечто такое, что не содержит сложной логики и не требует для своей работы сложного окружения (в виде компилятора, линковщика, линтера). Для сложного ПО использование скриптового языка чревато кучей проблем в чём на практике убедилась такая контора, как Dropbox, например.
> Линукс кернель на джаваскрипте и на брейнфаке можно написать.
Можно. Но работать это будет крайне ненадёжно и очень медленно, а сопровождать этот код будет чрезвычайно дорого. Для ОС это недопустимо.
> ЯП не дает никакой высокой производительности и надежности, это все свойства вашего алгоритма который вы реализуете, и главное в какой среде будет исполнение.
Программы, написанные на компилируемых языках, при прочих равных условиях, работают намного быстрее написанных на интерпретируемых. Понятно, что тормозную программу можно получить на любом ЯП и на любом железе. Именно поэтому я написал "при прочих равных условиях".
> Сравнивать компилируемые и интерпретируемые ЯП - бред, и говорить вот моя программа быстрее твоей - бред.
Но умные люди занимаются подобным сравнением. Зачем? Потому что это может важно в некоторых областях: например, в высоконагруженных системах, или системах реального времени, где время отклика программы должно быть предсказуемым, или в системах, требовательных к ресурсам (компьютерная графика, системное ПО, программирование микросхем и т.д.).
> Брать код "чужой" (от другой конторы, или опенсурс) и использовать его в своих проектах - равносильно "запустить лису в курятник".
Выкиньте сейчас в окно то устройство, с которого вы пишете вот это всё. Потому что ваше устройство, о ужас, использует чужой код!
> Кто в итоге будет нести ответственность за "чужой" код?
Зависит от договора с поставщиком такого стороннего ПО и вашего бюджета на такое ПО.
> Вопрос доверия всегда открыт. А открыт потому-что, нет нормальных механизмов "доверяй, но проверяй".
Есть, вобще-то. Называется "формальная верификация". Но это ОЧЕНЬ дорого на нынешнем этапе развития отрасли.
> И за место того, чтобы "доверять и проверять" (тратить ресурсы), думаю легче сконцентрироваться на создании "собственного".
Рекомендую поинтересоваться, во что обойдётся написание собственного Линукса, например. Если же вы лефтпад имели ввиду, то, разумеется, такое проще и безопасней написать самому, если это действительно так важно для вас и вы хотите заморочиться на это самостоятельно, и ваш работодатель (контрагент) готов платить за подобную скорость разработки. Однако предположу, что вы очень быстро будете посланы с вашим подходом куда подальше.
>Откройте для себя мир поисковых систем, сайт stackoverflow и LLMЯ, конечно, извиняюсь, но вы, Пользователь, где живёте? В России сейчас более чем в 30 регионах банят американские CDN в мобильной связи, а cloudflare некоторые и кабельные. Перечислю кого банят: cloudflare, akamai, amazon, oracle cloud, fastly.
А Рустовские сайты rust-lang.org, crates.io, docs.rs , между прочим, распологаются на cloudflareвской cdn и к ним доступа нет.
> Детям дошкольного возраста программирование преподавать рано. Я к тому, что вы подобрали неудачную аналогию.Я вообще-то привел аналогию с естественным языком, на котором говорят все люди, а не ЯП.
> Откройте для себя мир поисковых систем, сайт stackoverflow и LLM
Когда я учился, таких систем не было. И реальные знатоки на них вероятно не чалились бы. Сами видите уровень чатгопоты на том же Опеннете.
> Это, в некотором роде, беда отрасли, к сожалению.
Так дело не в отрасли, область эта - научно-инженерная(прикладная), такая же как математика. Но почему-то есть предрассудки, что математика им не нужна. Отсюда и то, что вы заметили "насколько это непростое занятие".
> Я просто не пойму, почему вам кажется, что я цепляюсь к этому термину.
Под вы имел ввиду многих, не лично вас, потому-что часто замечаю это суждение.
> Скрипт - это нечто такое, что не содержит сложной логики и не требует для своей работы сложного окружения
В смысле? Логика есть во всем ибо даже простая программа (скомпилированная) или скрипт (интерпретируемый) "хелловрот" это алгоритм вывода строки. Средства отладки есть у "обоих" (программа есть программа, я не признаю понятие скрипт как отдельной программы)
> Для сложного ПО использование скриптового языка чревато кучей проблем в чём на практике убедилась такая контора, как Dropbox, например.
Нет никаких проблем, условно чтобы обслужить все человечество программой на "скриптовом" ЯП, возьмите выделите ресурсы для каждого человека и вот вам решение вашей проблемы. Скрипт у всех гарантированно будет исполнен и удовлетворит всех людей. Проблема в деньгах на ресурсы ведь? А, что ЯП должен решать этот вопрос? Вы можете мне гарантировать, что раст мне сэкономит больше чем Си? А я скажу больше, асм - еще больше сэкономит, а что в ответ? Фииии асм...
> Можно. Но работать это будет крайне ненадёжно и очень медленно, а сопровождать этот код будет чрезвычайно дорого. Для ОС это недопустимо.
Надежность его будет одинаковой, а про сравнения "скоростей" речи быть не может, нельзя феррари и коня сравнивать, не потому-что конь медленней, а потому-что конь и феррари разной природы, и не корректно их сравнивать. На счет сопровождении кода, код есть код, это алгоритмы и т.д. его сопровождение не зависит от ЯП, это как лапша-код и в Африке лапша-код. А утверждение, что допустимо для ОС, а что нет - вопрос открытый и требует конкретных определений.
> Программы, написанные на компилируемых языках, при прочих равных условиях, работают намного быстрее написанных на интерпретируемых.
Нету тут равных условий, никто не спорит, что программы исполняемые самой машиной (машинный код) будет быстрее любой другой программы, которая интерпретирует код высокого уровня. Но сравнивать это - некорректно.
> Но умные люди занимаются подобным сравнением. Зачем?
Кто? Зачем? Сравнить двух коней (самцов) еще можно, но сравнить самца и самку уже будет некорректно, ибо природа самца и самки уже отличается. И говорить, что лошадь (самец) всегда быстрее лошадки (самки) - бред.
> Потому что это может важно в некоторых областях: например, в высоконагруженных системах, или системах реального времени, где время отклика программы должно быть предсказуемым, или в системах, требовательных к ресурсам (компьютерная графика, системное ПО, программирование микросхем и т.д.).
Ну тогда всегда можно сказать, что САМЫМ оптимальным выбором должен быть язык машинных мнемоник (асм). Но мы почему-то выбираем Си.
> Выкиньте сейчас в окно то устройство, с которого вы пишете вот это всё. Потому что ваше устройство, о ужас, использует чужой код!
Стоп, а зачем вы путаете понятие потребителя (меня) с понятием производитель (контора программистов, пишущая софт). Для потребителя есть местный продукт и импортный, и ему главное - качество продукта, то есть удовлетворяющих его характеристик (от цены и т.д.) Речь ведь идет о производителе. "Чужой" код это понятие относящееся к производителю, а не потребителю, потребитель в большинстве случаях даже код не увидит (коммерческая тайна).
> Зависит от договора с поставщиком такого стороннего ПО и вашего бюджета на такое ПО.
Ну да, и куплю я у вас продукт если вы не дадите гарантий? Логика говорит, что не должен покупать. А как вы дадите мне этих гарантий?
> Есть, вобще-то. Называется "формальная верификация". Но это ОЧЕНЬ дорого на нынешнем этапе развития отрасли.
Конечно, и там где необходимо это проводится. А теперь вопрос: Если бы те, кто формально верифицирует свой код и берет "чужой" открытый, тогда они могут спокойно поделиться этой проделанной работой над открытым "чужим" кодом, но почему этого не делает - почему? Может они не используют "чужой" код?
> Рекомендую поинтересоваться, во что обойдётся написание собственного Линукса, например.
Зачем именно Линукс? Некорректно так оценивать затраты.
> Если же вы лефтпад имели ввиду, то, разумеется, такое проще и безопасней написать самому, если это действительно так важно для вас и вы хотите заморочиться на это самостоятельно, и ваш работодатель (контрагент) готов платить за подобную скорость разработки.
Тема лефт-пада вообще крайний случай, а сама разработка может быть разной - заказной, где требования зависят от заказчика, и исследовательской-продуктовой, то есть вы сами диктуете требования по ресурсным затратам. Но как показывает современная реальность - "кто платит тот и заказывает музыку". Бизнесу пофиг на чем зарабатывать, на линуксе, написанном на Си или на Джаваскрипте, главное, чтобы прибыль росла.
> Однако предположу, что вы очень быстро будете посланы с вашим подходом куда подальше.
Все ведь зависит от сметы и гарантий качества. Кто-то пошлет, кто-то будет рад со "мной" работать.
>> Когда-то меня сильно отпугнула сложность C++
> А в чем заключалась сложность?Спецификация Плюсов составляет под тысячу страниц. Уверен, ни один человек в мире не знает Плюсы в полном объёме, каждый использует какой-то свой диалект. Мне такой подход не нравится.
> поэтому я считаю все ЯП излишними, кроме мнемоник машинных команд
Пока LLM далеки от совершенства, и их кто-то должен контролировать, высокоуровневые ЯП будут востребованы.
> Спецификация Плюсов составляет под тысячу страниц.Там тысяча страниц из-за стандартной библиотеки, которая к языку никакого отношения иметь не должна.
> Пока LLM далеки от совершенства, и их кто-то должен контролировать, высокоуровневые ЯП будут востребованы.
Так это одно и тоже, ведь компилятор это тот же ИИ, который лучше человека способен генерировать машинный код :) Только для этого "лучше" необходимо каждый раз добавлять новые "подсказки" компилятору. Вот задаю чатгпт одну неизвестную ему проблему, а он конечно же ответа не знает и мне же говорит "не могли бы вы мне намекнуть (подсказать) в какой области мне искать решения", черьезно? намекнуть? :) Буквально вчера пытался гемини объяснить простенький алгоритм, чтобы он написал код, час писал ему, и так и сяк, с примерами вывода, и т.д. - плюнул, и сказал, чем тратить час на объяснения простой вещь какому-то там чатгпт, легче самому реализовать. И все рассказы про то, что это удобно и быстро и т.д. - чушь собачья!
> Там тысяча страниц из-за стандартной библиотеки, которая к языку никакого отношения иметь не должна.Там 1000 страниц именно из-за языка, как такового. Потому что это спецификация языка, а не библиотеки (даже если она стандартная).
> компилятор это тот же ИИ, который лучше человека способен генерировать машинный код
Компилятор - это не ИИ, потому что он не в состоянии самостоятельно писать ПО. А что же он может? Только транслировать код из одного ЯП в другое состояние (или машинный код, или промежуточный кросс-платформенный код).
> Вот задаю чатгпт одну неизвестную ему проблему, а он конечно же ответа не знает и мне же говорит "не могли бы вы мне намекнуть (подсказать) в какой области мне искать решения", черьезно? намекнуть? :)
Контекст будет важен и для человека. Например, вы можете спросить человека "Какую машину мне лучше купить?" Подумайте, как можно ответить на этот вопрос корректно, не зная контекста (ваш бюджет, ваши предпочтения к типу дорог, любите ли вы механику или коробку-автомат и т.д.).
> Буквально вчера пытался гемини объяснить простенький алгоритм, чтобы он написал код, час писал ему, и так и сяк, с примерами вывода, и т.д. - плюнул, и сказал, чем тратить час на объяснения простой вещь какому-то там чатгпт, легче самому реализовать.
Предположу, что объясняли, всё-таки очень плохо. Я не пытаюсь заявить таким образом, что современные LLM совершенно не имеют проблем. Но если алгоритм действительно простенький, то с этим они, как показывает моя и не только практика, справляются очень хорошо.
> И все рассказы про то, что это удобно и быстро и т.д. - чушь собачья!
Это не только рассказы. Google заявил, что производительность труда их программистов выросла на 20% с внедрением LLM. Microsoft уволила какой-то штат программистов (тоже после внедрения LLM). Читал также что какой-то довольно крупный азиатский банк уволил несколько тысяч своих сотрудников (не программистов) с внедрением LLM. Ещё читал статью, как мужик в США выиграл суд, который длился несколько лет. И тоже благодаря применению LLM, которая помогла сэкономить сотни тысяч долларов на юристов.
Но! Вас никто не заставляет ими (моделями) пользоваться. Не правда ли?
> Компилятор - это не ИИ, потому что он не в состоянии самостоятельно писать ПО.Он же генерирует машинный код, который по заявлению "лучше" чем написанный человеком. ИИ ведь по идеи должен куда оптимальнее генерировать машинный код чем тот же компилятор.
> Контекст будет важен и для человека.
Все правильно, контекст и все подробности по проблеме были известны ИИ, а если конкретно без деталей, то из области поиска перестановочного инварианта, и тут ИИ предложил все известные методы, но результата это не дало, и в итоге он пишет, мол дайте мне еще каких-то "зацепок", а это говорит о том, что он не разрешит эту проблему никогда, если не получит (обучится) конкретных решений.
> Предположу, что объясняли, всё-таки очень плохо.
Лол, самое что не люблю во всех этих ИИ это их поддакивание, генерирование текста "не дослушав до конца", и предложение того о чем их не просили, все эти качества "общения" обычно описывают человека, который хочет проявить к себе интерес, выглядеть убедительным, одним словом "умеющим правдиво врать".
> Но если алгоритм действительно простенький, то с этим они, как показывает моя и не только практика, справляются очень хорошо.
Попробуйте попросить сгенерить алгоритм с некоторым списком конкретных требований, потом немного отредактировать требования и т.д. в таком духе он полностью теряет контекст и генерит хрень всякую (вероятно это связано с бесплатным пользованием), но пока желаемого результата я не получал.
> Это не только рассказы. Google заявил, что производительность труда их программистов выросла на 20% с внедрением LLM.
А где конкретика?
> Microsoft уволила какой-то штат программистов (тоже после внедрения LLM).
Лол, интересно за какой они продукт отвечали?
> И тоже благодаря применению LLM, которая помогла сэкономить сотни тысяч долларов на юристов.
- Эй гпт, придумай мне стратегию защиты в суде
- Напишите мне ФИО судьи, чтобы я накопал на него компромат :)Ну вот это довольно реалистичный пример, чем дела с программистами.
> Но! Вас никто не заставляет ими (моделями) пользоваться. Не правда ли?
Ну и телевизЕр смотреть меня никто не заставляет, ведь там тоже "потоки правды льются в наши глаза и уши". ЛЛМ ведь не база знаний или экспертная система? Если сравнивать википедию и ЛЛМ, я больше поверю статье в вики чем "высеру" ЛЛМ, а все потому-что в вики хоть источники инфы указываются. Ну да, ЛЛМ тоже якобы предостерегает "мелким шрифтом", "гемини может выдавать неточные ответы, всегда перепроверяйте результат" - отсюда вопрос, зачем тратить время на это, если можно обратиться к более авторитетным источникам информации. ЛЛМ хорош как поисковик, он понимает поисковую строку и может лучше выдавать результат.
>Порог вхождения очень высокий.Rust - это профессиональный язык, поэтому сложный.
>Может не такой высокий, как у Плюсов,
нет, гораздо выше.
> Rust - это профессиональный язык, поэтому сложный.Любой профессии - профессионально учат, вон выше отметил про отвратную подачу обучающего материала. В ПТУ не профессионалы поступают, а новички.
> Rust - это профессиональный язык, поэтому сложный.Термин "профессиональный" к языку программирования не применим. Потому что сфера применения Rust не ограничена только теми областями, где обязательно платят деньги. А именно наличие денег взамен на оказанные услуги определяет профессионализм.
>>Может не такой высокий, как у Плюсов,
>нет, гораздо выше.Всё-таки ниже. Не на порядок, но существенно. Перечислю то, что известно лично мне:
1. Нет хрен знает скольких способов инициализации экземпляров класса.
2. Нет множественного наследования (да и вообще наследования).
3. Нет шаблонов (templates), контрактов, концептов. Трейты проще намного. Как и дженерики.
4. В Rust компилятор контролирует такие вещи, как выделение памяти, гонку данных и подобные распространённые ошибки. В Плюсах надо заботиться обо всём самому, а для этого надо иметь достаточно высокую квалификацию.
5. В Rust отсутствует UB. В Плюсах это и в хвост и в гриву, и программист обязан знать о нём и учитывать при разработке программ.Вдобавок Плюсы тащат за собой весь накопленный "багаж знаний". В Rust для изоляции неудачных вещей существуют editions.
>Термин "профессиональный" к языку программирования не применим?? Как? Языки программирования с самого рождения компьютеров всегда делились на профессиональные, любительские, учебные, научно-исследовательские.
>инициализации экземпляров класса
Используйте только один способ - униформный.
>Нет множественного наследования (да и вообще наследования).
В Ruste наследование есть, но оно производится по-другому. Например через расширение трейтов и расширение набора методов структуры при помощи реализации трейта для этой структуры.
>Нет шаблонов
Умм? Вы о чём? Как нет?
>контрактов
Да, они не особо нужны, можно обойтись assertionами
>концептов
Как нет? Когда задаётся шаблонный тип, скажем, <T: T1+T2> - то T1+T2 это же и есть указание и ограничение для типа
>"Rust компилятор контролирует такие вещи, как выделение памяти, гонку данных и подобные распространённые ошибки. В Плюсах надо заботиться обо всём самому, а для этого надо иметь достаточно высокую квалификацию.
>В Rust отсутствует UB. В Плюсах это и в хвост и в гриву, и программист обязан знать о нём и учитывать при разработке программ."Так это говорит о том, что у Rust и C++ разная область применения. Rust - надёжный высокоуровневый из одной области с Java и Go, он как и они предназначен для автоматизации бизнес процессов (в том числе и для создания информационных систем).
А C++ - это же низкоуровневый язык, это объектно-ориентированное расширение С, а С - переносимый язык ассемблера. Конечно в языке ассемблера программист должен сам всё контролировать
> используется собственный тулкит с библиотекой виджетоврамки на виджетах надо потолще! а то многим экран 4К нечем заполнить!
А классный язык. Сначала придумали ограничения и теперь всю жизнь посвятят созданию способов их обхода. Отличная стратегия чтобы никогда не лишиться работы
Поделись с нами своей мудростью, аноним.
Какие способы обхода уже придумали в расте?
Rust хороший ЯП, но я перешёл на V
> Ещё язык не стабилизировали, а уже удаления платформ пошли...Ну так i686-pc-windows-gnu же!
Сам i686 нинужон, а windows-gnu и подавно.
когда появится rust# и let safe в unsafe блоках
Тут много комментаторов опять начинают то же самое, из темы в тему.
Ответьте сначала (тогда так и не ответили), что такое "дописать ОС" ?
[cpde]
if let Channel::Stable(v) = release_info()
&& let Semver { major, minor, .. } = v
&& major == 1
&& minor == 88
{
if let Rust::Syntax(wtf) = crap()
&& let = Devs {noobs, dumbass, hipsters, ...} = wtf
&& noobs = fuckoff
&& hipsters = fuckoff
&& dumbass = fuckoff
>
> if let Channel::Stable(v) = release_info()
> && let Semver { major,
> minor, .. } = v
> && major == 1
> && minor == 88
> {
>
> Очень читаемо! Кажется понял!Вобще-то, это обыкновенное сопоставление с образцом/деструктуризация из ЯП семейства ML/Prolog/Haskell.
Поэтому таки да, вполне читаемо для тех, кто не только в школе Турбопаскаль изучал или курсы "войти в ойти за 14 дней" просмотрел.
Вот тем да, не повезло - но их, походу не только Злобные Растоманы угнетают, но даже питонисты с жабоскриптозниками (где это тоже, пусть и более "легкой" форме, завезли). Бедолаги.
Если вас смущают такие простые конструкции, может вам не место в этой профессии?
Это комментаторы ещё icon не видели, которым раст очевидно вдохновлялся.
Шел 2025 год, а идеи DOS запихнуть ядро и ПО в одно адресное пространство все еще бударажат умы школьников