Может быть, я невнимательно просмотрел, но это же про обучение?

я имел в виду скорее уже программиста не первой свежести :))

У этого же преподавателя есть курс про конструирование компиляторов и проч. В обучающем процессе он использует собственный вариант Оберона на Ocaml: https://spivey.oriel.ox.ac.uk/corner/Design_overview_for_OBC

Я видел несколько подобных проектов (в том числе на Haskell). Оберон здесь является простым императивным ЯП на котором демонстрируются возможности ФП-подхода по созданию компиляторов.

А по поводу "программиста не первой свежести" — Оберон здесь является примером того, что ниша простых низкоуровневых системных ЯП далеко не заполнена. Ее не заполнили Rust, Zig и проч.

Из недавнего ZZ: https://github.com/zetzit/zz

А это ведь немного другое. Порождение кода на Си легко делается и на Haskell или Python, просто обычно это имеет смысл делать для своих же DSL.

Вообще-то, наличие такой ниши вовсе не очевидно. Несколько Свидетелей Оберона — ещё не ниша (у них всё равно денег нет). 🤷‍♀️

Nim тоже транспайлится в C. Это не суть важно. Я впомнил это в продолжение темы про незаполненность ниши

Программисту имеющему опыт за рамками паскального семейства средств разработки (ну Дельфи, короче)  практически нечем соблазниться. Не ищите там рационального зерна, это религия. Или как хобби (у меня, например :) Основные "жертвы" оберона - это школьники или люди из других профессий (не профессионалы в программировании), которые наслушались про "16 страниц, супер язык". Есть, как всегда, единичные исключения осмысленного применения на практике, но надо искать...

а ведь весь день оберон обсуждаем же

SML - это 40 страниц расслабленного текста, кстати.

Да, пример вполне в тему. Просто это, скорее, в духе совершенно иного направления. Мы не связываемся с системными языками вообще. Брезгуем писать на них напрямую. Мы берем удобные и привычные нам  высокоуровневые инструменты и занимаемся DSL-кодогенерацией в Си.

Я, например, подобным образом генерировал Си-код симуляторов для спецпроцессоров. У меня, к примеру, порождался код с оперированием отдельными битовыми полями широкой (100+ бит) команды. Менялся формат команды — код перестраивался. А на Си это привело бы к совершенно непродуктивной и чреватой ошибками возне.

А zig чем плох? Простой, в отличие от Rust.

Zig из той же весовой категории, что и Си, а не Rust

Это как раз хорошо, что по простоте он ближе к Си. Просто он не выглядит пока зрелым решением. Мне так показалось.

Я к тому, что "ниша простых низкоуровневых системных ЯП далеко не заполнена." Понятно, что Rust в неё не лезет. Oberon лезет, Zig тоже.

Да:

"SIMD
TODO Zig's SIMD abilities are just beginning to be fleshed out."

Собственно, чтобы быть полезнее С, нужно быть серьёзно лучше С в любом применении.

Rust, понятное дело, не из этой категории. У меня во всех проектах для микроконтроллеров и ПЛИС память выделяется статически на этапе компиляции. Ну и зачем мне тогда терпеть borrow checker? :)