Больше карбона, меньше си++

[vak]

Гугл предлагает новый язык Карбон на замену Си++. Проект на Гитхабе: https://github.com/carbon-language/carbon-lang

К примеру, вот такой код на Си++:



превращается в код на Карбоне:

Comments

[archaicos]

Можно без fn, var, ->.

[vak]

Хотят быть похожими на Rust.

[x86128]

Для такого синтаксиса получается простой парсер

[archaicos]

Ну, с одной стороны легче находить функции и переменные без честного учёта типов и деклараций.
А с другой стороны он всё равно нужен, если не городить динамические типы.

[archaicos]

Такая дебильная стрелочка и в C++ есть. В этом же самом месте.

[x86128]

Она там вообще не нужна, так как слева и так скобка ) а справа {, если между ними чтото есть это и есть тип возвращаемого значения

[archaicos]

Я чуть чаем не подавился, когда это увидел впервые. Уже ж был синтаксис, хоть и кривоватый, но к которому привыкли. К нему добавили ещё одну кривизну без необходимости.

[vak]

О, я и не знал. Начиная аж с С++11, оказывается.

[tiresome_cat]

Мне нравится. С другой стороны, я вообще с++ терпеть не могу :)

[vinsent_ru]

как по мне так то же самое, ну да синтаксис почище, да и все

[vit_r]

Повысили когнитивную сложность. Хотя, задачки на интервью будет решать прикольнее.

[bowhill]

Заимствования fn и типов из rust – это молодёжно, fn как и var часто избыточен, аббревиатурные же ключевые слова менее читабельны. Далее, помимо вкусов, тип не является атрибутом элемента (hello, typescript), это с ног на голову. Тем более что fn – тоже тип. Ну, и немного java, конечно. Интересный букет.

И если смотреть на него как наследника с++, то как раз получится по части винегретизации. Вообще, интересный и традиционный вопрос, какие языки служат материалом для размышлений авторов.

[juan_gandhi]

Друзья Сергея и Ларри продолжают развлекаться (имхо).

[vlad_m]

Могут себе позволить. )

[vak]

Развлекаться и я люблю. Лишь бы толк был.

[vlad_m]

Препроцессору, в общем, давно пора на покой.

Импорты вместо инклюдов.

Остальное не выглядит сильно компактнее.
Дьявол кроется в библиотеках,
посмотрим, насколько менее (или более) ужасными будут конструкции с использованием vectors, lists, maps и т д.

Slice, няп, встроен в язык. Уже неплохо.

[ircicq]

Импорты и в C++20 есть

[vak]

Только не работают они толком.

[kondybas]

А параметризацию можно сделать без препроцессора?

[ichthuss]

Темплейты отлично работают без препроцессора. Разумеется, это не настолько универсальный инструмент, но близкий по универсальности.

[kondybas]

Няз, STL реализован через препроцессор?

[ichthuss]

Вроде бы наоборот, препроцессор там никаким боком, одни сплошные темплейты.

[vlad_m]

Условную компиляцию? В рамках одного набора исходников - нет.
Даже с темплейтами и абстрактными интерфейсами (все методы pure virtual) где-то должен быть главный агрегатор, инстанциирующий конкретные классы.
Но можно условно включать/не включать в список исходников схожие по API модули, заточенные под разные варианты таргетов.
Разные варианты агрегаторов, например.

[spamsink]

C++ написан как жалкий позор. Надо

for (auto & c : circles), или даже без & - нечего референсы на пустом месте без надобности разводить. И когда С++ написан по-современному, а не как 10 лет назад, становится видно, что этот их карбон - тоже жалкий позор.

auto main(...) -> int - вообще за пределами добра и зла.

[vak]

Да уж, с main они дали маху.

Но в целом я не против, если товарищи осилят соорудить "улучшенный Си++", да добавят к нему пакетный менеджер типа cargo. От Rust я подустал чего-то.

[sab123]

Ой нет, от пакетных менеджеров - один вред и никакой пользы.

[spamsink]

Классическая фраза "Those who do not understand X are bound to reinvent it, poorly" верна и для X = C++ (в оригинале, если кто не помнит, X = UNIX).

[vak]

Ну вот Golang ведь вполне приличный язык получился. Но тут народ вообще полную совместимость с Си++ библиотеками и include-файлами желает иметь.

[x86128]

Кажется, что проблемы некоторых олдовых языков больше связаны с бардаком в библиотеках и сборочных инструментах, было бы хорошо если бы перетащили практики из go или rust (пакеты, линтеры, форматеры и сборщики) и управление версионнностью зависимостей.

[ivanrubilo]

А можно спросить,
Вы использовали Rust серьёзно на работе? И если так, то по прошествии так сказать "honey moon" что теперь думаете про Rust? И какие основные pain points?

Я только игрался с ним в мелких проектиках и думал может работу подыскать где 100% Rust, но ещё не настолько крут с ним чтобы профессионально только его юзать для работы :(

[vak]

Да, я использовал Rust серьёзно для работы. Для одного изолированного проекта, как ни странно, с GUI. Проект имел успех: за полгода команда из трёх малоопытных человек написала исходный код с нуля и выпустила релиз. Теперь продукт используется внутри компании.

Проблемы две. Во-первых, язык надо учить. Даже если у вас тридцать лет опыта в других языках, вы не сможете просто так взять и начать писать на Rust. Фокус проходит с Golang, D, Swift, Dart, но не здесь. Придётся проштудировать как минимум одну-две книжки. Привыкнуть к странным концепциям, типа Box вместо указателей и т.п.

Во-вторых, имеется масса tribal knowledge. В том смысле, что некоторые фичи языка не постигаются интуитивно или через чтение мануалов. Приходится выискивать примеры в исходном коде разных проектов и выяснять тонкости оттуда. Гуглить и читать блоги экспертов. Всё это замечательно развивает мозги и поднимает собственную квалификацию, но трудоёмко до чёртиков.

Но кто пробовал Rust - после cargo возвращаться к cmake нет никакого желания.

[ivanrubilo]

Спасибо за развёрнутый ответ!

[norian]

шо, ещё один киллер крестов ? ню ню

из крестов надо выкидывать отложения легаси и рефакторить, а вместо этого туда пихают всего побольше и помоднее

[archaicos]

Меня удручает сочетание размера современного C++ с неоднородностью. Если бы фичи прямо вытекали друг из дружки, стройно без исключений по соображениям обратной совместимости и тупой незаконченности, было бы лучшее. А так ты не можешь даже быстро определить что в данном контексте сделает какое-нибудь foo(), и даже какое именно из них, если их несколько, будет вызвано. Получается помойка для любителей dumpster diving.

[sab123]

Языкам без препроцессора место в сортире.

[ichthuss]

Препроцессор легко подключить к любому языку.

[bowhill]

А исходники общие или как?

Бывает, что два хороших стандарта хуже одного посредственного.

[ichthuss]

Вы можете сформулировать свой вопрос яснее?

[bowhill]

Можно более развёрнуто. Исходный текст для транслятора языка и для препроцессоров – это один и тот же текст?

Есть тест на языке, в который можно добавлять вкрапления для одного, второго, третьего препроцессора. Такое встречается, скажем, помимо стандартного препроцессора в с можно использовать doxygen, да что угодно.

[ichthuss]

По определению, исходный текст для транслятора языка - это выход препроцессора, и он обычно не совпадает с входом препроцессора (иначе зачем вообще препроцессор?).

[bowhill]

Не обязательно. С препроцессором или без, текст может быть корректным высказыванием на языке, и так же не обязательно, что препроцессор меняет текст. Но это сторонние замечания, не связанные с идеей.

А идея в том, что если в языке нет препроцессора, то a) его скорее всего и не будет или b) их будет несколько: два, три, пять. И из всех из них, весьма часто, будет мешанина (спагетти). И на каком именно языке, в итоге, будет код – сказать затруднительно.

[vak]

Кто программирует на Си/Си++, жизни не может представить без препроцессора. Однако в том же Rust препроцессор гораздо более мощный и удобный. Просто надо мыслить ширшее.

[sab123]

Самая мощная и удобная часть препроцессора - #if и #ifdef, в частности #if 0. Ничего мощнее и удобнее я не видел.

[vak]

Постоянно пользуюсь #if 0. Но код, вычеркнутый подобным способом, быстро устаревает при интенсивной разработке. Меняются переменные, окружение, методы - уже легко не раскомментируешь. Иногда лучше ставить if (false) { ... }.

[ccpro]

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

и наконец языки "сочиняют" умники, а используют простые смертные, которым плевать на узоры, им зарплату получать надо