Как пришел в разработку?

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

Мой путь, если по пунктам, был примерно такой, бля:

1. Универские проекты. Начиналось всё с классики — писал свои велосипеды, эти самые алгоритмы и структуры данных. Свои аналоги контейнеров из STL клепал, в аллокаторы заглядывал, чтобы понять, откуда память берётся. Бывало, сидишь, ебать копать, над какой-нибудь самописной vector и думаешь: «Ну и хитрая жопа эта вся адресация». Но зато потом понимаешь, как оно внутри работает — доверия к стандартной библиотеке сразу овердохуища.

2. Первая работа. Вышел в мир, и сразу в самое пекло — драйверы писать и low-level компоненты для всяких embedded систем. Тут уже не до шуток, чувак. Ошибёшься — и устройство превращается в кирпич. Зато какой кайф, когда после трёх дней дебага твой драйвер наконец-то оживает и начинает общаться с железкой. Чувствуешь себя почти богом, только в потёртой футболке и с кружкой холодного кофе.

3. Чем сейчас занимаюсь. Перешёл на высоконагруженные backend-системы. Тут уже масштабы другие, и требования к производительности и надёжности — просто пиздец. Каждый цикл процессора на счету, каждая наносекунда задержки — уже проблема. Но это и есть тот самый драйв, ради которого всё затевалось.

Вот тебе пример задачи, которая меня реально зацепила. Сидел я на одном проекте, и там нужно было сетевые пакеты обрабатывать так, чтобы не бутылочное горлышко было. Исходник, конечно, был написан на коленке: std::vector, постоянное копирование данных туда-сюда — в общем, тормозило всё, как черепаха в сиропе. Подозрение ёбать чувствую — ну не может же быть, чтобы быстрее нельзя!

И родилось у меня решение — кольцевой буфер без блокировок, с zero-copy подходом. Чтобы данные просто передавались по указателю, без лишних телодвижений. Сидел, думал над моделью памяти, чтобы не было гонок... Э, бошка, думай! В итоге родился такой класс:

class LockFreeRingBuffer {
public:
    LockFreeRingBuffer(size_t capacity) 
        : buffer_(new std::atomic<Packet*>[capacity]), capacity_(capacity) {}

    bool try_push(Packet* packet) {
        size_t current_tail = tail_.load(std::memory_order_relaxed);
        size_t next_tail = (current_tail + 1) % capacity_;

        if (next_tail == head_.load(std::memory_order_acquire)) {
            return false; // Буфер полон
        }

        buffer_[current_tail].store(packet, std::memory_order_release);
        tail_.store(next_tail, std::memory_order_release);
        return true;
    }

    Packet* try_pop() {
        size_t current_head = head_.load(std::memory_order_relaxed);
        if (current_head == tail_.load(std::memory_order_acquire)) {
            return nullptr; // Буфер пуст
        }

        Packet* packet = buffer_[current_head].load(std::memory_order_acquire);
        head_.store((current_head + 1) % capacity_, std::memory_order_release);
        return packet;
    }

private:
    std::unique_ptr<std::atomic<Packet*>[]> buffer_;
    std::atomic<size_t> head_{0}, tail_{0};
    size_t capacity_;
};

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