Почему Линус Торвальдс отказывается от C++ в ядре Linux: разбор аргументов

Линус Торвальдс и его отказ от C++ для ядра Linux

Линус Торвальдс, создатель Linux и «великодушный диктатор» проекта, известен своей критикой языка C++. Он не отвергает его просто так — он приводит убедительные технические и практические аргументы против его применения в ядре Linux.

В чем же причина неприятия C++? Давайте разберем ключевые доводы Линуса.

Почему C++ не подходит для ядра Linux

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

1. Обработка исключений

«Вся обработка исключений в C++ фундаментально сломана, особенно для ядра»

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

• Исключения трудно отлаживать;

• Они меняют парадигму обработки ошибок;

• Могут привести к нестабильности ядра.

Для пользовательских приложений вроде GNOME редактора это мелочь, но для ядра Linux — реальный риск.

2. Управление памятью и RAII

«Любой язык, который выделяет память за вашей спиной, не подходит для ядра»

C++ использует RAII (Resource Acquisition Is Initialization), автоматическое управление ресурсами через деструкторы. В ядре Linux память контролируется тонко и вручную, чтобы обеспечить максимальную производительность. Автоматизация в C++:

• Увеличивает зависимость от компилятора;

• Может снижать скорость работы модулей;

• Увеличивает вероятность багов.

3. Объектно-ориентированное программирование

«Вы можете писать объектно-ориентированный код на C без всей этой *** чуши C++»

Линус считает, что ООП полезно, но C++ вносит слишком много лишнего. ООП можно реализовать и на чистом C через структуры и функции. Пример «класса» на C:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    int value;
    void (*increment)(struct Person *self);
} Person;

void increment_person(Person *self) {
    self->value++;
}

Person* person_new(int initial_value) {
    Person *p = (Person*)malloc(sizeof(Person));
    p->value = initial_value;
    p->increment = increment_person;
    return p;
}

void person_free(Person *p) {
    free(p);
}

int main() {
    Person *p = person_new(5);
    printf("Initial value: %d\n", p->value);
    p->increment(p);
    printf("After increment: %d\n", p->value);
    person_free(p);
    return 0;
}

Это доказывает, что функциональность ООП доступна и в чистом C.

4. Стабильность библиотек и зависимостей

«STL и Boost для ядра — это боль и нестабильность»

Пользовательские библиотеки вроде STL или Boost могут быть стабильными для приложений, но не для ядра. Любая новая зависимость:

• Увеличивает риски безопасности;

• Требует поддержки и обновлений;

• Может снизить производительность.

Пример — уязвимость CVE-2024–3094 в liblzma, когда сторонний бэкдор повлиял на безопасность.

5. Сложные абстракции

«Неэффективные абстракции через два года могут разрушить весь код»

ОП-паттерны могут быть удобны для приложений, но в ядре Linux они опасны:

• Большие иерархии классов трудно поддерживать;

• Ошибки в логике абстракций могут разрушить архитектуру;

• Потребуется переработка больших частей кода.

Итог: почему ядро Linux на чистом C

«Единственный способ сделать хороший, эффективный и портируемый код — ограничиться тем, что доступно на C»

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

Использование чистого C привлекает разработчиков, сосредоточенных на аппаратных и системных задачах, а не на сложностях ООП.

Будущее: Rust, Go или Java?

Линус открыто обсуждал Rust для ядра. Вопросы применения Go, Java или C# повторяют дискуссию о C++. Основной принцип остается прежним: ядро должно оставаться максимально стабильным и оптимизированным.

«Вы хотите, чтобы ядро МРТ выбрасывало исключения?» — юмор Линуса иллюстрирует риск внедрения непредсказуемого кода в критически важные системы.

Выводы для разработчиков

1. Выбор языка и инструментов влияет на стабильность и производительность;

2. Любые зависимости требуют оценки долгосрочных последствий;

3. Иногда простота C — лучший выбор для системного программирования;

4. Разработчики должны балансировать эргономику и стабильность, особенно в критичных проектах.

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