Мне кажется, проблема в том, что мы не совсем об одном и том же разговариваем. Вы, похоже, говорите в основном про SPARK, который хоть и статически верифицируем, но в силу специфики имеет ограниченный круг применения. Я в основном говорю про Ada в общем. Так о чём будем продолжать разговор? Если про SPARK — предлагаю закончить, т.к. там благодаря стат. верификации большинства рантайм проверок и так не будет. И проблем с "не закрыли файл" тоже. Просто не во всех приложениях можно на этапе проектирования просчитать, сколько оно сожрёт ресурсов. Я бы сказал, в очень небольшом числе приложений.
Т.е. вы хотите сказать, что в языке с упором на безопасность и корректность до сих пор нет инструментов из коробки для управления ресурсами без сборки мусора?
Окей. Ткните меня пожалуйста носом в аналог std::unique_ptr, std::shared_ptr, std::weak_ptr. Я серьёзно. Потратил часа два или три и так и не нашёл. Т.е. что делать если мне нужно в контейнер положить не само значение, а ссылку на него?
Вообще-то нет. Перечитайте. Обычные плюс и минус в дебаге при переполнении выдают ассёрт, а в релизе работают как wrapping операция. Паника будет только при делении на ноль.
К сожалению, любое решение имеет свою цену. К примеру, исключения позоляют рапортовать любую ошибку откуда угодно. Но приводят к тому, что необходимо реально ждать такой ошибки из каждой щели. Почитайте про weak/strong exception guarantee в С++. В некоторых случаях обеспечение даже слабой гарантии превращает код в лапшу.
The default hook prints a message to standard error and generates a backtrace if requested, but this behavior can be customized with the set_hook and take_hook functions.
Я честно говоря так и не понял, о какой безопасности говорят сторонники Ada. В языке с исключениями, при отключенной сборке мусора, предполагается ручное на уровне С управление ресурсами. А RAII сделан через отдельный базовый класс, что сильно срезает его полезность. Т.е. возможностей отстрелить себе аллоцированный ресурс по самый thread header больше, чем в C++.
По поводу обработки числовых переполнений. Здесь КМК столкнулись требования zero overhead и безопасности. Во-первых, в Rust сознательно отказались от исключений в пользу Result. Следовательно, бросить исключение из оператора сложения мы не можем. Иначе был бы C++ "anything can throw". К тому же, проверка каждой операции приводила бы к оверхеду. Результатом был бы жуткий срач. Далее, делать всю арифметику return Result — убить эргономику. Ещё один потенциальный срач. Для тех, кому нужна предсказуемая арифметика, у каждого целочисленного типа Rust есть набор методов checked/saturating/wrapping/overflowing. У чисел с плавающей точкой есть свой набор контроллируемых операций.
Теперь, по поводу паник. Паники предназначены для выражения ошибок "Шеф! Всё пропало!". По умолчанию паники реализованы через С++-подобный механизм исключений, но можно реализовать свой паник хендлер либо выставить panic=abort. По умолчанию поймать панику можно — std::panic::catch_unwind.
Попробую, хотя у Вас в некоторых пунктах намешано много всего
Надёжность
"Устойчивость к ошибкам человека..." Честно говоря так и не понял, какие конкретные критерии.
Юникодные строки — да. Плюс ОС-зависимые строки отдельно для желающих. Защита от перерасхода памяти — не совсем понятно. Строковые слайсы? Cow? Что именно? Дата-время — есть std::time, для более точной оценки уточните требования.
Приведение типов только явное. Контроль переполнения и потери точности — через отдельные методы на примитивных типах (overflow_add etc.).
Контроль границ — есть.
Контроль памяти — compile-time borrow checker, non-null по умолчанию. Контроль стека — приводит к панике. Защита от фрагментации — нет, т.к. нет GC (или я не понял о чём Вы).
Обработка ошибок — ADT Result с сахаром плюс panics для ошибок вроде division by zero, bad alloc etc. ADT, RAII — используется в полный рост.
Модульность — иерархическая, crate как единица сборки. Пакетный менеджер и менеджер зависимостей из коробки.
Функциональность
ООП — нет в классическом понимании. Дженерики есть. Трейты выполняют функцию и концептов, и интерфейсов.
ФП — повсюду.
Контракты — нет. Юниттесты — встроены в язык и тулчейн.
Доступ к железу — не совсем понятно что именно надо. По идее зависит от платформы. Проекты микро-ОС для микроконтроллеров есть. Для ассемблерных вставок ЕМНИП есть макрос asm! в unstable. В целом — идеология языка никак не мешает такому доступу быть.
Многопоточность — классическая с аппаратными потоками и примитивами. Трейты Send/Sync для контроля перемещения объектов между потоками и контроля доступа из множества потоков к объектам. Акторы, асинхронка — в отдельных крейтах (см. tokio, std::futures, actix etc.). Микросервисы — не совсем понятно каким боком они к языку, но есть несколько крейтов для простой сборки оных.
Сетевые функции — базовая сеть в stdlib, остальное на crates.io
ГУИ — в основном биндинги к Gtk etc.
Файловый ввод-вывод — есть.
Безопасность
Контроль времени выполнения — там где проставлены panics или возврат ошибок. В целом опирается на безопасность времени компиляции.
Очистка выделяемой/освобождаемой памяти — по умолчанию нет, т.к. принцип zero overhead. Можно кастомизировать глобальный аллокатор либо сделать свои арены.
В целом Rust удовлетворяет бОльшей части Ваших требований из коробки либо позволяет их реализовать сравнительно легко. К сожалению, требования недостаточно чётко поставлены, чтобы можно было однозначно ответить на них.
Пожалуйста вычитывайте свои статьи. Читать Множество Слов С Большой Буквы С Очепятками, при начисто сбитом форматировании, тяжело.
И, кстати, какие предсказания способна сделать ваша модель? Про опыт Резерфорда и вообще объяснение целой кучи квантовых явлений в рамках вашей модели уже спросили.
Вброшу свою ложечку. Судя по https://old.reddit.com/r/cpp/comments/akihlv/c_modules_might_be_deadonarrival/, эти самые констрейнты заключаются в "шоб мы могли свой код времён Кеннеди перенести в новый стандарт в 2 строчки".
Т.е. module lookup хотят сделать зависимым от содержимого файлов (а там имя модуля может задаваться в зависимости от макроссов, упс...) просто потому, что, грубо говоря, есть ОС, которая не умеет больше одного слоя директорий в своей ФС. Или ОС, которая не знает, что такое расширение. Или в байте 9 3/4 бит...
Как написали выше, пифагоровы тройки — не очень удачный пример. Вообще же вы подняли старую проблему push vs pull iteration. push-iteration, которая на коллбэках, делается проще — но гораздо хуже ведёт себя в композиции.
Да ладно вам. Винду точно так же плющит и таращит. У меня по работе ноут с UHD экраном и монитор FullHD. При отключении-подключении постоянно были проблемы с поехавшими системными (!) элементами управления. Пока я принудительно не поставил везде масштаб 100% и скейлинг через принудительно заданное разрешение.
Примеры:
Выпадающая панелька трея на внешнем мониторе распухала после его подключения, как будто была на встроенном экране
У ряда приложений менюбар и строка заголовка рандомно меняли размер шрифта и свой собственный размер.
Вишенка на торте — для приведения всего в порядок МС предлагает логаут-логин. Т.е. корректно перезапустить композитор или чего у них там они не могут.
Мне кажется, проблема в том, что мы не совсем об одном и том же разговариваем. Вы, похоже, говорите в основном про SPARK, который хоть и статически верифицируем, но в силу специфики имеет ограниченный круг применения. Я в основном говорю про Ada в общем. Так о чём будем продолжать разговор? Если про SPARK — предлагаю закончить, т.к. там благодаря стат. верификации большинства рантайм проверок и так не будет. И проблем с "не закрыли файл" тоже. Просто не во всех приложениях можно на этапе проектирования просчитать, сколько оно сожрёт ресурсов. Я бы сказал, в очень небольшом числе приложений.
Видел. Закопано хорошо. Во вводных по языку об этом ни слова, хотя КМК должно быть чем раньше, тем лучше.
Корректно удалить объект при выходе из скоупа? Например, закрыть файл? Несмотря ни на какие исключения.
Т.е. вы хотите сказать, что в языке с упором на безопасность и корректность до сих пор нет инструментов из коробки для управления ресурсами без сборки мусора?
Зато Unchecked_Deallocation это супер современно.
А вы почитайте. Про то, как надо побиться головой об стену чтобы обеспечить инварианты в условиях могущих вылететь откуда угодно исключений.
Окей. Ткните меня пожалуйста носом в аналог
std::unique_ptr,std::shared_ptr,std::weak_ptr. Я серьёзно. Потратил часа два или три и так и не нашёл. Т.е. что делать если мне нужно в контейнер положить не само значение, а ссылку на него?Вообще-то нет. Перечитайте. Обычные плюс и минус в дебаге при переполнении выдают ассёрт, а в релизе работают как wrapping операция. Паника будет только при делении на ноль.
К сожалению, любое решение имеет свою цену. К примеру, исключения позоляют рапортовать любую ошибку откуда угодно. Но приводят к тому, что необходимо реально ждать такой ошибки из каждой щели. Почитайте про weak/strong exception guarantee в С++. В некоторых случаях обеспечение даже слабой гарантии превращает код в лапшу.
https://doc.rust-lang.org/std/panic/fn.set_hook.html
https://doc.rust-lang.org/std/primitive.i32.html#method.checked_add и далее вниз по доке. Для остальных примитивов аналогичный набор.
Я честно говоря так и не понял, о какой безопасности говорят сторонники Ada. В языке с исключениями, при отключенной сборке мусора, предполагается ручное на уровне С управление ресурсами. А RAII сделан через отдельный базовый класс, что сильно срезает его полезность. Т.е. возможностей отстрелить себе аллоцированный ресурс по самый thread header больше, чем в C++.
Давайте немножко разделим.
По поводу обработки числовых переполнений. Здесь КМК столкнулись требования zero overhead и безопасности. Во-первых, в Rust сознательно отказались от исключений в пользу Result. Следовательно, бросить исключение из оператора сложения мы не можем. Иначе был бы C++ "anything can throw". К тому же, проверка каждой операции приводила бы к оверхеду. Результатом был бы жуткий срач. Далее, делать всю арифметику return Result — убить эргономику. Ещё один потенциальный срач. Для тех, кому нужна предсказуемая арифметика, у каждого целочисленного типа Rust есть набор методов checked/saturating/wrapping/overflowing. У чисел с плавающей точкой есть свой набор контроллируемых операций.
Теперь, по поводу паник. Паники предназначены для выражения ошибок "Шеф! Всё пропало!". По умолчанию паники реализованы через С++-подобный механизм исключений, но можно реализовать свой паник хендлер либо выставить panic=abort. По умолчанию поймать панику можно — std::panic::catch_unwind.
Попробую, хотя у Вас в некоторых пунктах намешано много всего
В целом Rust удовлетворяет бОльшей части Ваших требований из коробки либо позволяет их реализовать сравнительно легко. К сожалению, требования недостаточно чётко поставлены, чтобы можно было однозначно ответить на них.
Напомнило шнобелевскую премию. Сначала смеёшься, потом задумываешься.
Пожалуйста вычитывайте свои статьи. Читать Множество Слов С Большой Буквы С Очепятками, при начисто сбитом форматировании, тяжело.
И, кстати, какие предсказания способна сделать ваша модель? Про опыт Резерфорда и вообще объяснение целой кучи квантовых явлений в рамках вашей модели уже спросили.
Вброшу свою ложечку. Судя по https://old.reddit.com/r/cpp/comments/akihlv/c_modules_might_be_deadonarrival/, эти самые констрейнты заключаются в "шоб мы могли свой код времён Кеннеди перенести в новый стандарт в 2 строчки".
Т.е. module lookup хотят сделать зависимым от содержимого файлов (а там имя модуля может задаваться в зависимости от макроссов, упс...) просто потому, что, грубо говоря, есть ОС, которая не умеет больше одного слоя директорий в своей ФС. Или ОС, которая не знает, что такое расширение. Или в байте 9 3/4 бит...
Как написали выше, пифагоровы тройки — не очень удачный пример. Вообще же вы подняли старую проблему push vs pull iteration. push-iteration, которая на коллбэках, делается проще — но гораздо хуже ведёт себя в композиции.
Да ладно вам. Винду точно так же плющит и таращит. У меня по работе ноут с UHD экраном и монитор FullHD. При отключении-подключении постоянно были проблемы с поехавшими системными (!) элементами управления. Пока я принудительно не поставил везде масштаб 100% и скейлинг через принудительно заданное разрешение.
Примеры:
Вишенка на торте — для приведения всего в порядок МС предлагает логаут-логин. Т.е. корректно перезапустить композитор или чего у них там они не могут.
А как насчёт идеи срезать лишние компоненты и прекратить держать пользователей за идиотов?