OberonCore

Для Оберон-ов есть предложение на базе метаданных:
Zero-Overhead Exception Handling Using Metaprogramming

Однако, этот механизм (лишь для обработки exception) на основе "устных соглашений", вне контракта системы типов или без явных управляющих языковых конструкций. Может быть, каким-то способом через compiletime-макросы можно сделать механизм и с явными декларациями, в том числе и эмуляцию finally-секций или RAII (т.е. исполнение обработчиков и при "обычном" выходе из процедур), и может быть с иной стоимостью runtime-обработки метаданных (или вообще без интроспекции).

А в целом, вопрос в целесообразности. В самом Go defer-а не достаточно, раз уже имеются неструктурные прыжки, то тогда уж и обработку ошибок возникает желание делать не только "структурными if-ами", из-за чего собираются добавить и check с handle:
Обработка ошибок в Go 2

Откровенно говоря, механизм scope в D выглядит, хотя бы по крайней мере, однородно на фоне Go-экспериментов:
https://dlang.org/articles/exception-safe.html

Однако, в случае существенного разнообразия видов всех этих "defer-ов" уже под вопросом понятность алгоритмов.
Причём, согласно статейке выше про exception в Оберон-ах, эти "defer-ы" покрывают лишь т.н. terminate-семантику (в вариантах success, failure или же в целом finally), и нет resume- и retry-семантики.

В Rust-е, к слову, когда-то предлагали и эмуляцию лисповых "conditions and restarts" (resume-семантику), в дополнение к прочим макросам для обработки ошибок:
https://static.rust-lang.org/doc/0.8/tutorial-conditions.html#conditions

По крайней мере, есть ещё "автоматные" подходы -- иерархические "состояния" или автоматы с "вытеснением" внутренних состояний/автоматов. Идеи "реактивного программирования" из 80-х в мейнстрим притянули лишь частично и в искажённом представлении (точнее, современные игры в "реактивность" совсем иные на фоне истоков).
Ниже примерчик из С-подобного экспериментального языка SHIM (для верификации систем), где exception-ы построены по некоторым мотивам из Esterel:
Scheduling-Independent Threads and Exceptions in SHIM

Exception-ы в статейке, как минимум, имеют несколько иную, отличную от привычной семантику. Этот конкретный вариант механизма несколько усложнён и спорный в ряде моментов, и это всего лишь пример. А в целом, exception-ы выше это замаскированные некоторые "сигналы" (в более привычной форме как объекты Exception и в виде операторов try/catch) из древней автоматной школы (здесь на форуме про Esterel/Lustre и производные есть отдельная темка). И гипотетически в языке возможен единый способ выражения структур данных и процессов над ними, включая параллельные (истинно параллельные и корутины), что по сути, на фоне Go, есть альтернатива не только отдельным механизмам обработки ошибок и RAII (с поддержкой всех вариантов семантики), но и Go-рутинам с оператором select и пр. Но это отдельная и непростая тема.

Сериализация, говорите, в голанге есть. Это больше похоже на её отсутствие...
В частности, попробовал сделать парсинг CSV аналогично, как делал на Object Pascal. Скорость парсинга, в приципе, получил соизмеримую. Но! Хвалёная сериализация встроенная в Go (GOB) это просто какой-то сплошной дикий тормоз. Наверное в A2 в XML-ки гораздо быстрее сериализуется! В Object Pascal встроенная сериализация работает просто молниеносно быстро. Ip2Location база пишется/читается за 2 мс. В Go чтение/запись GOB такие же по скорости как парсинг CSV. Это ж просто бред какой-то, а не сериализация! Зачем она такая нужна???
И в Object Pascal бинарники (сериализованные данные) в 6 раз компактнее!
Вот, подобное с 12-го года висит Parsing gob is significantly slower than parsing JSON
И подобных тем и бенчмарков целая куча. Не понял ещё, правда, кто же победитель по скорости...

В Active Oberon есть близкий аналог - FINALLY

Нет варианта с отображением файла в память ))

Сериализация в Object Pascal, это практически отображение из памяти / в память, очень эффективная реализация. Смотрю теперь на то как сделано в Go как на "Цырк на дроти" (Цирк на проводе). Как можно было такое убожество выкатывать в массы?

Да вроде, обычное чтение из потока было, или что-то в этом плане изменилось и они стали мапить файлы?

Не очень понял, о чём речь. Но допустим, отображение в память. Можно ли сломать систему, подсунув ObjectPascal определённым образом подготовленный файлик?

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

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

В чём небезопасность, конкретно? Вариант, что существующая стандартная реализация просто не эффективна, не рассматривается?

Тут вопрос такой: если данный вид файла может прийти по сети, замапить поинтер и выполнить произвольный код, то это неприемлемо и нужен другой формат, защищённый от таких штук. Если он создаётся только локально, то тогда другой разговор - байтики на локальном жёстком диске всегда можно как-нибудь подменить, поэтому защищаться от такого варианта локально нет смысла.

Это же просто ресурс, там нечего выполнять. В windows-версии он вообще хранится в исполняемом файле программы

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

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

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

Из-за того, что не надо парсить значения (в случае бинарного представления).

В общем-то, наверое, глупость я написал. В файле не может быть указателей, максимум там могут быть смещения, которые нужно "перелинковать" после загрузки файла в память. А если отличие в скорости за счёт бинарного формата, то тогда дело вообще в другом и с т.з. безопасности разницы особо нет. Хотя парсить нужно и бинарный формат, просто парсер может быть экстремально простым и поэтому быстрым.

Так при отображении файла в память мы не используем файловые операции, а обращаемся напрямую к памяти. Поэтому нет тормозов в работе

Т.е. у наc уже две версии

какие версии? Достаточно посмотреть значение термина Отображение файла в память