Тут в наших Интернетиках разгоняется новый хайп вокруг экспериментального языка Carbon от Google.
Я потратил некоторое время на входных, чтобы краем глаза пробежаться по текущей версии документа, описывающего дизайн языка.
Краткое впечатление: мне не интересно.
Складывается ощущение, что Google с Carbon-ом решает ту же самую проблему, что и Microsoft двадцать пять лет назад, когда ей не позволили форкнуть Java и "облагородить" ее нужными для Microsoft расширениями. Как говорится, у Java обнаружился фатальный недостаток, поэтому в Microsoft сделали C#.
Теперь вот Google обнаружил в Rust несколько фатальных недостатков. И пытается сделать Carbon, который вроде как и Rust, но с прицелом на дешевый интероп с C++ "искаропки", привычным многим ООП и чуть более щадящим синтаксисом.
Возможно, и с более низким порогом входа. Но об этом пока рано судить.
Мне, как старому C++нику, хочется иметь дело с очищенным от вековых наслоений C++. Т.е. привычный синтаксис, привычные возможности, легкая адаптация старых исходников под новый вариант языка.
Ну, например, стоило бы:
- выбросить typedef;
- выбросить старый синтаксис для объявления указатель на функцию;
- выбросить старый синтаксис определения переменных (чтобы не было загадок из категории "как объявить массив указателей на массивы указателей");
- выбросить унаследованные из чистого Си enum-ы (чтобы остались только enum class);
- выбросить унаследованные из чистого Си вектора в пользу std::array;
- сделать так, чтобы new возвращал не голый указатель, а экземпляр move-only типа std::owner<T>, а в delete можно было передавать только std::owner<T>;
- отказаться от неявных приведений типов;
- отказаться от [[nodiscard]]. Нельзя игнорировать возвращаемые значения. Когда же это можно, то следует ставить отметку [[maybe_unused]];
- отказаться от SFINAE в пользу концептов;
- отказаться от существующего механизма выброса исключений (когда можно бросать все что угодно, но принято разбрасываться наследниками std::exception) в пользу более эффективных исключений, где бросаются только экземпляры std::errc;
- и т.д., и т.п.
Вот такой "очищенный C++" стал бы для меня заменой современному C++, а не этот Google-овский Carbon. Потому что если бы я хотел Rust-а, то просто взял бы Rust.
Пожалуй, это и все, что я пока могу сказать по поводу Carbon.
Посмотрим, что случиться с этим языком через несколько лет, когда он доберется до релиза версии 1.0. До тех пор не вижу смысла к этой теме возвращаться.
PS. Сильное впечатление на меня произвел вот этот пример кода. Такое ощущение, что кто-то хотел Ada-83 в синтаксисе Rust-а :)))
external impl like T as AddWith(like U) where .Result == V {
// `Self` is `T` here
fn Op[me: Self](other: U) -> V { ... }
}
2 комментария:
А что там с Zig, Nim? Если смотрели, есть кто-то интересный? Или для всех этих задач сейчас берут Rust? Я чисто с практических точек зрения.
Я писал на C++ в режиме "C с классами" почти 20 лет назад (Visual C++ 6.0). Я вот даже не представляю, как сейчас подойти к современному языку, после C++ 11, 14, 17. Тот код, что вы иногда постите в блоге, я честно не понимаю. Если это равносильно изучению с нуля, то что могло бы его заменить? Я понимаю, что язык выбирает заказчик/работодатель, но гипотетически.
@Alex
ИМХО, если с чисто практических точек зрения и у вас нет возможности выбирать язык для нового проекта, то нет смысла смотреть в сторону пока еще недобравшейся до мейнстрима маргинальщины, вроде Zig, Nim, Crystal и иже с ними.
Заменами C++, на мой взгляд, сейчас являются Go и Rust (это если нужна компиляция в нативный код). Но и C++ в ближайшие годы никуда не уйдет. Возможно даже спрос на толковых разработчиков только вырастет, но за счет того, кто кому-то унаследованные кодовые базы на C++ нужно же будет сопровождать. Переписать все это добро на Go/Rust/Carbon вряд ли возможно в обозримое время.
Отправить комментарий