> Конкретно в этом случае дырявый явно не язык программирования.

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

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

Увы, пока компьютер не в состоянии понимать человека. Так что приходится создавать языки со всё более и более продвинутыми абстракциями.

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

Чем тебе Rust не подходит в этой роли? Инкапсуляция - есть. Вместо наследования - принцип композиции. Вместо полиморфизма - параметрический полиморфизм. Обобщённое программирование есть. Работа с памятью безопасна по умолчанию (но если нужно, можно повыпендриваться, используя unsafe (сразу замечу, без этого в некоторых случаях никак)). Только не говори, пожалуйста, про уродливый синтаксис. Обычно так говорят люди, которые не знают языка от слова "совсем". Он вполне себе обычный: не хуже, не лучше других языков, да хоть тех же Плюсов. Да, есть необычные конструкции, но чтобы их понимать, надо просто разбираться в языке.

Структуры в Rust - это и есть своего рода аналог объектов из мира ООП.

Кстати, а что такое структуры в Плюсах? ;)

> Или, ну не знаю, как-то стимулировать, чтобы человеки выучил основы работы с памятью.

Человеки не глупые, выучить могут, и учат. Человеки НЕВНИМАТЕЛЬНЫЕ, они не могут гарантировать 100-процентную концентрацию внимания во время работы над кодом. Поэтому без помощи со стороны компилятора (линтера, анализатора, санитайзера и прочих приблуд) могут ошибаться и ошибаются.
Урри тут уже предлагал использовать CI, QA. На мой вопрос, почему в одной из самых популярных Сишных библиотек дырень висела 15 лет, он попросту слился. А правильный ответ всё тот же - утеря концентрации внимания. Ни один человек от этого не застрахован, каким бы усидчивым и внимательным он ни был.
Если ЯП не гарантирует корректную работу с памятью, такие проверки приходится проводить дополнительными средствами, которые, в свою очередь, тоже несовершенны. Кроме того, это в целом удорожает процесс программирования.

> Отсутствие базовых конструкций для проектирования ОМ не отменяет того, что базовые абстракции
> мешков с мясом включают объекты, верхний уровень абстракции на 98% состоит
> из них (не у всех в явном виде). От того, что
> при реализации код можно нормализовать убрав из него явные ОО конструкции
> не говорит, что ОМ нет -- просто код становится труднее читать
> и при дальнейшей модификации появляются неявные ошибки.

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