воскресенье, 24 июля 2022 г.

[prog.flame] Если можно, то не спрашивайте меня про новый язык Carbon

Тут в наших Интернетиках разгоняется новый хайп вокруг экспериментального языка 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 комментария:

Alex комментирует...

А что там с Zig, Nim? Если смотрели, есть кто-то интересный? Или для всех этих задач сейчас берут Rust? Я чисто с практических точек зрения.

Я писал на C++ в режиме "C с классами" почти 20 лет назад (Visual C++ 6.0). Я вот даже не представляю, как сейчас подойти к современному языку, после C++ 11, 14, 17. Тот код, что вы иногда постите в блоге, я честно не понимаю. Если это равносильно изучению с нуля, то что могло бы его заменить? Я понимаю, что язык выбирает заказчик/работодатель, но гипотетически.

eao197 комментирует...

@Alex

ИМХО, если с чисто практических точек зрения и у вас нет возможности выбирать язык для нового проекта, то нет смысла смотреть в сторону пока еще недобравшейся до мейнстрима маргинальщины, вроде Zig, Nim, Crystal и иже с ними.

Заменами C++, на мой взгляд, сейчас являются Go и Rust (это если нужна компиляция в нативный код). Но и C++ в ближайшие годы никуда не уйдет. Возможно даже спрос на толковых разработчиков только вырастет, но за счет того, кто кому-то унаследованные кодовые базы на C++ нужно же будет сопровождать. Переписать все это добро на Go/Rust/Carbon вряд ли возможно в обозримое время.