> Пока еще нет. Но вообще рассматриваю идею выучить его когда в gcc
> будет нормальная поддержка и я пойму как обходиться без закладывания на
> стремные пакеты из реп от гугломайкрософтамазона.

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

> А таки у сей есть слабые стороны...

У всего есть слабые стороны.

> 1) Те доперли до данных фиксированой ширины. А не "int" е...чий! В
> сях этот рак вклинился очень глубоко. Поэтому в макросах, enum и
> проч возникает много вопросов "какой реально тип данных будет?!" и "безопасна
> ли такая математика вообще?". Особенно если учесть определение "int" в стандарте.

Потому что типов нет. Есть байтики, а ты сам можешь их интерпретировать. И раст и вообще всё именно так и работают. Где-то с большим контролем, где-то с меньшим. Нет у процессора знания что же туда положил программист на ДРУГОМ КОМПЬЮТЕРЕ НА ДРУГОЙ АРХИТЕКТУРЕ С НЕИЗВЕСТНЫМИ ВВОДНЫМИ. А в пределах одной программы и у сей никаких проблем нет. Компилятор знает на сколько байтиков у него int, а всякие извращенные типы инта используются крайне редко на редкоиспользуемых архитектурах (а не только x64 и arm как на расте). Более того именно из-за этого комитет по плюсам так долго мурыжил C++11 в котором ABI наконец решили поменять. И у раста будут точно такие же проблемы (если уже не случились). Но смузипогромистов не знакомых с ассемблером это конечно вряд ли волнует, для них программа это не инструкции, а типы и классы головного мозга.

> 1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum
> не распостраняется! По крайней мере в цивильном и контролируемом виде.

Не понял.

> 2) integer promotion в си работает совсем не так как представляло себе
> большинство кодеров. Почему это должно быть через такой @нус для меня
> загадка. А ваш код переживает -Wconversion без единого варнинга? Скажите честно!

Вот как раз integer promotion достаточно подробно описан в стандарте. Большинство кодеров (подходящее слово) очевидно не читали его и не собирались, но ВНЕЗАПНО он работает не так как они ОЖИДАЛИ. Ну знаете ли, многое работает не так как я ожидаю.  

> 3) UB. Извините но в си это за гранью добра и зла,
> стандартизаторы упростили жизнь себе в ущерб остальным. Даже wrap "int" -
> ub?! Потому что было минимум 2 формата хранения signed? А сам
> "int" - что угодно, от 16 битов и далее со всеми
> остановками? И сколько кода готово все возможные варианты "int" без фаллаута
> схарчить?! Примрено нисколько?! Круто! А мы точно хотели такие стандарты и
> такой код? Потому что он разваливается от тыкания палочкой.

Уже обсуждалось. Специфичные условия чтобы развязать руки разработчикам компилятора. В реальной жизни в рамках одной программы проблемы не встречается, компилятор знает что у него UB и как на него реагировать, еще и расскажет об этом. А то что байтики на разных компьютерах могут перекладываться по-разному, так это ВНЕЗАПНО всегда будет, хотя бы из-за разных архитектур (собственно поэтому и добавили UB). Мне и самому не нравится концепция UB, я считаю ее неудачной (да и авторы тоже). Но сишники уже на нее наступили, а раст...ее повторил! При этом UB в си это плохо-плохо-как-так-можно, а unsafe в расте который ТОЖЕ САМОЕ это почему-то благо. Лицемерие, сэр.

> 4) Переменная типа "enum" в си жрет любой хлам. Даже зачастую без
> варнинга. Круто, но можно это и получше сделать так то.

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

> 5) В сях аннотации массивов весьма декоративные. В функцию можно с кормить
> func(arr[10]) но реально это - указатель. Без малейшего намека на bounds
> checking. Продвинутые анализаторы в принципе могут поспорить с этим но по
> дефолту это так не работает и аннотация смысла не имеет. Можно
> через struct сделать - но тогда это крайне неэффективно будет.

Как и в любом другом языке. И в расте тоже (кто-то из растоманов даже ПРЕДЛАГАЛ ОТКЛЮЧАТЬ ПРОВЕРКУ ВЫХОДА ЗА ПРЕДЕЛЫ МАССИВА ДЛЯ УСКОРЕНИЯ ПРОГРАМММ НА РАСТЕ, ну просто верх лицемерия). Внезапно и в сях ты можешь использовать типы с bounds checking и подозреваю при грамотно написанном коде производительность будет выше чем в расте.

> 6) Struct в си кстати отдельная боль. На уровне апей и абей
> профачено все что можно профачить. Поэтому если вы мечтали о структурированом
> апи, да еще с предсказуемым аби - забудьте. Хотя затрахавшиеся люди
> все равно стали нормальные апи с "struct" делать. Потому что неструктурированные
> апи без аннотации намерений кодера ведут к багам.

Такие абстрактные вещи сказать про любой проект/ЯП и т.д.. Про то что у N отстойное апи я слышу всю жизнь. У N меняются названия, языки, разработчики, платформы, годы разработки, но смысл всегда один "неструктурированный, неудобный, непонятный апи", даже сейчас во времена протобафа. Очевидно это больше психологическая проблема, чем технологическая.

> 6.1) Битовые поля в оных. Это грабледром. Код который генерят компилеры ужасен.
> А определено это так что можно получить более 9000 грабель. Ряд
> кода на это кладет и все равно юзает. Потому что все
> остальные способы еще ужаснее. За это он становится непортабельным и этот
> арбалет - с термоядерным наконечником стрелы. Эта обугленная косточка - пятка
> кодера который пытался перенести сие на соседнюю платформу. Не прокатило.

Вот тут согласен, все популярные компиляторы  это !@#$%^, особенно gcc. Ну а раст еще больше этого !@#$%^ добавляет и внезапно работает на... сишном llvm. Ну т.е. да, разобраться что и почему генерит компилятор это проблема, а раст ВСЕ ЕЩЕ УСЛОЖНЯЕТ.

> 7) Даже самый крутой статический анализатор не знает что вы намеревались дать
> в void* и было ли это валидно, и не порушит ли
> это память. Узнать это можно только рантайм чекерами типа asan, делающими
> из сей долбаный дотнет. А в математике указателей можно прострелить себе
> пятки более 9000 разных способов.

Уже писал. Не используй указатели где не нужны. Почему-то unsafe для тебя норм, а не использовать указатели по каждому чиху (что тоже своего рода unsafe) тебя не устраивает.

> 7.1) Сишники повернуты на сабмите неструктурированного хлама в функции и поэтому аргументы
> не подлежат какой либо автоматической проверке. Что ведет к морю багов.

Частично согласен. Только вот раст вместо того чтобы избавиться от этого где можно (понятно что от байтиков и каста непонятно чего в ожидаемое не избавишься), например от макросов...еще все ухудшил и создал для макросов отдельный язык. Растоманы, вы больные. И лицемерные.

> 7.2) И возврате такого же хлама. С тем же эффектом. В си
> вообще нельзя вернуть 2 значения по простому. На самом деле, правда,
> struct это позволяет. Но за это вас проклянут по линии ABI.

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

> 8) 1, 1U, 1UL и 1ULL это 4 довольно разные вещи. А
> 01 вообще - октальное число. Как и +/- 0 в плавучке.
> И граблями это может #%нуть мама не горюй.

Так ты же можешь выбрать что-то одно и использовать. А остальное не использовать. Ну и в расте не то чтобы сильно лучше, например 0b1111_0000. А еще в расте есть юникод, который нехило так добавляет интересных применений в коде.

> 9) Половину stdlib сей стоило бы запретить к использованию. Особенно олдовые функции
> работы с строками и неудачно сделанную аллокацию памяти где то забывают
> освободить, то дважды освобождают, то юзают после этого - и ничего
> хорошего конечно же не выходит.

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

> ...за последнюю неделю я зашиб минимум 2 ошибки работы с памятью (unchecked
> alloc) и чЮдную математику сабмитящую (в который раз!) в массив отрицательный
> "int" как индекс.

А я видел 2 аварии, переводим всех водителей машин на самокаты? Примерно такая же логика у растоманов. "А машинам можно будет ездить только по unsafe дорогам" !@#$%, кэп, итак все нормальные люди так уже и делают.

> Ну он по крайней мере решает ряд осточертевших проблем сей.

Пока ни одну не услышал.

> Создает ли
> взамен больше проблем чем решает - это мы будем посмотреть. Для
> начала с безопасной дистанции, а потом как пойдет.

Уже видно.

> Конечно же с ограничениями. И длииииинный список рулесов типа MISRA какой намекает
> что половина этого должна была быть вбита в стандарт, с расчисткой
> от UB, недоговорок и маразма. Но это не было сделано. Поэтому
> наш софт норовит нас отыметь.

Если вы пишете софт для АЭС на сях, то у меня плохие новости. И на расте у вас будут точно такие же проблемы.

> А жесткой логикой или мясом рулить
> такими вещами получается еще хуже. Эзотерика типа ады деланая академами -
> для системного програмизма непригодна от слова вообще. Пусть сами ей пользуются,
> перепрофилировавшись из теоретиков в системных кодеров, если им так угодно. Тогда
> глядишь их попустит ментальный булшит чутка.

Не подскажешь где ваш софт используется, может я успею переехать?

> RT_LINUX к раст не относится - но намекает что линух очень хотят
> юзать для управляющих систем толпа народа.

Так он не для управляющих систем. Он для "типа управляющих систем". Т.е. какому-то музыканту ЦАП наверное заменит, а вот для чего-то серьезного надо использовать специализированные RTOS. Т.е. RT в линуксе это "мы попробуем подтюнить линукс чтобы снизить задержки, но ничего не гарантируем". Где-то применимо, но далеко не там где нужны реальные RTOS.

> А раст... некоторые кодеры ядра полагают что он им позволит лепить меньше
> багов и писать более читаемый и майнтенабельный код. И они имеют
> определенный пойнт.

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

> И с сями это приблизилось
> к своим лимитам. В силу особенности конструкции сей. С11 немного улучшает
> это но - лишь маргинально.

Вот только лучше пока не придумали.

> А у кернела есть более 9000
> собственных костылей для компил-тайм чеков, воркэраундов сишной идиотеки и много чего
> еще. Это не значит что нас не задолбало i++'й раз изобретать
> вел с квадратными колесами.

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

> Но
> у него есть предпосылки есть ряд вещей сильно лучше чем си.

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

> Нет, вон тот код с вон тем качеством - оставили таки мои
> предшественники.

Ваши предшественники это не деды. Это вы. Деды это Столлман, Ритчи, можно наверное Линукса туда запихнуть. А 35летний мужик который уволился перед вами это ваш современник и вероятно он и дальше пишет код в другой шаражке.

> Это ляп сразу на уровне дизайна конструкции ЯП.

А ляпы в конструкциях раста вас не смущает? Или итераторы вместо индексов (которые тоже есть в расте) существенно меняют дело?

> Ну, не сишникам на магические символы жаловаться. Будете вырубаться - достану из
> загашника прикольные конструкции на си которые таки - формально валидный код.
> У меня есть.

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

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

Похвальное качество но раст в этом не помогает.

> UB это UB. Это не unsafe, это х-вые стандарты. И только. Если
> что я махровый сишник повернутый на антибаги.

Который не знает что Linux RT это не RTOS и вероятно не знает альтернатив? Который не знает как пишут софт с особыми требованиями к надежности? Который знает проблемы указателей и стандартных типов, но не знает современных альтернатив и не использует их? Который ругает си за проблемы, которых фактически нет у практикующих разработчиков, но про которые пишут новички столкнувшись с проблемами потому что учились по учебникам 1980ых переведенных в РФ в 2000ых? Вы либо студент, либо начинающий разработчик какой-то шаражки, либо пришли из какого-нибудь особо высокоуровнего языка вроде джавы и не особо развивались.

Практически все что вы назвали сводится к теоритическим проблемам. Их часто ругают, но по факту они не столь влияют на работу. UB ну есть такое, есть предпоссылки почему они попыли в стандарт, стандарт не описывает как с ними работать, потому что не должен, реализации довольно успешно их обрабатывают. Да, можно встретить на конференции как какой-нибудь проженный сишник ругается на UB в стандарте в какой-нибудь специфичной ситуации из которой он вполне успешно на практике выходит. Встроенные типы си из коробки были рассчитаны на производительность и простоту, а не на разработку надежного кода, а сейчас просто являются наследием. Для этого есть отдельные либы, есть отдельные гайдлайны по современному безопасному кодингу, потому что применений множество и разработчики стандарта си не ограничивают применение. Вот например регэкспы - кому-то нужны быстрые проверяемые, кому-то нужны быстро компилируемые, кому-то с определенным функционалом, а кому-то с наименьшим количеством потребляемых ресурсов, кому-то под опеределнную архитектуру, а кому-то под определенные данные. Что должен сделать разработчик ЯП?
1) Ограничить оптимизации компилятора (явно прописать какие типы и как должны использоваться и сколько байтов в них должно быть и все равно не достигнуть бинарной совместимости на разных платформах), зато без UB
2) Ограничить сферу применения (по сути написать фреймворк по конкретную задачу, как сделали в php, тогда ЯП не будет способен использоваться в других сферах)
3) Описать все варианты (нереально, по сути сводится к п.2 только с переусложеннным ЯП, в некотором роде плюсы частично следовали этой логике и раст ее частично применяет, тот же safe/unsafe это попытка совместить две области).
4) Описать только то что явно понятно (и получить UB, а реализацию оставить на откуп компиляторам)
Теперь уберем первый пункт потому что непонятно какая архитектура будет через 5-10 лет. Теперь уберем второй пункт потому что си это язык общего назначения. Теперь уберем третий пункт потому что си это язык общего назначения. Прошу, выбирайте.

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

В целом согласен. Но на мой взгляд комитет просто видит свою цель в строительстве нового языка, а в неполомании текущего. Очевидно что как только комитет начнет ломать ABI (как раст), то на си все сразу забьют, поэтому он вынужден ломать оооочень медленно почуть-чуть, чтобы жильцы (и это не хипстеры-студенты, а целые устоявшиеся отрасли) успели переехать. С другой стороны на си итак рано или поздно забьют. Но я надеюсь что за это время придет что-то поадекватнее и посовременней раста и желательно без корпораций которые будут полностью контролировать закулисье ЯП.