Как начать думать о Google Carbon

На последней конференции CppNorth в июле Google представила свой язык программирования, потомок C++, под названием Carbon.

Google только что выпустил 0.1. Carbon 1.0 будет доступен примерно в 2024–2025 годах. Цель состоит в том, чтобы позволить сообществу разработчиков из разных источников иметь достаточное представление на раннем этапе.

При запуске Google упомянул Carbon как естественную преемственность в модели эволюции языка:

  • Microsoft улучшила JavaScript для создания TypeScript (хотя это часто обсуждается в сообществе программистов)
  • Jetbrain улучшил Java для создания Kotlin
  • Apple улучшила Objective C, чтобы придумать Swift

Если вы заметили, во всех вышеперечисленных случаях усилия по улучшению сосредоточены на обеспечении большей статической проверки типов, чтобы предотвратить неправильную обработку типов и, следовательно, сбои во время выполнения, включая сбои и утечки памяти.

Google намерен сделать то же самое для C++ с помощью Carbon.

Это преобразующий шаг. В то же время он выносит так много мыслей, идей и вопросов на передний план области языков программирования.

Как C/C++ повлиял на эволюцию языка (невообразимым образом)

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

В 90-х Sun Microsystems придумала Java. Его основной коммерческий аргумент заключался в том, чтобы запускать кросс-платформу внутри виртуальной машины для интеллектуального управления миллионами устройств. Это достигается за счет сохранения C++-подобного ООП, но устранения уродливого управления указателями.

Java тоже выбрал идеальное время. У Интернета был момент Большого Взрыва, и Java де-факто стал языком для серверов приложений. Java-апплеты какое-то время занимали место в браузере. В течение десяти лет синтаксический брат Java, Javascript, захватил Интернет. Путь Javascript не завершился даже после его серверного аналога Node.js. Он все еще растет.

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

C/C++ продолжал оставаться в ядре как коммерческих, так и некоммерческих систем, которые развивались параллельно:

  • Google, Facebook, Amazon, Twitter и Bing — все они имеют базовую логику приложений, написанную с использованием C/C++.
  • Операционная система Android работает на ядре Linux, написанном на C. Linux написан на C. Mac OS и iOS являются ответвлениями Unix на основе BSD, который в значительной степени написан на C.
  • Системы контроля версий Git и Subversion написаны на C.
  • Все базы данных (Oracle, Postgres, MySQL, IBM Db2, SQL Server — список бесконечен) написаны на C/C++.

Благодаря непревзойденной производительности C/C++ он по-прежнему занимает второе место в списке наиболее предпочтительных языков программирования. (В прошлом году он был №1, но в этом году его заменил Python.)

Тем не менее, именно проблемы с C/C++ заставляли сообщество программистов искать следующий язык программирования-панацеи.

Проблема с С/С++

Основная проблема C/C++ — драконовский синтаксис. Это крутая кривая обучения. Это приводит к огромному техническому долгу, встроенному в гигантскую кодовую базу. Даже опытные программисты опасаются рефакторинга таких кодов.

Уродливый синтаксис C/C++ приводит к крутой кривой обучения, создавая огромный технический долг, который создает порочный круг.

Когда синтаксический анализ языка не интуитивно понятен, разработка поддерживающих его инструментов затруднена. Поддержка IDE, главного оружия новичка против языка программирования, для C/C++ минимальна из-за его синтаксиса. Microsoft Visual Studio долгое время господствовала в этом пространстве, но была частной. Конкуренция также не может предложить многого с точки зрения экономической эффективности или возможностей.

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

  1. Крутая кривая обучения
  2. Меньше любви разработчиков
  3. Технический долг

В двух словах:

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

Программисты не хотят ставить себя в положение выбора между производительностью и простотой. Почему они не могут иметь оба?

Есть два способа добиться этого:

  • Улучшить С/С++
  • Создать новый язык, в котором отсутствует управление памятью, но который по производительности не уступает C/C++ (следовательно, совместим с C/C++ из-за большой существующей кодовой базы).

Потом был Раст.

Чистота часто не является причиной, по которой компании хотят заменить уродливую вещь. Пока он приносит деньги, он остается, несмотря на свои подводные камни.

Microsoft, как обычно, первой сопоставила уродство C/C++ с уменьшающейся прибылью.

По состоянию на 2004 год ошибки, связанные с памятью, обходятся отрасли примерно в 250 000 долларов каждая.

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

В C/C++, несмотря на его долгую историю развития, это неизбежно.

Согласно самой консервативной оценке Microsoft, датированной еще 2004 годом, ошибки, связанные с памятью, обходятся отрасли примерно в 250 000 долларов каждая. В результате Microsoft активно начала переводить большую часть своего критически важного кода с C/C++ на Rust.

Запущенный Mozilla в 2010 году, Rust имеет крупнейших сторонников во всех ведущих технологических компаниях: Microsoft, Amazon, Google, Facebook и Apple.

AWS также запускает свой код развертывания лямбда-функций с использованием Rust. Facebook тоже использует Rust.

Google планировал использовать Rust в ядре Linux, на котором работает Android.

Carbon от Google имеет сильное синтаксическое сходство с Rust.

Одна из самых поразительных частей документации, которая привлекла мое внимание, — это раздел:

Any path to safety must preserve performance of C++ today. This rules out garbage collection, and many other options. The only well understood mechanism of achieving safety without giving up performance is compile-time safety. The leading example of how to achieve this is Rust.

Объявляя Carbon, Google не критиковал Rust. Фактически, в какой-то момент в CppNorth Каррут (ведущий разработчик Carbon) посоветовал тем, кто использует Rust, продолжать использовать его.

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

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

Как Google поживает в диаграмме языкового развития

Golang от Google имел успех. Его часто называют самым быстрым языком разработки бэкенда. Он статически типизирован и является одним из самых простых в освоении. С момента своего создания он постоянно поднимался в Индексе популярности TOIBE.

Flutter был не так хорош на iOS, как на Android, что часто сводило на нет его кросс-платформенное существование.

В рамках своей кроссплатформенной инициативы Flutter Google придумала Dart. Опираясь на огромную поддержку сообщества, он получил более быстрое распространение. Тем не менее, некоторые из заявлений о производительности Flutter не оправдались после первоначальной эйфории. В первом выпуске Dart долгое время отсутствовали базовые функции, такие как хеширование — признак дилетантского подхода к созданию языка.

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

Несмотря на то, что его приняли крупные компании, Dart так и не стал тяжеловесным вилочным погрузчиком, каким Google его рекламировал, а Flutter оставался усилиями сообщества в соответствии с React Native — детищем собрата Google по рекламной платформе, которому суждено быстрее создавать кроссплатформенные приложения для себя, привлекая сообщество. -развитые элементы управления.

Зачем был создан Google Carbon?

Некоторые могут подумать, что разработка Carbon идет по той же траектории, что и Dart, из-за его чрезмерной зависимости от сообщества.

Однако нет причин для пессимизма в отношении Carbon.

Здесь цель Google коренится в развитии C++ — задача, которая стала тернистой из-за чрезвычайно бюрократической эволюции самого архаичного в мире языка прикладного уровня.

Для достижения этой цели Google сделал Carbon открытым на раннем этапе разработки (1.0 ожидается в 2024–2025 годах). Google также взял за правило, чтобы ни одна организация не вносила более 50% в искоренение монополистического захвата.

Вот выдержка из Readme от Carbon на GitHub:

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

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

В двух словах:

  • Google признает непревзойденную производительность C/C++ и большую кодовую базу
  • Компания признает, что создала огромный технический долг, неприемлемый для отрасли в целом.
  • Трудно улучшить C++ из-за бюрократического характера (возможно, вызывающего конфликты) изменений в стандартах C++. Хотя Google не уточняет, что здесь имеется в виду, не стесняйтесь дополнять примерами, если они у вас есть.

Итак, новый язык.

Может ли Google Carbon Power осуществлять кроссплатформенную мобильную разработку на основе C++?

Кроссплатформенная разработка на C++ — это вещь.

Впервые он был представлен Dropbox, когда он представил свой Джинни на Конференции CppCon 2014.

Djinni — это генератор кода, который принимает IDL (язык определения интерфейса) в качестве входных данных и создает скелеты классов C++, совместимые с Objective C и Java.

IDL — это не что иное, как заголовочный файл, эквивалентный C++, или интерфейс класса, эквивалентный Java.

Сгенерированный код (файлы .cpp и .hpp) известен как привязка платформы C++. Его можно использовать как общую бизнес-логику ниже нативных уровней (Objective C+Swift или Java+Kotlin).

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

Не будет ошибкой предположить, что Google Carbon стремится заменить C++ в этой области.

Возможности Google Carbon

Вернемся к документам. Исходя из своих целей высокого уровня, Carbon поддерживает:

  • Дженерики и шаблоны
  • Кортежи
  • Совместимость с существующим кодом C++ и миграция из него (перевод исходного кода для идиоматического кода C++)
  • Та же модель памяти, что и в C++ (объем памяти объекта в Carbon будет таким же, как в C++)

Углерод не будет стремиться:

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

Культура ест стратегию на завтрак.

Понятно, что помимо раскрытия целей дизайна, Google очень мало насторожил, прежде чем выпустить багажник. Репо вполне живое. Когда я пишу эту статью в субботу вечером по восточноевропейскому летнему времени, кто-то (если не какой-то бот-релиз) внес изменения всего 14 минут назад:

Как начать работу с Google Carbon

# Install bazelisk using Homebrew.
$ brew install bazelisk

# Install Clang/LLVM using Homebrew.
# Many Clang/LLVM releases aren't built with options we rely on.
$ brew install llvm
$ export PATH="$(brew --prefix llvm)/bin:${PATH}"

# Download Carbon's code.
$ git clone https://github.com/carbon-language/carbon-lang
$ cd carbon-lang

# Build and run the explorer.
$ bazel run //explorer -- ./explorer/testdata/print/format_only.carbon

исследователь углерода Google

Google Carbon explorer — это валидатор, который может отслеживать изменения дизайна в спецификации языка Carbon. Он реализован как интерпретатор языка, а не как компилятор.

Согласно GitHub:

Это реализация Carbon, основная цель которой — действовать как четкая спецификация языка. В дополнение к этой цели его также можно использовать в качестве платформы для прототипирования и проверки изменений в языке.

Как играть с Google Carbon, не устанавливая его?

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

Заключение

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

Углерод питает планету. Надо отдать ему должное. Это также время, когда мы позволяем ему отдохнуть.

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

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

Было бы желательно, чтобы сообщество программистов восприняло Google Carbon с контролируемым энтузиазмом и прагматичными вложениями времени и денег, учитывая, что это довольно ранний цикл разработки.

В любом случае, это попытка в правильном направлении. Видя, как прочный, старый язык программирования превращается во что-то современное и публично созданное известной командой, сообщество программистов только выигрывает.