Вполне возможно что это (fuchsia) обманка. Микроядро (древнее) Mach с обвязкой на C++. Смысл какой? Пытаются сделать Symbian 2.0? Так Симба была на другом микроядре EKA2. Если и брать какое микроядро, то из линейки L4 (L4KA,OKL4,seL4) и делать обвязку.

Откуда ты взял в Fuchsia микроядро Mach, да ещё и на C++? Там Zircon, который есть переосмысление Little Kernel и имеет некоторые общие корни с ядром Haiku.

Яп - Modula3, возможно с небольшой доработкой

Очень смешно.

Intel "залип" на Rust

https://3dnews.ru/993325

Хорошо или плохо?

https://events19.linuxfoundation.org/wp-content/uploads/2017/11/SecurityInZephyrAndFuchsia.pdf

"Fuchsia: The Zircon Microkernel. • Initally derived from … Mach (DTMach/ DTOS) and Fluke (Flask). "

Плохая аналогия. C это ядерный реактор без средств защиты и автоматического отключения, построенный в центре города. Если персонал облажается, весь город взрывается к чертям. А Rust и Go это реактор в горах, залитый бетоном и напичканный тремя слоями автоматики. Да, чуть менее удобно добираться, зато никто не умрет.

Ну камон, C это единственный язык, где фатальные ошибки в коде не ловятся компилятором и должны ловиться программистом по одной единственной причине: потому что так сложилось. Нет ни одной технической причины для существования UB, это следствие организации «экосистемы» в 80х и 90х.

В смысле хорошо или плохо? Кому хорошо?

В плане того что Intel собирается «давить», протаскивая им нужные фичи в язык

Intel собирается контрибутить. Почему нет?

Зачем ты лжёшь и подменяешь цитаты из этой презентации?

По твоей же ссылке:

Fuchsia: The Zircon Microkernel
Initially derived from Little Kernel (LK)

Our early work was in the context of capability based microkernel operatng systems.
– Mach (DTMach/DTOS) and Fluke (Flask)

Уже понял, не Mach а Magenta

Magenta это просто бывшее имя Zircon до публичного релиза этой Fuchsia.

C это единственный язык, где фатальные ошибки в коде не ловятся компилятором

компилятор это инструмент для компиляции. внезапно. то есть компилятор обязан ругаться только если не понимает инструкций программиста. а если компилятор сообщает еще какую-то дополнительную инфу, то девелопер должен отвесить разрабам компилятора поясной поклон и три раза произнести «слава роботам» и «большое спасибо».

и должны ловиться программистом

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

Нет ни одной технической причины для существования UB

есть, и причины эти даже описаны. например, отсутствие проверок на выход за границы массива или переполнение целого, в отдельных случаях дают 30-50% ускорения.

компилятор это инструмент для компиляции. внезапно. то есть компилятор обязан ругаться только если не понимает инструкций программиста. а если компилятор сообщает еще какую-то дополнительную инфу, то девелопер должен отвесить разрабам компилятора поясной поклон и три раза произнести «слава роботам» и «большое спасибо».

Ну то есть опять аргумент из серии «деды страдали и нам завещали», ведь технических причин заниматься подобной ерундой нет уже лет тридцать.

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

Либо использовать языки не страдающие от неактуального наследия 70х.

есть, и причины эти даже описаны.

Описаны и технически обоснованы это разные вещи. А то вот в расте нет ub на переполнение инта, а tls библиотека почему-то получается быстрее.

например, отсутствие проверок на выход за границы массива или переполнение целого, в отдельных случаях дают 30-50% ускорения.

В каких? Ссылки на бенчмарки в студию.

технических причин заниматься подобной ерундой нет уже лет тридцать.

и, как я понимаю, тесты ПО тоже не нужны. канпелятор должен за один проход все сам проверить и отканпелять в целевую архитектуру. предварительно, видимо, телепатически извлечь из головы разраба нужные знания. если они там есть.

А то вот в расте нет ub на переполнение инта, а tls библиотека почему-то получается быстрее.

и каковы «технические причины»(тм) лучшей производительности реализации tls, и как они связаны с переполнением инта?

Ссылки на бенчмарки в студию.

ну то есть мысль о том, что любые дополнительные рантайм проверки это дополнительные затраты, и связанная с этим потеря производительности, не тривиальна? вопросов больше не имею.

и, как я понимаю, тесты ПО тоже не нужны. канпелятор должен за один проход все сам проверить и отканпелять в целевую архитектуру. предварительно, видимо, телепатически извлечь из головы разраба нужные знания. если они там есть.

Тесты ПО нужны, UB в компиляторе не нужно. Причем тут телепатия? %)

и каковы «технические причины»(тм) лучшей производительности реализации tls, и как они связаны с переполнением инта?

Нет, вопрос в другом – каким образом определенное переполнение int’а тормозит реальные программы? А то вот в Linux ‘-fwrapv’ включен по умолчанию и почему-то никто не страдает.

ну то есть мысль о том, что любые дополнительные рантайм проверки это дополнительные затраты, и связанная с этим потеря производительности, не тривиальна?

Тривиальна. Вопрос, как всегда, в цене. Если реальные программы тормозят на 1% больше, то это допустимая цена, которую мы платим за отсутствие глупых багов.

Вопрос, как всегда, в цене.

exactly. поэтому там где нам плевать на цену дополнительных гарантий целесообразно брать тот же питон\жабу\жабоскрипт\whatever и не заниматься ерундой.

Нет, вопрос в другом

вопрос как раз таки в том, за счет чего получен лучший результат. если он получен за счет предоставления большего числа гарантий - это одно. если за счет лучших архитектурных решений - это никоим образом не пересекается с вопросом о том «какой ЯП самый япистый в мире» и все печеньки уходят архитектору, а штрафные баллы за передергивание и натягивание совы на глобус начисляются адептам.

Тесты ПО нужны, UB в компиляторе не нужно

а почему тесты нужны, если компилятор дает все интересующие нас гарантии? потому что из низкоуровневых конструкций ЯП мы создаем высокоуровневые конструкции, заточенные на специфику задачи. другими словами, конструируем некий DSL, спецификация которого содержит присущие ему граничные условия, defined и undefined behavior. и никто пока еще не родил методологию программирования, которая избавляла бы от необходимости проверки граничных условий и поведения. другое дело, что наличие твердых гарантий на уровне ЯП, механизмов типа GC и прочая и прочая, снижает издержки, уменьшает time to market, etc. но вот насчет того, что кто-то-там отлил таки серебряную пулю есть обоснованные сомнения.

exactly. поэтому там где нам плевать на цену дополнительных гарантий целесообразно брать тот же питон\жабу\жабоскрипт\whatever и не заниматься ерундой.

Питон относительно C тормозит так, что мама не горюй. А Rust – нет.

вопрос как раз таки в том, за счет чего получен лучший результат. если он получен за счет предоставления большего числа гарантий - это одно. если за счет лучших архитектурных решений - это никоим образом не пересекается с вопросом о том «какой ЯП самый япистый в мире» и все печеньки уходят архитектору, а штрафные баллы за передергивание и натягивание совы на глобус начисляются адептам.

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

а почему тесты нужны, если компилятор дает все интересующие нас гарантии?

Логику работы программы компилятор за тебя не проверит. Interoperability с библиотеками и другим софтом тоже не проверит. Перформанс не проверит.

потому что из низкоуровневых конструкций ЯП мы создаем высокоуровневые конструкции, заточенные на специфику задачи. другими словами, конструируем некий DSL, спецификация которого содержит присущие ему граничные условия, defined и undefined behavior. и никто пока еще не родил методологию программирования, которая избавляла бы от необходимости проверки граничных условий и поведения. другое дело, что наличие твердых гарантий на уровне ЯП, механизмов типа GC и прочая и прочая, снижает издержки, уменьшает time to market, etc. но вот насчет того, что кто-то-там отлил таки серебряную пулю есть обоснованные сомнения.

Причем тут серебряная пуля? Речь о том, что UB в C не является технически обоснованным решением (e.g. без этого просто невозможно писать быстрый код), а является наследием (что показывает Rust, где писать быстрый код без UB вполне себе можно).

UB в C не является технически обоснованным решением

С каких это пор UB в стандарте C создаётся целенаправленно? Ты точно понимаешь смысл выражения Undefined Behaviour? Это свойство реализации, даже не имеющее отношение к расширениям реализации, а не языка.

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

(e.g. без этого просто невозможно писать быстрый код)

Сам придумал или подсказал кто?

кто бы сомневался

Питон относительно C тормозит так, что мама не горюй. А Rust – нет.

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

К сожалению консервативность победила.

почему к сожалению? к каждой новации нужно относится осторожно. принцип один — не навреди. любая инновация — это чей-то геморрой (не того, кто её устраивает) и тонны бабла выкинутого на ветер.

С каких это пор UB в стандарте C создаётся целенаправленно? Ты точно понимаешь смысл выражения Undefined Behaviour? Это свойство реализации, даже не имеющее отношение к расширениям реализации, а не языка.

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

Сам придумал или подсказал кто?

Ну посмотри переписку, что ли. Тут товарищ утверждает, что если проверять границы буферов, то аж 50% потерять можно :D

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

implementation defined и undefined это разные вещи.

Тут товарищ утверждает, что если проверять границы буферов, то аж 50% потерять можно

да можно и больше потерять на специально заточенной синтетике.

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

Это свойство стандарта, которое оставляет реализацию определенных моментов на усмотрение компилятора

Из этого не следует, что это нужно стремиться использовать и что это заложено целенаправленно, с целью использовать. Все ситуации сложно предусмотреть.

Тут товарищ утверждает, что если проверять границы

Это не имеет отношение к undefined behaviour. Совсем.

Про 50% не знаю, но в fpc есть флаг отключающий такую проверку и в зависимости от задачи прирост достаточно заметный.

В туалет поезда кидать лом не положено. Но если кинуть, то результат может быть самым разным. Долой такие поезда, это пережиток прошлого?

В современных поездах т.н. биотуалеты.

Интересно, где нибудь остались поезда в которых говно на пути выбрасывают?

Сквозного отверстия нет, а туалет есть. И кинуть в него лом по прежнему можно.

И результат опять же будет зависеть от конкретной модели туалета

Добавят новые API доступные только на фуксии и все.

implementation defined и undefined это разные вещи.

В данном случае undefined это «случится может что угодно». В том числе «компилятор обработает это нормально и все будет хорошо». Как и делает gcc с -fwrapv для переполнения интов, например.

да можно и больше потерять на специально заточенной синтетике.

Ну задроты будут завывать, что тормозит, хотя по факту нет. Нам-то что?

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

Назови уже хоть какую-нибудь.

Про 50% не знаю, но в fpc есть флаг отключающий такую проверку и в зависимости от задачи прирост достаточно заметный.

Примерно 80% уязвимостей в C это переполнение буфера с последующими непотребствами. Яхз, чувак, но по-моему проигрыш даже в 15% стоит того, чтобы закрыть самый большой класс уязвимостей в современном IT :D

каким образом определенное переполнение int

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

И результат опять же будет зависеть от конкретной модели туалета

Потому что туалеты делают разные компании. Если компилятор один, то UB просто нет смысла вводить, потому что любое поведение компилятора по факту DB :D

А компиляторов С много, и архитектур под которые они компилят код, тоже много.

А компиляторов С много, и архитектур под которые они компилят код, тоже много.

Вот именно. Зачем компиляторов C много? :D Это как бы основная проблема.

Примерно 80% уязвимостей в C это переполнение буфера с последующими непотребствами.

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

по-моему проигрыш даже в 15% стоит того

Действительно, какая разница расчёт длится 12 или 10 месяцев.

Зачем компиляторов C много

Это бизнес, детка.

Ах да, нужен же один компилятор подо всё архитектуры. Какие там архитектуры у rust поддерживаются, напомни?

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

Ну лол же просто. То есть тебе дают компилятор, который не требует Coverity за космическое бабло, а ты такой: ДЕДЫ СТРАДАЛИ ТЫ КУДА ПОЛЕЗ ВПЕРЕД БАТЬКИ ТЕСТЫ ПИШИ?

Действительно, какая разница расчёт длится 12 или 10 месяцев.

Лол. То есть закрыть большую часть дыр на планете ценой покупки проца подороже это типа не путь джедая, да? :D

Во первых, есть огромное количество аппаратных архитектур, всяких микроконтроллеров, dsp процессоров, итд. И не все их производители хотят зависеть от авторов ‘одного единственного’ компилятора си.

Далее, вот с ‘одним единым’ питоном мне на винду пришлось тащить msys, чтобы его запустить. Это бред, тащить эмулятор одной ос на другую, чтобы запустить компилятор

ПОЛЕЗ ВПЕРЕД БАТЬКИ ТЕСТЫ ПИШИ?

Ок, тесты не нужны. Компилятор лучше знает, что должно получиться в результате реализации.

То есть закрыть большую часть дыр на планете ценой покупки проца подороже это типа не путь джедая, да? :D

Какую ещё большую часть дыр? Что ты несёшь? Ну купи пару сотен процов подороже.

Ну и как, закрыл дыры? Как успехи?

А если бы и был один единый компилятор, на разных архитектурах он вполне может давать разное поведение при переполнении int, например

Про 50% не знаю, но в fpc есть флаг отключающий такую проверку и в зависимости от задачи прирост достаточно заметный.

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

Кстати, на каком процессоре прирост?

Действительно, какая разница расчёт длится 12 или 10 месяцев.

Такие рассчеты достаточно редкие. 99.999999..99% рассчетов достают юзер-профиль из базы данных.

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

Ну для таких вещей можно и питон. А си это язык для тех, кому нужна производительность

Но вот что именно сделает процессор при переполнении регистра, это зависит от процессора

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

В Rust можно сделать wrapping_add, а можно сделать checked_add, в зависимости от того, волнует тебя этот бит или нет. С checked_add все понятно, или переполнения не было или ошибка и уже ее обрабатываешь. С wrapping_add в принципе понятна формула оборота, она записана в языке и будет обеспечена даже на каком-то странном процессоре, хотя скороее всего ничего особого делать не прийдется.

Есть еще overflowing_add который просто выдает wrapping_add и бит в bool.

https://doc.rust-lang.org/std/primitive.u32.html#method.wrapping_add

Короче вот пример как можно сделать все нормально. И по коду будет понятны намерения программиста

Люди иногда любят производительность бесплатно.

«Хотите производительность и вам за это особо платить не нужно? Да, конечно, почему бы и нет».

Потому не нужно метаться между крайностями. С - крайность. Python - тоже. Ниши есть - но они все уже и уже с каждым годом

Примерно 80% уязвимостей в C это переполнение буфера

Так то защиты уже есть все, и проверки тоже, в С, для этого не нужен Rust.

Компилируешь с -fsanitize=bounds и всё, все индексы у массивов проверяются. Компилируешь с -fstack-protector и во все функции вводятся проверки, что стек не переполнится.

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

Но видимо это не нужно ни сишникам, ни бизнесу…

Кстати, напомни, в расте можно всю память под структуры данных выделить статически? Чтобы избежать динамического выделения памяти.

я ж сказал, что не знаю, насчёт 50% - это не моя цифра. intel core i3 как минимум же. Хз кто такой царь и почему ему нужно верить.

Такие рассчеты достаточно редкие. 99.999999..99% рассчетов достают юзер-профиль из базы данных.

Вот пусть они свои дыры и закрывают.

Компилируешь с -fsanitize=bounds и всё, все индексы у массивов проверяются.

Для какого кода? Попробовал, создаю массив динамически через malloc в С, через vector в С++ на три элемента. Пишу в 10й. Все молча компилируется, даже работает.

Я как-то не так понял? Я еще добавил -O2. Это мешает? Пробовал и GCC и clang.

Да, если я прямо пишу int a[3], то да, оно не дает статически записать в 10й, но это унылая проверка.

Кстати, чем Modula3

С твоей точки зрения плох для разработки ОС и системного программирования?

Во первых, есть огромное количество аппаратных архитектур, всяких микроконтроллеров, dsp процессоров, итд. И не все их производители хотят зависеть от авторов ‘одного единственного’ компилятора си.

Эм… Ну добавьте свое поделие в LLVM да будет счастье. Парни из Эльбруса так и делают.