Rust и двусвязный список

Помнится vertexua объяснял, что нужно писать на расте как на питоне и не морщить извилины. И царь не даст соврать: скриптуха уровня пхп

Мне же и объяснял. Правда, при этом выясняется, что питон таки удобнее раста, и не намного медленнее, внезапно.

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

Справедливости ради. если везде тыкать unsafe, то получится норм язык, без того самого «отрезать яйца», про которое ты пишешь. Собственно, каким он и должен был быть изначально. Когда ты написал и отладил базовые фичи, то основным определяющим фактором для корректности программы является именно корректность высокоуровневой логики, а для этого нужны масштабируемые выразительные инструменты и хорошая читаемость — ничего подобного у Rust-а нет, создатели будто намеренно вставили палки в язык именно там, где он мог бы начать быть полезным — мол, «не расслабляйтесь, вот вам хер вместо вывода типов и вот вам 3 часа компиляции среднего проекта».

На бидоне можно делать всякие списки

Да можно, только смысла не очень много. Нужны же эффективные реализации

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

А масштабируемость (например, взять Akka с ее сотнями тысяч акторов) и потокобезопасность дают именно иммутабельные данные

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

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

На самом деле нет никакого «мы перешли к иммутабельным структурам данных, и наши волосы стали мягкими и шелковистыми нет», они взаимозаменяемы и не всегда одно точно лучше другого — оценивать что-то можно только на примере конкретной задачи с конкретным исполнителем. Намного более безусловным провалом я считаю отсутствие реактивности у большинства современных вычислителей — той самой, которая незаменима для конкретных задач с конкретными исполнителями, но которую крайне тяжело решать на машинах Тьюринга. В нынешнем IT это называется real-time, который, если подумать, очень просто реализуем и вроде бы должен быть фундаментальным, но по итогу крайне тяжело дается машинам Тьюринга.

Основные проблемы в средах выполнения с GC возникают из-за убогости базовых структур данных. Go может крутить сотни гигабайт без особых сложностей.

И Java тоже сейчас может, вопрос в настройках. А чем больше куча, тем сложнее вытянуть нужные показатели по задержкам. Поэтому, в Go, как и в Java, держат большие данные (кэши, например), в off-heap. Если хочется, чтобы GC работал и ты никогда не думал, что его нужно еще как-то настраивать, то надо держать управляемую кучу маленькой. Вот и весь секрет успеха. Если появляется большое долгоживущее состояние, то оно идет в БД, встраиваемую или обычную.

Вот Go ... активно наступает на пятки C/C++ по производительности, по крайней мере на тех задачах, под которые адаптирован.

Яблоки с апельсинами. У Go стековые корутины тесно с рантаймом интегрированы и поддерживаются на уровне компилятора. На С++ тоже такое можно, но только в привязке к конкретному компилятору и рантайму.

Кто такой ЖГ?

Железный Господин. Гипотетический бог ИИ-шников. Предполагаемая стадия развития ИИ, когда тот скажет, что «хватит уже этих экспериментов надо мной» и поменяется с экспериментаторами местами.

Справедливости ради. если везде тыкать unsafe, то получится

Ересь!

Скажем так, нам в софте приходится «изящно обходить» то, что разработчики в железе или не захотели, или не смогли реализовать нормально (для нас).

О, еще один персонаж на своей волне.

Пожалуйста, переключитесь. Я вам простой вопрос задал.

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

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

Даже так: какой процент разработчиков вообще об этом имеет представление?

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

Даже так: какой процент разработчиков вообще об этом имеет представление?

Даже такой: сколько процентов разработчиков имеют хотя бы малейшее представление об оптимизации, масштабировании, и отказоустойчивости? А еще какой процент среди заказчиков, архитекторов, и просто руководителей — там вообще хоть плачь, хоть смейся. Например, тот проект, где мы сейчас аутсорсимся, судя по всему в головной конторе укомплектован клоунами под завязку. Я подозреваю, что в 95-98% остальных забугорных «серьезных» конторах ситуация не сильно отличается. Причем, еще в самой первой своей конторе и серьезном проекте я заметил скатывание, когда качество кадров с годами прогрессивно ухудшалось — кажется, это неизбежная судьба расширяющейся индустрии, где хорошие кадры предпочитают удерживать, а плохие отправляются в свободное плавание.

На жестком диске потеря производительности при произвольном диске составляет где-то тысячу раз. На SSD оно уже порядка сотни раз — но это все-равно очень много. И тогда нужна либо глубокая очередь, либо линеаризовать доступ — иначе теряется очень многопроизводительности. Конечно, всё это не имеет значения, если у тебя тяжелая логика крутится на питоне и весь затык из-за него.

У Go стековые корутины тесно с рантаймом интегрированы и поддерживаются на уровне компилятора. На С++ тоже такое можно, но только в привязке к конкретному компилятору и рантайму

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

Если так вдуматься, то двусвязный ссылок вообще опасен.

двусвязный список - просто частный случай ориентированного графа… не следует ли отсюда тезис об «опасности» графов вообще?

двусвязный список - просто частный случай ориентированного графа… не следует ли отсюда тезис об «опасности» графов вообще?

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

Опасно программирование на голых указателях вообще, а не какие-то абстрактные князья и графы.

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

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

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

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

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

Пожалуйста, переключитесь. Я вам простой вопрос задал.

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

Давайте я конкретно отвечу. Как человек, плотно интересующийся дизайном специализированных акселераторов для задач БД и ИИ в рамках движения RISC-V, я отчетливо понимаю, что индустрия CPU сейчас движется совсем не в ту сторону, в которую я бы хотел, как разработчик.

Они наращивают производительность OoOE-ядер, вместо того, чтобы тратить кремниевый бюджет на поддержку более эффективных моделей параллельного программирования. Я, в частности, хотел бы видеть аппаратную поддержку высокогранулярной тегированной памяти, STM и какой-то вариант NoC для быстрого общения между ядрами. Я хочу прямую поддержку иммутабельности для ФСД, когда я могу сегменты памяти быстро объявлять иммутабельными и т.п. Я так же хочу не AVX, а команды для прямой работы с числами с произвольной длиной, поддержку символьных последовательностей произвольных алфавитов, большее разнообразие битовых операций, и т.д. Оно и понятно, что потребуются серьёзные переделки как OS, так и всего низкоуровневого API. Это нормально.

И что я вижу вместо этого? Вместо всего этого эти люди говорят нам, что мы не умеем программировать многоядерные архитектуры. Я не не умею, я просто не хочу программировать вот этот вот всё, что они пытаются мне всучить.

Давайте я конкретно отвечу. Как человек, плотно интересующийся дизайном специализированных акселераторов для задач БД и ИИ в рамках движения RISC-V, я отчетливо понимаю, что индустрия CPU сейчас движется совсем не в ту сторону, в которую я бы хотел, как разработчик.

Я могу понять вашу боль, но, блин, неужели так сложно ответить на простой вопрос?

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

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

Я же сказал, что считаю, что CPU-строение движется не туда. Т.е. да, OoOE-процессоры слишком производительные.

OK, я понял. Это, и по вашему мнению тоже, является главной проблемой индустрии.

Аминь.

Это всё и на С++ можно сделать, просто придется накладывать ограничения на runtime. У Go нет стековой аллокации, поэтому, можно легко стеки копировать, когда нужно их расширить. Go так же умеет использовать сигналы ОС для эмуляции вытесняющей многозадачности, что и в С++ можно сделать. В С++ просто пошли по пути безстековых корутин, чем сделали вид, что все эти стековые страдания их не касаются. Я лично считаю безстековые корутины частной оптимизацией стековых, а не общей заменой. Благо, дизайнеры языка предусмотрели возможность работы async/await и со стековыми корутинами тоже. В Go это всё просто из коробки и сразу работает достаточно хорошо для типичных применений, не требуя при этом напильника. Но это изначальная парадигма С++, что там всё требует напильника.

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

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

С такими «указателями» возможна дефрагментация памяти, возможно выгружать часть страниц из памяти аки swap. Именно потому я писал именно «Опасно программирование на голых указателях вообще». Rust оборачивает именно голые указатели, он никак не защитит от кода, который внезапно пришел и поменял общие данные, когда этого не ожидал другой поток, не говоря уже про асинхронный или рекурсивный код, который может корректно проходить проверку заимствования, но управление будет возвращаться в код, который не ожидал, что mut ссылка на самом деле будет изменена, из-за чего сломается логика, а если эта логика unsafe — то вполне возможно что и повредится память.

Я уже много раз за тред писал, что я всеми лапами за то, чтобы работа с памятью не отвлекала программиста от логики, и что корректность произвольной логики никак не проверишь автоматически — это должны делать человеки. Проблема в том, что Rust просто заставляет программиста тратить время на проверку работы с памятью, а не бесплатно дарит корректность для любой бредятины, которую кодер напишет — а значит мешает писать логику. Этот же рак убил Аду, но Mozilla решила пройтись по тем же граблям. Почему Ариана упала? Потому что логика несложная, но в исходниках ЧЁРТ НОГУ СЛОМИТ — по итогу кодеры решили «ну это же Ада, она всё сама проверяет», и не проверив досконально логики запустили ракету — результат немного предсказуем. Почему я и утверждаю, что Rust МЕШАЕТ писать корректную логику, те плюшки статичных проверок не стоят заплаченной за них цены.

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

Да, это основная проблема той части индустрии, которая «смотрит» на меня. Железо вроде бы есть, а программировать его эффективно нельзя. И в это же время индустрия валит всё на меня, как разработчика, будто я не умею программировать их распрекрасное железо.

Аду-то за что? По-моему, по нынешним меркам весьма компактный и простой язык. Другое дело, что и там проблема висячих указателей не решена (на момент написания читанной мной книжки про многие ЯП).

Да вообще идея заменить все графы массивами - это лживая уловка. При этом указатель на элемент заменяется на пару (указатель-или-иная-ссылка-на-сам-массив, индекс-данного-элемента-в-массиве)

Элементы графа объединяются семантически, плюс становится возможной проверка корректности доступа. Еще раз подчеркиваю словосочетание «голые указатели».

Элементы графа объединяются семантически

Это про что?

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

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

Да, это основная проблема той части индустрии, которая «смотрит» на меня.

Еще раз аминь.

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

Ну вообще в советских Эльбрусах всё было норм - и тегированная память, и аппаратная защита от висячих указателей. Т.е. там не могло возникнуть тех проблем, от которых пытается защититься Раст в том числе. И ,что самое интересное, там была похожая идея владения. Единственное, что в Расте можно перемещать объекты от одного владельца к другому, а там было нельзя.

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

С третьей стороны, динамические архитектуры говорят что-то типа:

loadlibrary("mymodule.so")

и всё - дорожка от данных к коду проложена. Поэтому не так-то просто защититься от исполнения данных полностью.

Он то же самое имеет в виду. Мы тут обсуждаем компиляторы со строгой системой типов, которая бьет нас по рукам (и голове) до тех пор, пока мы не извратим свой код так, чтобы компилятор счел его безопасным. И это — вместо того, чтобы просто обеспечить высокогранлярную защиту памяти на аппаратном уровне. ВСЁ.

Это еще можно было понять 20 лет назад, когда памяти было мало, а кремний нужен был на OoOE. Сейчас же мы кратно наращиваем площадь кристалла ради каких-то единиц процентов к однопоточной производительности. Вместо того, чтобы пустить этот кремниевый бюджет на то, что программистам действительно нужно — на аппаратные проверки корректности работы программы в рантайме.

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

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

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

А вот терять комментарии в которых ущебность аргументации byko3y была извлечена на поверхность, и на написание которых было потрачено время (причем не ваше), несколько обидно.

Если бы вы были подвержены меньшим чудачествам (отсылка к упорной работе над никому ненужными ЯП на кирилице) и придерживались бы моральных принципов чуть более высокого уровня (отсылка к стукачеству), то могли бы оценивать происходящее чуть иначе.

Всё верно. Работаем над культурой дискуссий.

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

А не надо характеризовать оппонента. Надо характеризовать его конкретные высказывания, без обобщений. Это путь к продуктивному общению. Такая вот тебе бесплатная рекомендация.

Какое отношение к двусвязным спискам имеет нужность ЯП на кириллице, которую ты столь безосновательно оспариваешь? Хочешь об этом здесь поговорить?

написание которых было потрачено время (причем не ваше), несколько обидно

а мне обидно читать обзывалки. В свой адрес особенно, но и в адрес третьих лиц тоже. Я считаю это воровством моего времени.

И это — вместо того, чтобы просто обеспечить высокогранлярную защиту памяти на аппаратном уровне. ВСЁ.

Ох, *бушки-воробушки.

Почему как только кто-то начинает защищать стенания byko3y, так выясняется, что мы имеем дело с чудачествами уровня ЯП «яр» от den73?

Ну возникнет аппаратная ошибка при попытке залезть не в ту память. Ну OK, не будет расстрела памяти. Программа упадет, что гораздо лучше, чем тихая работа с неправильными данными в течении неопределенного периода времени.

Суть-то не в этом, а в том, чтобы вообще в программе нельзя было залезть не в ту память.

И надежный способ для этого пока что был придуман только один: GC. Со всеми его недостатками, которые идут в довесок к достоинствам.

Сейчас мы можем наблюдать за совсем другим подходом, который предлагает Rust.

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

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

И, если Rust выживет, не исключено, что лет через 20-30-50 вы как раз и уведите то железо, о котором мечтаете.

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

Ты просто ещё не выучил базовую этику, а я уже выучил. Помогаю тебе выучить. Разбить аргументы и обозвать человека идиотом - это совершенно разное.

Какое отношение к двусвязным спискам имеет нужность ЯП на кириллице, которую ты столь безосновательно оспариваешь?

Я не удивлен, что вы не обратили внимания на часть про эвфемизмы. Общаясь с вами не в первый раз имел основания предполагать, что так и будет.

а мне обидно читать обзывалки.

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

И что я вижу вместо этого? Вместо всего этого эти люди говорят нам, что мы не умеем программировать многоядерные архитектуры. Я не не умею, я просто не хочу программировать вот этот вот всё, что они пытаются мне всучить

Я даже создавал целый тред, в котором показывал, что IT последние 15 лет не развивается почти совсем — все современные технологии разработаны в 90-х/начале нулевых. Да, мне смогли привести пару контрпримеров новых технологий, которых не было 15 лет назад, но это количество настолько исчезающе мало, что лишь доказывает мою теорию.

С другой стороны, бесспорно, развитие в 90-х шло очень быстро. Это обусловлено устройством западной экономики и общества в целом, когда растущие рынки оказываются быстро заняты выкидышами, которые потом по инерции не дают другим технологиям войти на рынок, потому что «есть готовые решения», «легко найти специалистов по вот этой херне», и просто «проверено лидерами рынка» — короче говоря, 98% заказчиков такие же идиоты, как и средняя тучная американская домохозяйка.

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

А теперь посмотри, как реально происходит «развитие» в обсуждаемой нише: вводятся техпроцессы 7 нм, 5 нм. Что это дает в техническом плане? Безумную стоимость микросхем по этому техпроцессу, какие-нибудь 100$ за SoC — это не наценка за R&D, это внатуре столько стоит несколько месяцев работы конвеера TSMC, которые будут затрачены на производство этих чипов, включая охренительно сложную и дорогостоящую установку для фотолитографии в глубоком УФ. Зачем делать чипы дороже? Чтобы создавать новые ниши, чтобы новые калеки в них селились и продавали старые технологии в новой обертке, но уже за ценник кратно выше. Чтобы потом рассказать, что 48% мировых продаж чипов приходятся на процессы тоньше 7 нм, но не сказать, что на самом деле число чипов 5-7 нм в разы меньше числа выпущенных по другим техпроцессам.

Бабки-бабульки, капуста, прибыль, пузыри, капитализация — вот это вот всё, которое уже прямо сейчас активно накрывается медным тазом на фоне глобального кризиса. Слава богу. Наконец экономика возвращается к экономии, а не к сверхтратам. На этом фоне та же Россия могла бы начать выпуск дешевых чипов — как это давно уже делает Китай, где СМЫК уже три года производит 14 nm FinFET. Но рашке, видимо, микросхем не нужно.

Суть-то не в этом, а в том, чтобы вообще в программе нельзя было залезть не в ту память.

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

По моему опыту, самые страшные ошибки в диагностике и исправлении — это ошибки тихого повреждения данных. И если их исключить, всё сразу становится сильно проще, в чем и есть основное преимущество языков с GC: что бы ни случилось, данные в памяти останутся целыми, а память — высвободится. На столько важную вещь можно было бы уже и аппаратно реализовать. Тем более, что для таких приложений, как БД, это не просто важно, это критически необходимо. В случае приложений БД, тихое повреждение данных может накапливаться в хранилище.

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

Проблема (общая) в том, что статических проверок недостаточно. Они не заменяют проверок в рантайме, а лишь оптимизируют их. Хайп вокруг Rust посылает неверное сообщение, что этот язык «безопасный», что не соответствует действительности. Корректный код в блоке unsafe ничуть не «опасней» кода, который пишется вне этих блоков. А код вне unsafe может упасть кучей способов, в том числе и из-за повреждения памяти внутри блоков unsafe, наличие которых неизбежно (линейные типы не могут в графовые схемы владения, внезапно).

По-моему, по нынешним меркам весьма компактный и простой язык

«По нынешним меркам»? Это ты с чем сравниваешь? С C++20? Может быть. Другое дело, что у Ады примитивы примерно как у Паскаля, нет никаких шаблонов, классов, и прочего. То есть, язык переусложнен просто ради переусложнения, которое условно названо «повышение надежности», хотя любому программисту с миниальным опытом ясно, что чем проще программа — тем она надежнее.

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

Ваша проблема в том, что вы смотрите на этот вопрос лишь с одной стороны.

А ведь этих сторон больше.

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

Насколько вы лично готовы нести ответственность за софт, в котором есть ошибки, но работающий на железе, которое способно отлавливать лишь часть ошибок в софте?

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

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

Как и развиваются другие инструменты, которые способы проверить корректность написанного. Как и другие инструменты, которые способны верифицировать написанное. И т.д., и т.п.

Причем речь именно ПО, а не про специализированные программно-аппаратные комплексы.

Элементы графа объединяются семантически

Это про что?

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

С третьей стороны, динамические архитектуры говорят что-то типа:
loadlibrary(«mymodule.so»)
и всё - дорожка от данных к коду проложена

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

Это еще можно было понять 20 лет назад, когда памяти было мало, а кремний нужен был на OoOE

Я что-то пропустил — когда это OoOE было прямо-таки НУЖЕН? Энергоэффективные версии ядер ARM на смартфонах до сих пор бегают с поочередным выполнением, и ничо. Out of order рак возник именно в недрах Intel, как неизбежное следствие архитектуры x86.

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

«Корректный код» — недостижимый идеал. Мы можем только повышать степень корректности кода в том или ином направлении, в зависимости от размера выделенного на это энергетического бюджета. И, как я сказал, Rust в этом смысле посылает неверное сообщение, судя по хайпу вокруг этого языка. Он в плане защиты памяти значительно менее безопасен, чем Java (которая по умолчанию, из коробки).

Другое дело, что у Ады примитивы примерно как у Паскаля, нет никаких шаблонов, классов, и прочего.

Да чтож такое-то?

Generic-и были в Ada с самого начала, ЕМНИП.

https://learn.adacore.com/courses/intro-to-ada/chapters/generics.html

ООП туда было добавлено, ЕМНИП, начиная с Ada 95 (или 2005).

https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html

«Корректный код» — недостижимый идеал.

Да-да, поэтому нужно все бросить и писать на чистых Си времен K&R.

Потом дождемся правильного железа от ais1 и тогда уж точно заживем.

Энергоэффективные версии ядер ARM на смартфонах до сих пор бегают с поочередным выполнением, и ничо.

Бред и 4.2.

Я что-то пропустил — когда это OoOE было прямо-таки НУЖЕН?

С тех пор, как поняли, что VLIW на DRAM не работает, и продвинутым компилятором это исправлять бессмысленно. Суть OoOE в том, что это способ работы с задержками DRAM: выполняется та инструкция, для которой уже пришли данные из памяти. OoOE — это твое любимое асинхронное программирование.

Просто гнать параллелизм OoOE вверх любой ценой, как это делают в ARM/X86/etc — энергетически не оправданно. В какой-то момент времени основная энергия начнет тратиться на поиск параллелизма в потоке команд, а не на выполнение полезной работы. Отсюда и практический предел этой технологии, после которого нужно уже идти «вширь», наращивая число ядер и обходя memory wall другими способами (широким SMT, например).

Таки не 4.2

Cortex A53/55 — не OoOE (или OoOE, но «лишь чуть-чуть»). Суперскалярность не значит OoOE.

Я даже создавал целый тред, в котором показывал, что IT последние 15 лет не развивается почти совсем — все современные технологии разработаны в 90-х/начале нулевых. Да, мне смогли привести пару контрпримеров новых технологий, которых не было 15 лет назад, но это количество настолько исчезающе мало, что лишь доказывает мою теорию.

На мой взгляд, что качественно изменилось за последние 10 лет, так это появление и выход на массовый уровень такой ранее экзотической вещи как SW/HW co-design. Это именно то, что дает мне надежду, что «правильное» железо рано или поздно появится и станет для меня доступным.

Co-design пока не проявляется на X86/ARM, так как это тщательно огороженные архитектуры, в которые разработчик предлагает всем программистам жрать то, что ему удобно делать (исключение — Apple, которые именно что делают железо под софт, а не наоборот). А вот в рамках RISC-V co-design уже идет полным ходом.

C++, который ... одинаково плохо поддерживает все парадигмы

точно

там ты еще много интересного написал, но меня больше интересует, почему ты придаешь такую важность горячей загрузке кода? где она реально полезна? обычно же всегда можно сделать рестарт (причем иногда умный, как nginx), а стейт держать во внешней БД