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

Как всё сложно. Другие федеральные службы и сами постирают, и сами принесут, и перестирают, если плохо отстиралось.

Ошибку в unsafe легко отловить — она локализована, а остальной код проверяет компилятор, если, конечно не писать в стиле «unsafe fn main()». Если, как в Си, при разыменовании любой указатель может потенциально быть невалидным, это уже совсем другое дело. Понятно, что в современном С++ сейчас нет особенной нужды на каждом шагу жонглировать указателями, но частных случаев, неявных приведений, методов по умолчанию, и т. п., остаётся до ужаса много. Вон даже в банальной арифметике столько разных нюансов. Тут где-то на Хабре была статья бывшего плюсовика со стажем чуть ли не в 20 лет, который подробно описывал свои мысли по этому поводу.

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

enum Color {
    Grin {r: u8, s: String},
    Red (f32)
}

fn func(e: Color) {
    match e {
        Color::Grin { r, s } => {
            println!("Grin: {}, {}", r, s)
        },
        Color::Red (t) => {
            println!("Red: {}", t)
        }
    };
}

fn main() {
    func(Color::Grin {r: 9, s: String::from("not bad") });
    func(Color::Red (4.5));
}

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

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

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

Я перевёл программу Лавлейс на язык C

Почему не на язык Ада? :)

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

Изначально, возможно, их можно было упрекнуть в этом. На данный момент, GLib и набор библиотек, простроенных на ней, являются сишным ядром, а разработка может вестись на более высокоуровневых языках, в том числе и C++ (gtkmm и glibmm — биндинги к C++).

Что касается Vala, тут вы сравниваете совершенно разнородные сущности. У Vala вполне конкретная ниша — прикладные десктопные приложения, в первую очередь для GNOME и GTK-based окружений. У Vala очень простой и дружелюбный синтаксис, обширная стандартная библиотека, делающая построение десктопных приложений простым и приятным процессом. Вне этой ниши использовать Vala большого смысла нет, в общем-то. Это не конкурент C++, скорее, его можно сравнивать со Swift — язык конкретный платформы и фреймворков.

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

Glib != GTK

В таком виде да. Но GTK+ построен на системе GObject, которая является частью GLib, так же как построены на GObject GStreamer, GSettings, Pango, GIO, ATK и многие другие, более высокоуровневые системные компоненты.

Хотя бы из соображений удобства создания биндингов для более высокоуровневых языков. Кроме того, значительный пласт приложений под UNIX-системы использует фреймворк GLib/GTK+ в чистом виде.