На вынесенную в заголовок тему заставила задуматься статья: С++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 комментариев:
Ваши бы слова да Богу в уши. Хотелось бы, конечно, особенно Котлина в мире С++ - чтобы максимально практично, сделано инженерами для себя же. Со всеми современными фишками но без излищней зауми. С разными бэкендами (чистый си - с++ - LLVM - whatfnever). С поддержкой крупной корпорации (как минимум одной) за спиной. С как минимум одной выбитой в честном бою экологической нишей (как Андроид для Котлина). Но что-то за последние 20 лет оно так и не появилось - люди никак не поймут будет ли смысл в нативе через 10 лет и стоит ли вообще вкладываться в развитие могильщика C++.
> люди никак не поймут будет ли смысл в нативе через 10 лет и стоит ли вообще вкладываться в развитие могильщика C++.
Как бы Swift, Go и Rust намекают, что нейтив никуда не денется.
Другое дело, что при наличии Rust-а надобность в другом C++ киллере для многих будет неочевидна. Но в моих фантазиях поинт в том, чтобы новый язык с минимальными проблемами мог библиотеки на C++17 (и более младших версиях) переиспользовать. В том числе и с активным применением шаблонов написанные. Такого в Rust-е никогда не будет.
> Другое дело, что при наличии Rust-а надобность в другом C++ киллере для многих будет неочевидна.
Мне почему-то кажется что Rust уже не взлетит. Идея была интересная, революционная - но народ жалуется что получается слишком сложно. Проще чем С++ но и близко не так просто как тот же Go. Ну и скорость компиляции никак не могут победить - и, похоже, не смогут уже. Т.е. самое время очередному С++ киллеру выскочить из табакерки.
Ну и да - кстати - возможность использования шаблонов С++ потребует там наличия компилятора С++ внутре, со скоростью работы компилятора С++, что как бы убивает 90% удовольствия от нового языка.
> Т.е. самое время очередному С++ киллеру выскочить из табакерки.
Это было бы очень интересно.
Хотя по поводу Rust-а у меня более оптимистичные прогнозы. Видимо, это язык, который будет идти в мейнстрим долго. Но неизбежно. Однако, это будет специфический мейнстрим, околосистемный. Что-то вроде Ada, но не для военных, а для СУБД, MQ-шных брокеров, mail-серверов и т.д., и т.п.
> что как бы убивает 90% удовольствия от нового языка.
Для меня скорость компилятора не критична. Но я и над небольшими проектами работаю.
Ну и для меня львиная доля удовольствия бы состояла в том, что из нового языка можно было бы сходу использовать все тот же Asio, RapidJSON (с нашим json-dto, конечно же), ImageMagic, Dear Imgui и все то, что уже есть. И с чем уже есть опыт работы.
По крайней мере на первые 10-15 лет, пока "родные" варианты не подъедут.
Вслед за скоростью компилятора идет поддержка со стороны IDE. Тот же Котлин Intellij Idea поддерживается только чуть хуже джавы, а вот скала - ой-ой. Медленно и жутко глюкаво. Если мы затащим в новый язык C++ 17 - то поддержка IDE к нему созреет лет через 15.
И опять же, насчет поддержки старых библиотек. Да, из Котлина можно дергать старые джавовые и это гуд. Но! В котлине есть своя стандартная асинхронность, в джавовых оно сделано в каждой библиотеке по-своему. В итоге - на старые библиотеки все равно пишут врапперы (да, благодаря синтаксической гибкости Котлина это могут быть 3 строчки кода, но тем не менее). Я к чему - все равно врапперы на старые библиотеки писать придется, хотя бы для того чтобы код сделать идеоматичным.
Тут я не готов разговаривать о деталях.
Возможно, можно было бы сделать что-то вроде:
import(c++)
и это бы не было доступно для IDE в такой же степени, как сущности, которые определены уже в рамках нового языка.
Или же чтобы был какой-то слой, внутри которого определяются обертки для C++ного кода, а IDE уже видит только то, что экспортированно наружу из этого слоя.
В общем, смысл в том, что если из нового языка с минимальными усилиями можно задействовать, скажем, наш SObjectizer, то это есть гуд. А если нужно SObjectizer под новый язык переписать (пусть даже на 50%), то это уже очень и очень плохо. Проще тогда уже под Rust переписать.
Упс, блогер кусок комментария выбросил.
Предполагалось что-то вроде:
import(c++) <asio/asio.hpp>
Со стороны 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
Отправить комментарий