среда, 6 октября 2021 г.

[prog.c++] Хотелось бы увидеть в мире C++ сценарий Kotlin/Ceylon из мира Java

На вынесенную в заголовок тему заставила задуматься статья: С++23 — feature freeze близко. Несколько моих комментариев к ней и к сопутствующим материалам в FB: раз, два, три.

Есть ощущение, что С++ уже не просто подошел к пределу моих умственных способностей, но и сильно их превзошел. Подозреваю, что моих мозгов не хватит, чтобы освоить C++20 и C++23 на более-менее приличном (для себя) уровне.

И винить здесь C++ бессмысленно. Он просто живет и эволюционирует. Следовательно, он будет усложняться и дальше (на эту тему я когда-то писал большую статью, продолжаю находиться при мнении, что это естественный процесс с которым ничего не поделаешь).

Невольно задумаешься о том, а как должны были бы развиваться события, чтобы появилась какая-то надежда на горизонте?

Сейчас я бы присмотрелся к сценариям, которые в мире Java пытаются претворить в жизнь Scala, Ceylon и Kotlin. Т.е. на базе уже существующей экосистемы создать инструмент, который бы был удобнее Java, но позволял бы использовать то, что в Java уже есть.

Как по мне, так вместо введения тех же модулей в C++20, было бы гораздо перспективнее сделать какой-то новый язык, который мог бы бесшовно интегрироваться с уже существующим C++ным кодом.

Грубо говоря, какая-то спроектированная на современном уроне Vala, которая бы, в примитивном сценарии, просто транслировалась в C++ный код (например, на C++17) и компилировалась бы далее обычным C++ным компилятором. И из которой можно было бы использовать C++ные библиотеки напрямую, без необходимости писать какие-то обертки (ну или с минимальными усилиями по написанию таких оберток).

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

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

12 комментариев:

  1. Ваши бы слова да Богу в уши. Хотелось бы, конечно, особенно Котлина в мире С++ - чтобы максимально практично, сделано инженерами для себя же. Со всеми современными фишками но без излищней зауми. С разными бэкендами (чистый си - с++ - LLVM - whatfnever). С поддержкой крупной корпорации (как минимум одной) за спиной. С как минимум одной выбитой в честном бою экологической нишей (как Андроид для Котлина). Но что-то за последние 20 лет оно так и не появилось - люди никак не поймут будет ли смысл в нативе через 10 лет и стоит ли вообще вкладываться в развитие могильщика C++.

    ОтветитьУдалить
  2. > люди никак не поймут будет ли смысл в нативе через 10 лет и стоит ли вообще вкладываться в развитие могильщика C++.

    Как бы Swift, Go и Rust намекают, что нейтив никуда не денется.

    Другое дело, что при наличии Rust-а надобность в другом C++ киллере для многих будет неочевидна. Но в моих фантазиях поинт в том, чтобы новый язык с минимальными проблемами мог библиотеки на C++17 (и более младших версиях) переиспользовать. В том числе и с активным применением шаблонов написанные. Такого в Rust-е никогда не будет.

    ОтветитьУдалить
  3. > Другое дело, что при наличии Rust-а надобность в другом C++ киллере для многих будет неочевидна.

    Мне почему-то кажется что Rust уже не взлетит. Идея была интересная, революционная - но народ жалуется что получается слишком сложно. Проще чем С++ но и близко не так просто как тот же Go. Ну и скорость компиляции никак не могут победить - и, похоже, не смогут уже. Т.е. самое время очередному С++ киллеру выскочить из табакерки.

    ОтветитьУдалить
  4. Ну и да - кстати - возможность использования шаблонов С++ потребует там наличия компилятора С++ внутре, со скоростью работы компилятора С++, что как бы убивает 90% удовольствия от нового языка.

    ОтветитьУдалить
  5. > Т.е. самое время очередному С++ киллеру выскочить из табакерки.

    Это было бы очень интересно.

    Хотя по поводу Rust-а у меня более оптимистичные прогнозы. Видимо, это язык, который будет идти в мейнстрим долго. Но неизбежно. Однако, это будет специфический мейнстрим, околосистемный. Что-то вроде Ada, но не для военных, а для СУБД, MQ-шных брокеров, mail-серверов и т.д., и т.п.

    ОтветитьУдалить
  6. > что как бы убивает 90% удовольствия от нового языка.

    Для меня скорость компилятора не критична. Но я и над небольшими проектами работаю.

    ОтветитьУдалить
  7. Ну и для меня львиная доля удовольствия бы состояла в том, что из нового языка можно было бы сходу использовать все тот же Asio, RapidJSON (с нашим json-dto, конечно же), ImageMagic, Dear Imgui и все то, что уже есть. И с чем уже есть опыт работы.

    По крайней мере на первые 10-15 лет, пока "родные" варианты не подъедут.

    ОтветитьУдалить
  8. Вслед за скоростью компилятора идет поддержка со стороны IDE. Тот же Котлин Intellij Idea поддерживается только чуть хуже джавы, а вот скала - ой-ой. Медленно и жутко глюкаво. Если мы затащим в новый язык C++ 17 - то поддержка IDE к нему созреет лет через 15.

    ОтветитьУдалить
  9. И опять же, насчет поддержки старых библиотек. Да, из Котлина можно дергать старые джавовые и это гуд. Но! В котлине есть своя стандартная асинхронность, в джавовых оно сделано в каждой библиотеке по-своему. В итоге - на старые библиотеки все равно пишут врапперы (да, благодаря синтаксической гибкости Котлина это могут быть 3 строчки кода, но тем не менее). Я к чему - все равно врапперы на старые библиотеки писать придется, хотя бы для того чтобы код сделать идеоматичным.

    ОтветитьУдалить
  10. Тут я не готов разговаривать о деталях.

    Возможно, можно было бы сделать что-то вроде:

    import(c++)

    и это бы не было доступно для IDE в такой же степени, как сущности, которые определены уже в рамках нового языка.

    Или же чтобы был какой-то слой, внутри которого определяются обертки для C++ного кода, а IDE уже видит только то, что экспортированно наружу из этого слоя.

    В общем, смысл в том, что если из нового языка с минимальными усилиями можно задействовать, скажем, наш SObjectizer, то это есть гуд. А если нужно SObjectizer под новый язык переписать (пусть даже на 50%), то это уже очень и очень плохо. Проще тогда уже под Rust переписать.

    ОтветитьУдалить
  11. Упс, блогер кусок комментария выбросил.

    Предполагалось что-то вроде:

    import(c++) <asio/asio.hpp>

    ОтветитьУдалить
  12. Со стороны Rust уже предпринимаются попытки интегрироваться с C++. Самый живой проект - это CXX:

    https://github.com/dtolnay/cxx
    https://cxx.rs/index.html
    https://docs.rs/cxx/

    Есть еще более старый Cpp:

    https://docs.rs/cpp/
    https://github.com/mystor/rust-cpp

    ОтветитьУдалить