> синтаксис раста. Потому что в этой строке ни одного макроса.

А я разве говорил что они там есть? Мну было интересно можно ли ту наркоманщину сделать более симпатичной и читаемой, без таких тантров? Потому что вероятно в ядре этого довольно много надо будет и такие загогулины выписывать каждый раз - это точно круто, читабельно и вообще, апгрейд? :) А так да, я таки не растаман. Стану ли я уметь раст когда-либо? А кто его знает. Там есть интересные идеи, но скверная экосистема и синтаксис костылями оброс до уровня покруче плюсов, пожалуй.

> А '?' это оператор распаковки Option value, try_new возвращает Option<Self> (можно глянуть
> доку https://docs.rs/boxext/0.1.6/boxext/trait.BoxExt.html)

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

> Это гарантирует Null safety - компилятор тебя обяжет или получить значение и
> работать с ним, или обработать это одним из способов.

Само по себе это может даже и не плохо, но...
1) А что если проблема не только null?
2) Не могло бы это выглядеть как-то менее наркомански?
3) Вот такого в кернеле вероятно будет везде и всюду. Это что, везде будет вот эта чисто техническая дрянь на полэкрана?

> И не нужно будет писать кучу проверок на null при обращении к значению.

С другой стороны, при проверках автор _в курсе_ code flow и _понимает_ как более-менее без проблем оттуда при факапе свалить. А какой-нибудь внезапный эксепшн в тыкву, в кернельном коде - ну, блин, апликухи то на хрусте резко умирают "для безопасТности". Но боюсь что такая обработка проблем кернелом у юзеров энтузиазм не вызовет. Хотя, возможно, MS и хочет нам из линуха Win95 устроить?

> Т.е. без ухищрений невозможно будет обратиться к null объекту.
> В отличие от с и с++ - там или проверяешь каждый раз,
> или забиваешь и надеешься на лучшее.

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

Бонус этого варианта в том что...
1) Это уже совершенно точно баг ядра а не вываливание в fallback path по ауту памяти или чему там еще. Ядро не должно умирать даже если RAM кончилась, поэтому plan B на случай невыделения памяти у кода должен быть. Иначе будет полное булшит бинго. Вплоть до жесткого корапта данных и прочих прелестей. Конечно не потому что из буфера вылезли, а потому что желаемое совсем не существовало. Но какая кому разница если в итоге какая-нибудь там ФС данные профачит?
2) Это вообще совсем ничего не стоит - MMU и так есть, он на уровне железа доступы к страницам чекает всегда - и на доступ к 0-й странице просто возбухнет как обычно.

И профит от этого наступает... например, в чем? Я бы сказал что бывают системы без mmu но там видите ли линух экзотика, и это (лол) нарушает допущения хруста. Он без MMU не очень то и безопасный и может на раз не только поиметь stack overflow но и перетереть оным унутренние состояния и что там еще, если оно ниже было.

> Это кстати не изобретение раста - оно появилось в эйфиле, а потом
> в C#, Kotlin, Swift, Dart и других.

Они видите ли ни в раз не позиционируются как системные яп...

> Как будто что-то мешает написать аналогичное на расте. Ну, только без богомерзких begin-end.

Первое на самом деле декларит массив структов, второе его терминирует. Это некий tradeoff, дело в том что массив struct'ов разного размера - безразмерный и я не знаю когда уже пора отвалить. Для парсера критерий терминации - специальный токен, "это последняя запись".

Фокус с END убивает 2 зайцев. Закрывает заполнение массива и железобетонно вешает запись-терминатор, удостоверяясь что парсер совершенно точно не будет out of bounds парсить "потому что лох забыл терминатор". Видите ли compile-time построение прогеров и антикосячные трюки нравится не только растаманам.

> let mut menu = Menu::new();
> menu.add("1", "Do something 1!", handler1);
> menu.add("2", "Do something 2!", handler2);

Ах да, я не сказал одну мелочь? Все меню в итоге являет собой одну большую *константу*. Это полностью precomputed в compile time - идет в именно RODATA. В случае МК в ридонли флеху, которой у меня видите ли больше RAM'ы.

Если кто не понял, это на самом деле дебажно-конфигурационные менюшки по типу сигейтовского монитора на сериальной консольке. А чо, я хуже сигейта? Ну и сдампить лишку памяти в дебажный шнурок парсером - последнее что бы мне хотелось в фирмвари. А вон тот Menu::new(); точно уйдет целиком в RODATA? Или таки будут динамические вычисления в рантайм, хлам в RAM и проч?

> И добавляешь сколько нужно. И никаких чеков, никаких закорючек. Даже более короткий
> и существенно менее отвратительный чем ваш вариант.

У моего варианта простые, понятные даже дауну правила. И он не даст лохануться даже, вот, сишнику. И бонусом это наглухо RODATA, настолько что целиком отправляется в flash ROM. И все потребные смещения компилер тоже предвычисляет так что парсер получает сие как массив структов а не какие там еще указатели и - довольно вменяемо итерирует через это все :)

> Конечно высокоуровневее. В си вы опечатались и вместо значения одного enum написали
> другой такого же базового типа. И ведь молча схавает. Про nested enums можно даже не вспоминать.

Си схавает. Статический анализатор - может и прочухать. Ну и я туда допустим адреса HW regs помещаю. Если я опечатаюсь в адресе - я по любому completely f...d up.

> Null safety - спасает от целого класса ошибок.

А оно не может в более generic проверки? Скажем, часто такая проблема: я знаю что входной параметр валиден от 1 до 100, а если больше - конкретное д-мо! Да, можно runtime проверку этого - но, блин, в фирмвари runtime error булшит полный. Я для сей научился макросами местами чекать такое, но это налагает жесткие лимиты: должно быть compile time constant. При том шаг в сторону (например передается как входной параметр функции) и оно уже не катит. В смысле компилер не умеет в range-analisys чтобы понять что там. Хотя нет, падло именно это делает для dead code elimination и оптимизации кода! Но извлечь сие знание для анализа constraints на передаваемый функции параметр в compile time....

Хруст имеет чего такого интересного предложить как именно compile time checks подобных вещей? В рантайме то любой рак может, но там уже малость поздняк в системщине, если честно. Как вы относитесь к unexpected termination фирмвары вашего гироскутера? Морда на асфальте одобрит это?

> Паттерн-матчинг - не киллер фича, но штука крутая (не, ну можно конечно все тоже самое
> нафигачить ифами, но... зачем?) Zero-Sized Types. Много элементов
> системного программирования.

А вон пример специфичной вещи системного программирования. А покажите как это на русте?

> И это без наверное главных фишек раста вроде borowing, ownership и lifetimes.

Так то я даже не спорю что в расте есть некоторые здравые идеи. Но они ориентировались все же на full blown апликухи в основном, а про аналог "freestanding" из C99 кажется не очень задумывались.

> Да тут очень долго можно перечислять. Потому что си это по факту
> переносимый человекочитабельный ассемблер.

И зачастую именно это я на допустим микроконтроллере и хочу - очень тонкая прослойка между мной и железом. А потому предсказуем чуть ли не потактово и я на уровне интуиции понимаю какой код и данныые будет вот тут.

> А синтаксис - это вкусовщина. Кто-то обожествляет лисп, а других от него
> блевать тянет. Или паскаль (хехе, begin-end). Но минимального знания раста дальнейший
> разговор не имеет смыслы - вы просто не совсем понимаете что там написано.

Насчет вкусовщины - на мой вкус даже в сях довольно много закорюк, у которых с читаемостью "не очень". Имхо зря rust усугубляет это. Я конечно понимаю что клаву топтать всем впадлу но все же. А больше всего в подобных вещах анноят всякие не однозначно трактуемые символы и проч, если на мой вкус.