Carbon: кому и зачем нужен новый язык от Google и почему корпорации не нравится C++

Carbon — это новый язык общего назначения от разработчиков Google. Создаётся как альтернатива C++, а его исходники уже можно полистать на GitHub. На мой взгляд, было две причины для создания Carbon. Первая — идейная, а вторая — бизнесовая.

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

Бизнес-причина. В Google всегда активно использовали C++: в книге Software Engineering at Google от 2020 года говорится о 250 миллионах строк, а с момента выхода книги это число значительно выросло. Логично, что Google всегда был одним из самых крупных амбассадоров экосистемы C++ (например, формат Clang-Tidy придумали и развивали именно в Google) и вложил в развитие «плюсов» значительное немало денег и ресурсов, а также долгое время состоял в комитете (рабочей группе) по C++.

Google всегда хотел развивать новые возможности языка, но постоянно возникали какие-то проблемы и к общему знаменателю с остальными участниками прийти не получалось. Например, корпорация предлагала заменить unordered_map на flat_hash_map, однако сделать это было практически невозможно, потому что существует скомпилированный ещё 20 лет назад код, который пока ничем не заменить. И подобные препятствия попадались всё чаще.

В итоге, сколько бы Google ни старался что-то менять, практически ничего не получалось. А что происходит, когда какая-то система стагнирует? Если у того, кто недоволен состоянием системы, достаточно сил, он просто разрабатывает аналоги (или это делают конкуренты). Так и появился Carbon — следствие бизнес-потребности Google в развитии C++: не смотреть на код 40-летней давности, а апдейтить его под свои нужды. С комьюнити «плюсов» договориться о развитии и поддержке нового языка не вышло, поэтому компания пытается создать что-то своё.

Кстати, похожая история была у Apple. У неё вообще свой путь: раньше в компании активно использовали C++, а теперь заменили его на Swift. Хотя и там всё до сих пор сложно — операционные системы продолжают писать на C++, а на Swift создают лишь клиентские приложения. Возможно, Google тоже пытается двигаться в эту сторону.

А прежде чем начнём разбираться, кому же пригодится новый язык и что у него под капотом, дам небольшой дисклеймер:

Кому нужен Carbon

Целевая аудитория Carbon — большие компании. По-моему, была идея привлечь NVIDIA, Bloomberg и другие компании, которые вынуждены пользоваться C++, но устали от него и постоянной борьбы с комитетом за новые фичи.

Такие компании не любят C++, потому что в нём регулярно возникают инциденты безопасности (security incidents). И менеджмент каждый раз спрашивает, что опять произошло, интересуется, можно ли наконец начать писать код без багов. А разработчики отвечают, что C++ так устроен — по-другому писать на нём просто невозможно.

В итоге всё пришло к тому, что сегодня выигрыш от производительности C++ перестал покрывать потери от инцидентов безопасности. Кстати, полагаю, что это как раз та причина, по которой Rust должен обойти C++ в популярности, — ведь в Rust намного меньше багов и security incidents.

Итак, Google хотел привлечь к работе над Carbon крупные компании. Но что же вышло? IBM, кажется, не выразила заинтересованности, Microsoft пока тоже не горит желанием оказывать какую-то особую поддержку Carbon. Сотрудники NVIDIA, Bloomberg, Adobe поддержали идеи Carbon лишь в частном порядке.

Большим компаниям вообще тяжело полностью слезть с иглы C++ — именно поэтому в Google так активно пытаются проложить мостик между C++ и Carbon.

Этот мостик сможет брать старые файлы на C++ и автоматически импортировать их так, что ими можно будет пользоваться из Carbon. Скорее всего, мостик будет работать далеко не во всех случаях и иметь много ограничений, но главное, что он будет.

Пока в Google пишут код на обоих языках. Кардинально ситуация может измениться, если Google введёт у себя запрет на написание нового кода на C++. Только в этом случае начнётся медленный, но верный процесс переезда кода, старых библиотек и проектов на Carbon. Думаю, что в сумме процесс этот займёт лет десять, не меньше.

Кто разрабатывает новый язык

Есть такой известный в кругах C++ человек — Чендлер Каррут. Он много сделал для LLVM и Clang, но в то же время стремился совершить какой-то качественный карьерный переход. Таким переходом для него стала работа над новым языком Carbon, который он впервые представил миру в июле 2022 года на конференции CppNorth:

Чендлер и сам довольно талантливый инженер, и в свою команду он взял очень сильных ребят, которые давно занимаются языками программирования. Сейчас в этой команде около пяти основных участников: все очень серьёзные инженеры, и почти все успели поработать над Clang.

Например, Ричард Смит принимал участие в разработке стандарта C++ и долгое время отвечал за документацию, а Джош Левенберг был идейным вдохновителем переезда Google на Clang- и LLVM-инфраструктуру.

Чем Carbon отличается от C++

Carbon — язык с более удобным, чем в C++, синтаксисом. Google, по сути, убирает всё «плюсовое» легаси, а также оказывает пользователям поддержку при переезде с C++ на свой язык. Дело в том, что C++ как экосистема совершенно против переездов — даже на уровне идеологии, а Carbon как раз будет поддерживать эту возможность. В этом одна из ключевых фишек нового языка.

Ещё одно преимущество Carbon — в регулярных обновлениях. Здесь не будет таких проблем, как вокруг ABI Compatibilities, или бинарной совместимости.

Что это за проблема: в C++ и в C есть давняя история, связанная с обратной совместимостью. Приложения, написанные на новых версиях языка, обязаны корректно работать со старыми версиями библиотек — это один из приоритетов в C++. Однако именно из-за этого полным ходом идёт стагнация языка: в языке куча фич, которые двадцать лет назад были ОК и выглядели вполне современно, а на новом железе просто неэффективны. Мы вроде как можем зарелизить новую фичу взамен старой, чтобы она работала гораздо лучше, но у нас есть ABI Compatibilities и мы обязаны делать фичи такими, чтобы они работали и на старом железе.

Конечно, можно маркировать код — это старая версия, это новая версия (как в HTML или CSS делают вёрстку под разные браузеры и устройства и помечают это в коде), однако разработчиков-плюсовиков практически невозможно вдохновить на такую работу — к тому же комитет C++ не хотел делать форк стандартной библиотеки и развивать несколько её версий параллельно.

При этом гиганты вроде Google, «Фейсбука»* и Adobe утверждают, что уже прошли ту эру C++, когда приложения собираются с нуля, а потому кейсов, в которых необходима обратная совместимость, очень мало. Хотя в других компаниях, которые сидят на экосистеме C++, такая совместимость может требоваться очень часто.

Комитет на фоне этого вопроса даже сильно разругался: да, игнорировать обратную совместимость невозможно, но при этом надо как-то развивать язык и идти вперёд, а что делать — всё равно непонятно. В общем, это сложный философский вопрос — и Google ответил на него с помощью Carbon. Дело в том, что языки типа Rust и Carbon никогда не обещают такой «вечной» обратной совместимости — и это заложено в них на уровне философии. Развитие — важнее.

Подобную проблему уже решают в геймдеве. Каждый из нас мог сталкиваться с патчами к играм. Например, выходили регулярные патчи к Cyberpunk 2077 — и через шесть месяцев игра под капотом фактически становилась совершенно другой. При этом после каждого патча все ваши «сохранялки» должны продолжать работать, а значит, мигрироваться.

К тому же бывают и каскадные изменения — когда игрок полгода не качал обновления, а потом разом перескочил условно с версии 1.01. на 1.06. Да, языки программирования — это более открытые сущности, чем игры, но тоже вполне можно придумать механику, при которой язык не отстанет от развития железа, будет приятным, эффективным и даже, не побоюсь этого слова, модным.

Синтаксис Carbon

Carbon — язык программирования с приятным синтаксисом и фишками, которые зарекомендовали себя в других языках в последние несколько десятков лет. Вообще, вся IT-индустрия живёт всего лет семьдесят, и сорок лет из них — с C++. Поэтому, конечно же, синтаксис нужно регулярно обновлять.

Но я не верю, что синтаксис хоть как-то влияет на продуктивность разработчика — на продуктивность гораздо больше влияет архитектура написанного кода и возможность легко его читать. C++ читать довольно легко — вы просто привыкаете к нему. Единственное, что сложно читается в C++, — это шаблонные 20 тысяч строк. В общем, в моём мире не существует более простого или более сложного синтаксиса. Да, в C++ свои болевые точки, но и в Carbon они вполне могут быть — просто я пока о них не знаю, так как этот язык ещё в разработке.

Модульная система

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

Но это всё ещё довольно серьёзное легаси, которое очень тяжело исправить. Поддержкой модулей могут пользоваться сейчас, наверное, только единицы. В Rust тоже используют модули. А Carbon уже из коробки предлагает модули и пакетный менеджер.

Шаблоны

В Carbon попытаются сделать более приспособленную к жизни и понятную людям шаблонную систему. В C++ шаблоны довольно страшные. В Carbon сделают систему шаблонов, похожую на Rust. Например, generics должны описывать те операции, которые можно выполнять с типами, когда как в C++ происходит так называемый duck typing, когда только компилятор проверяет совместимость тех операций, которые используются внутри. В общем случае это называется bounded parametric polymorphism vs ad-hoc polymorphism.

Если вы хотите писать на C++, просто продолжайте писать на C++, который продолжает развиваться, хоть и по-своему. Carbon в сравнении с C++ более удобный, потому что в нём нет легаси, и требует чуть меньше знаний.

Carbon и Rust

Не секрет, что Google одновременно смотрит и в сторону Rust. И путь развития Rust мне нравится больше. Но мы написали столько кода на C++ — как нам теперь взять и сразу переехать на Rust? Это возможно, только если мы сможем написать инструмент, который берёт код на C++ и превращает его в Rust. Только в таком случае сама идея существования Carbon может стать нежизнеспособной — а пока Rust в деле замены C++ на старых проектах с большим количеством легаси ему не конкурент. Rust уже можно использовать на Android, но в Google Android — отдельная сущность.

Carbon изначально создавался с намерением проложить мостик к C++ и позволить командам разработчиков безболезненно переходить с одного языка на другой, переносить кодовую базу. С одной стороны, очень тяжело создать такой язык с нуля. С другой, написать мостик между Rust и C++ — не менее простая задача.

Критика Carbon основывается на том, что Rust в какой-то степени считался преемником C++. Но с этим тезисом не все согласны — это холиварная тема. У Rust была идея, что программисты не умеют писать код без багов. Конечно, это факт, с этим ничего не поделать. Динозавры говорили: если вы не умеете писать код без багов, то вы плохой программист. Но на самом деле все пишут код с багами — и если вы хотите расширять экосистему языка, это придётся учитывать.

Вообще, Rust возник из идеи создать язык, у которого не будет проблем с памятью, а у Carbon такой идеи нет — он не будет безопасным в сфере памяти, но будет подсвечивать такие проблемы. Это часть идеологии Carbon: он хочет быть таким же быстрым, как C++. Хотя, справедливости ради, всё ещё непонятно, что быстрее — Rust или C++, это тоже до сих пор холиварная тема, точку в которой никто пока не поставил. Однако на C++ написать более быстрый код действительно проще, чем на Rust.

Carbon стремится быть как C++ с точки зрения перформанса — а вот идей по безопасности памяти у команды пока не было. Именно поэтому Carbon пока больше напоминает именно C++, а не Rust.

Кажется, сложилось два лагеря. С одной стороны — люди, которые хотят memory safety, чтобы ничего не ломалось, чтобы программа работала, когда скомпилировалась. Люди по другую сторону хотят быть ближе к ассемблеру, но с элементами ООП. Если вы хотите быть в первом лагере, то будете писать на Rust. Если во втором — лучше выбрать Carbon.

Развитие и спецификации Carbon

Развитие Carbon будет осуществляться по пути, похожему на путь Go. Есть комьюнити, которое развивает язык, а Google в какой-то степени это развитие мягко контролирует. Думаю, первое время спецификациями будет заниматься компания, а со временем эту задачу подхватит комьюнити — оно будет набирать вес, путём голосования выбирать тех, кто представляет интересы сообщества. Но всё это будет, только если Carbon выживет.

Я не поддерживаю идею монополии на языки программирования — это открытые системы, которые нужны людям, они не должны принадлежать компаниям. Языки программирования никогда не выживают, если они закрыты. В какой-то степени поэтому Carbon пошёл в open source. Но на Carbon пока никак не повлиять человеку извне. Пока есть только возможность посмотреть на него со стороны и дать фидбэк — именно для этого его и представили общественности в июле 2022 года.

Кажется, первый фидбэк в целом не очень: с момента анонса прошло уже три месяца, а идея языка, по ощущениям, не очень выстрелила — люди не кричат о Carbon на каждом углу. Посмотрим, что будет происходить дальше.

* Решением суда запрещена «деятельность компании Meta Platforms Inc. по реализации продуктов — социальных сетей Facebook и Instagram на территории Российской Федерации по основаниям осуществления экстремистской деятельности».