Подсветка нужна чтобы взглянув на 1 выражение быстро найти ВСЕ части выражения.
Отдельно для каждого выражения.
Функции в целом или даже файлы подсветкой не определяются. Для этого используют форматирование и отступы.
В рамках одного выражения до 7 цветов нормально, так как их смысл не в том, чтобы быстро по цвету находить что-то (например, строку), а чтобы цвета помогли мозгу быстро разбить выражение на части. Отделить разные части callchain, аргументы от имени функции, await от const и так далее.
И у вас там еще одна ошибка - слишком светлый фон.
Около 20 лет назад еще писал на PHP сайт (softodrom) и свою CMS для него, которая собирала страницу и кэшировала ее в memcached вместе с некоторыми метаданными, такие как параметры запроса и внутренние связи между данными.
Например, на странице мог быть блок с данными, которые обновляются по крону или через админку, страница знает какие данные на ней присутствуют и пересобирает себя если обновилось что-то из них, но не весь контент, а только эту часть. Там так же используется свой шаблонизатор, он строит что-то типа AST, кэширует его и пересобирает только ту часть, которая изменилась.
Профилировал весь движок так, чтобы он работал практически мгновенно, еще пришлось Linux + KDE установить, потому что Flamegraph красиво отображать тогда умело только что-то под KDE :)
Были планы еще переписать движок как расширение на PHP, но уже не стал.
В C++ нет полноценного “async/await” как законченной модели исполнения. Есть низкоуровневые корутины (co_await/co_yield) - синтаксический сахар без Future/Executor/IO-рантайма, которое нужно всё написать самому, там же и настраивается поведение в каком потоке проснется код после co_await, но тут даже по имени видно "co_await" != "await", о чём я и говорил. Я не утверждал, что в C++ нет ничего похожего по поведению на .await в Rust.
И в любом случае, даже в C++ корутины в продакшене плохо - они делают код некрасивым, сложным, медленным (без шаманств). И даже с этими всеми недостатками гибкость C++ выше на голову.
В С++ fetch выведет одинаковые thread_id если запустить вот так:
asio::io_context io;
auto ex = asio::make_strand(io);
co_spawn(ex, fetch(), detached);
io.run();
В C++ вообще мьютексы на общие данные внутри корутин использовать не очень хорошо, будут проблемы, но тем не менее это можно сделать корректно, например, организовав шардинг задач по id (если вся работа с локами только внутри корутин) или используя await-able мьютексы.
Выстрелить себе в ногу - это больше про интеллект, чем про ограничения и возможности языка. Тот же нож в руках у идиота тоже может делов натворить и что, из-за пары идиотов делать все ножи тупыми?
await на JS не меняет поток :) await в C++ нет. И да, я предпочитаю когда я точно знаю какой поток что выполняет, а не рандом.
Ради эксперимента можем посоревноваться, я пишу на C++, а вы на Rust и сравниваем скорость разработки, быстродействие программы, безопасность, архитектуру, простоту поддержки и красоту кода. C++ сделает Rust.
Хороший паттерн блокировок в C++ - scoped_lock, unique_lock, никто уже давно не лочит мьютексы сам. Приходится захватывать мьютекс в одном месте, а освобождать в другом = архитектура кусок говно. Раньше я и без них не делал так, чтобы лок / анлок был в разных функциях
Только взглянул на ваш код на TS сразу увидел проблему. С таким сталкивался еще в школе 25 лет назад…
Пример на Rust как раз показывает всю ущербность Rust. Сам себе создал проблему на ровном месте (await, отсутствие контроля за потоками), сам ее нашел еще и в другом месте и героически не дал собрать проект.
Напомнило C++ 2000-х годов, где сообщение об ошибке ссылалось на что угодно, только не на строку с проблемой.
На C++ за десятилетия программирования я ни разу не столкнулся с ошибкой что освободил мьютекс из другого потока…
Дедлоки - да, но они и в расте могут быть.
И за этим всем на самом деле скрывается некачественная архитектура проекта. Блокировать мьютекс надо только на составление запроса, но не на выполнение (с оговорками на случай больших транзакций с откатами).
На нашем сервере я сделал несколько перехватчиков scoped_lock, unique_lock и т.д. + некий measure_scope.
Все данные с номерами строк и именами файлов записываются в tbb::concurrent_queue и в отдельных потоках сохраняются в ClickHouse.
Оверхед ~0, точность идеальная, вплоть до отдельных строк кода, отдельно по блокировкам - видно сколько времени блокировка ожидалась, сколько держалась, количества вызовов и так далее.
Миллиарды записанных событий, данные в ClickHouse занимают до сотни гигабайт. Строятся гистограммы распределения времени, считаются экстремумы.
Визуализация в datalens, можно настраивать так же алерты, подключать ИИ к анализу.
А файлы… Если вы такое всерьез рассматривали в 2025 году, то забудьте про ИТ и идите пасти коров, что-ли…
Зачем? Как это делать написано уже 100 раз до меня, просто возьмите архитектуру любого http сервера, например, nginx. STL + pthreads + OpenSSL + libev + Intel TBB + libfmt + rapidjson - основа.
Для бинарного протокола используем ULEB-кодирование и свой формат описания пакетов.
Парсер HTTP свой, для API-сервера не нужна полная поддержка протокола.
SSL проксирование через CloudFlare или через nginx, он же может и корректность протокола проверять.
У нас на этом написано несколько бэкэндов онлайн-игр, API-сервера для аналитики, различные сервисы.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
БД ClickHouse + MySQL, адаптер самописный.
Я так же написал свое расширение для ClickHouse для PHP (оно открытое), которое работает с ним по нативному протоколу и тоже базовая часть заняла около суток, остальное время уже реализация дополнительного функционала.
Как люди извращаются, чтобы решить проблемы, которые сами же и выбрали. Хотите я ускорю ваши C++ вызовы в 1000 раз? Просто. Используйте. C++.
И не надо мне писать про преимущества Go, современный C++ такой же безопасный и на нем так же быстро решаются продуктовые задачи как и на Go, при том что он часто быстрее и гораздо более универсальный и мощный.
Странно, на такое 2 недели… На C++ давно уже пишем гораздо более сложные вещи за день примерно. Без проблем с производительностью, WS/бинарный протокол/rest. Без явного выделения памяти, RAII и так далее. Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун.
Фактически - всё, нет, ВСЁ, что вы описали - как раз признак ТУПОСТИ. Вы описали костыли для инвалидов (умственных). Умный человек как раз всё это сделает сам, чекпоинты, дедлайны, бизнес-ценность, даже задачу сделает не так, как ее поставили, а так, как это на самом деле нужно бизнесу.
Так работают нормальные программисты. Им не нужны лиды, ТЗ… Достаточно описать идею и дальше вы получите работающий бизнес-продукт.
Это все сложно и непонятно. У меня было всё гораздо проще - я программирую с 9 лет (мне 39) и я всегда считал, что программирую лучше всех (и за годы жизни не встречал лично людей, которые программируют лучше). И я знал почти всё всегда лучше других и всегда спорил до победного отстаивая свою точку зрения даже если меня о ней никто не спрашивал. Я создавал целые теории и философию чтобы доказать, что я прав. И да, были моменты, где мне доказывали, что я не прав и я на них учился. Это лучшее обучение, что есть в мире. А еще я читал очень много книг по программированию, управлению людьми, проектами, рефакторинг, математика, гейм-дизайн, маркетинг, аналитика и так далее. И читал я потому что мне было интересно.
Прошел 2 полноценных MBA (1 на 2 года зарубежный и второй на 1 год, наш), германский курс по PMBook и еще кучу мелких и тоже просто потому что было интересно, мне было плевать на развитие как таковое всегда.
Для меня любая новая тема и тем более та, в которой я еще не разбираюсь - вызов и соревнование, где я должен за очень мало времени стать лучшим, показать всем как надо учиться и потом делать.
Среднее выполнение задач у меня в 3-5 раз меньше, чем даже у Сеньоров. А если говорить про бизнес, то у окружающих вообще мрак.
Так что не мучайте себя, забейте, вы все всё-равно выше головы не прыгнете, у вас не хватит мозгов. Или докажите, что я не прав. :)
Кстати, заметил, что нормальные книги по программированию пишут только зарубежные авторы… А я их очень много прочитал.
По бизнес-направлениям тоже зарубежные авторы на голову выше наших, наши как-будто боятся рассказать самое ценное, что есть, и поэтому книги выходят сухими и бесполезными.
Вы странный. Писать отдельную статью про «обучение». Сам процесс «обучение» выделяют в обособленную сущность только глупые люди. Для меня, например, его отдельно не существует, я просто делаю и это получается. Никаких правил и особенных подходов, просто всё легко. Не сразу получается идеально, но очень быстро становится таковым, но без вот этого всего, что вы написали :)
Я бы сказал, что «обучение» неизбежно, как третий закон Ньютона и скорость этого процесса напрямую и экспоненциально зависит от интеллекта субъекта.
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять? У меня случаи были оптимизации (руками), которые и в 10 000 раз ускоряли запрос (написанный не мной)… Ваш движок не ускорит запросы, написанные мной… Более того, для оптимизации «запросов» я применяю еще методы кэширования данных (те же MATERIALIZED VIEW и временные таблицы), изменение структуры таблиц и формата записи данных, изменения алгоритмов, которые используют эти запросы. Ваш движок такое умеет?
Я считаю, такие оптимизаторы вредными. Они позволяют тем, кто работает с БД быть тупыми…
Линус тут жестко тупанул. Замените Rust на «детскую порнографию» и со азу станет понятно, что всё, что он написал - чушь полнейшая. Я понимаю тех разработчиков, которые говорят, что не хотят иметь никакого отношения к Rust (детской порнографии) и что Rust (детской порнографии) не место в ядре никак и никогда и что у них есть право голоса по поводу любых запретов Rust (детской порнографии)…
Логика стала понятнее? Вот для меня Rust еще хуже, чем детская порнография…
price с клиента в коммерции надо передавать ОБЯЗАТЕЛЬНО, а потом уже проверять на сервере соответствие и возвращать «Цена изменилась», если она изменилась, иначе пользователь откроет форму со старой ценой, будет думать, что покупает за старую цену, и пока он смотрит цена может поменяться и там дальше куча проблем, начиная от заказа с другой ценой, заканчивая списанием другой суммы…
Облако всё-равно это тупо. Облако выходит в 5-10 раз дороже собственных серверов… 14 лет уже этим занимаюсь и ни разу не было такого случая, чтобы облако было чем-то лучше или эффективнее…
Вы неправильно используете подсветку кода.
Подсветка нужна чтобы взглянув на 1 выражение быстро найти ВСЕ части выражения.
Отдельно для каждого выражения.
Функции в целом или даже файлы подсветкой не определяются. Для этого используют форматирование и отступы.
В рамках одного выражения до 7 цветов нормально, так как их смысл не в том, чтобы быстро по цвету находить что-то (например, строку), а чтобы цвета помогли мозгу быстро разбить выражение на части. Отделить разные части callchain, аргументы от имени функции, await от const и так далее.
И у вас там еще одна ошибка - слишком светлый фон.
Около 20 лет назад еще писал на PHP сайт (softodrom) и свою CMS для него, которая собирала страницу и кэшировала ее в memcached вместе с некоторыми метаданными, такие как параметры запроса и внутренние связи между данными.
Например, на странице мог быть блок с данными, которые обновляются по крону или через админку, страница знает какие данные на ней присутствуют и пересобирает себя если обновилось что-то из них, но не весь контент, а только эту часть. Там так же используется свой шаблонизатор, он строит что-то типа AST, кэширует его и пересобирает только ту часть, которая изменилась.
Профилировал весь движок так, чтобы он работал практически мгновенно, еще пришлось Linux + KDE установить, потому что Flamegraph красиво отображать тогда умело только что-то под KDE :)
Были планы еще переписать движок как расширение на PHP, но уже не стал.
В C++ нет полноценного “async/await” как законченной модели исполнения. Есть низкоуровневые корутины (co_await/co_yield) - синтаксический сахар без Future/Executor/IO-рантайма, которое нужно всё написать самому, там же и настраивается поведение в каком потоке проснется код после co_await, но тут даже по имени видно "co_await" != "await", о чём я и говорил.
Я не утверждал, что в C++ нет ничего похожего по поведению на .await в Rust.
И в любом случае, даже в C++ корутины в продакшене плохо - они делают код некрасивым, сложным, медленным (без шаманств). И даже с этими всеми недостатками гибкость C++ выше на голову.
В С++ fetch выведет одинаковые thread_id если запустить вот так:
В C++ вообще мьютексы на общие данные внутри корутин использовать не очень хорошо, будут проблемы, но тем не менее это можно сделать корректно, например, организовав шардинг задач по id (если вся работа с локами только внутри корутин) или используя await-able мьютексы.
Выстрелить себе в ногу - это больше про интеллект, чем про ограничения и возможности языка. Тот же нож в руках у идиота тоже может делов натворить и что, из-за пары идиотов делать все ножи тупыми?
await на JS не меняет поток :) await в C++ нет. И да, я предпочитаю когда я точно знаю какой поток что выполняет, а не рандом.
Ради эксперимента можем посоревноваться, я пишу на C++, а вы на Rust и сравниваем скорость разработки, быстродействие программы, безопасность, архитектуру, простоту поддержки и красоту кода. C++ сделает Rust.
Хороший паттерн блокировок в C++ - scoped_lock, unique_lock, никто уже давно не лочит мьютексы сам. Приходится захватывать мьютекс в одном месте, а освобождать в другом = архитектура кусок говно. Раньше я и без них не делал так, чтобы лок / анлок был в разных функциях
Только взглянул на ваш код на TS сразу увидел проблему. С таким сталкивался еще в школе 25 лет назад…
Пример на Rust как раз показывает всю ущербность Rust. Сам себе создал проблему на ровном месте (await, отсутствие контроля за потоками), сам ее нашел еще и в другом месте и героически не дал собрать проект.
Напомнило C++ 2000-х годов, где сообщение об ошибке ссылалось на что угодно, только не на строку с проблемой.
На C++ за десятилетия программирования я ни разу не столкнулся с ошибкой что освободил мьютекс из другого потока…
Дедлоки - да, но они и в расте могут быть.
И за этим всем на самом деле скрывается некачественная архитектура проекта. Блокировать мьютекс надо только на составление запроса, но не на выполнение (с оговорками на случай больших транзакций с откатами).
Опять странные решения…
На нашем сервере я сделал несколько перехватчиков scoped_lock, unique_lock и т.д. + некий measure_scope.
Все данные с номерами строк и именами файлов записываются в tbb::concurrent_queue и в отдельных потоках сохраняются в ClickHouse.
Оверхед ~0, точность идеальная, вплоть до отдельных строк кода, отдельно по блокировкам - видно сколько времени блокировка ожидалась, сколько держалась, количества вызовов и так далее.
Миллиарды записанных событий, данные в ClickHouse занимают до сотни гигабайт. Строятся гистограммы распределения времени, считаются экстремумы.
Визуализация в datalens, можно настраивать так же алерты, подключать ИИ к анализу.
А файлы… Если вы такое всерьез рассматривали в 2025 году, то забудьте про ИТ и идите пасти коров, что-ли…
Слишком долго и сложно. Я обычно кидаю кусок кода и пишу что-то типа «найди проблему с ресайзом области текста после сокрытия бейджа и исправь»
Зачем? Как это делать написано уже 100 раз до меня, просто возьмите архитектуру любого http сервера, например, nginx. STL + pthreads + OpenSSL + libev + Intel TBB + libfmt + rapidjson - основа.
Для бинарного протокола используем ULEB-кодирование и свой формат описания пакетов.
Парсер HTTP свой, для API-сервера не нужна полная поддержка протокола.
SSL проксирование через CloudFlare или через nginx, он же может и корректность протокола проверять.
У нас на этом написано несколько бэкэндов онлайн-игр, API-сервера для аналитики, различные сервисы.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
БД ClickHouse + MySQL, адаптер самописный.
Я так же написал свое расширение для ClickHouse для PHP (оно открытое), которое работает с ним по нативному протоколу и тоже базовая часть заняла около суток, остальное время уже реализация дополнительного функционала.
У вас что-то не так просто с эффективностью…
Как люди извращаются, чтобы решить проблемы, которые сами же и выбрали. Хотите я ускорю ваши C++ вызовы в 1000 раз? Просто. Используйте. C++.
И не надо мне писать про преимущества Go, современный C++ такой же безопасный и на нем так же быстро решаются продуктовые задачи как и на Go, при том что он часто быстрее и гораздо более универсальный и мощный.
Странно, на такое 2 недели… На C++ давно уже пишем гораздо более сложные вещи за день примерно. Без проблем с производительностью, WS/бинарный протокол/rest. Без явного выделения памяти, RAII и так далее. Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун.
Фактически - всё, нет, ВСЁ, что вы описали - как раз признак ТУПОСТИ. Вы описали костыли для инвалидов (умственных). Умный человек как раз всё это сделает сам, чекпоинты, дедлайны, бизнес-ценность, даже задачу сделает не так, как ее поставили, а так, как это на самом деле нужно бизнесу.
Так работают нормальные программисты. Им не нужны лиды, ТЗ… Достаточно описать идею и дальше вы получите работающий бизнес-продукт.
Вот они, олимпиадники… Код корректный, но ужасный, отвратительный.
Столько таких повидал за время работы, для меня «Призер олимпиады» - красный флаг.
Только детям мозги ломаете :( На 1000 олимпиадников находится только 1, которому это пошло на пользу.
Это все сложно и непонятно. У меня было всё гораздо проще - я программирую с 9 лет (мне 39) и я всегда считал, что программирую лучше всех (и за годы жизни не встречал лично людей, которые программируют лучше). И я знал почти всё всегда лучше других и всегда спорил до победного отстаивая свою точку зрения даже если меня о ней никто не спрашивал. Я создавал целые теории и философию чтобы доказать, что я прав. И да, были моменты, где мне доказывали, что я не прав и я на них учился. Это лучшее обучение, что есть в мире. А еще я читал очень много книг по программированию, управлению людьми, проектами, рефакторинг, математика, гейм-дизайн, маркетинг, аналитика и так далее. И читал я потому что мне было интересно.
Прошел 2 полноценных MBA (1 на 2 года зарубежный и второй на 1 год, наш), германский курс по PMBook и еще кучу мелких и тоже просто потому что было интересно, мне было плевать на развитие как таковое всегда.
Для меня любая новая тема и тем более та, в которой я еще не разбираюсь - вызов и соревнование, где я должен за очень мало времени стать лучшим, показать всем как надо учиться и потом делать.
Среднее выполнение задач у меня в 3-5 раз меньше, чем даже у Сеньоров. А если говорить про бизнес, то у окружающих вообще мрак.
Так что не мучайте себя, забейте, вы все всё-равно выше головы не прыгнете, у вас не хватит мозгов. Или докажите, что я не прав. :)
Кстати, заметил, что нормальные книги по программированию пишут только зарубежные авторы… А я их очень много прочитал.
По бизнес-направлениям тоже зарубежные авторы на голову выше наших, наши как-будто боятся рассказать самое ценное, что есть, и поэтому книги выходят сухими и бесполезными.
Вы странный. Писать отдельную статью про «обучение». Сам процесс «обучение» выделяют в обособленную сущность только глупые люди. Для меня, например, его отдельно не существует, я просто делаю и это получается. Никаких правил и особенных подходов, просто всё легко. Не сразу получается идеально, но очень быстро становится таковым, но без вот этого всего, что вы написали :)
Я бы сказал, что «обучение» неизбежно, как третий закон Ньютона и скорость этого процесса напрямую и экспоненциально зависит от интеллекта субъекта.
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять? У меня случаи были оптимизации (руками), которые и в 10 000 раз ускоряли запрос (написанный не мной)… Ваш движок не ускорит запросы, написанные мной… Более того, для оптимизации «запросов» я применяю еще методы кэширования данных (те же MATERIALIZED VIEW и временные таблицы), изменение структуры таблиц и формата записи данных, изменения алгоритмов, которые используют эти запросы. Ваш движок такое умеет?
Я считаю, такие оптимизаторы вредными. Они позволяют тем, кто работает с БД быть тупыми…
И вы не показали еще запросы с JOIN-ами, в ClickHouse их надо писать по особому, чтобы было быстро
У меня 30 лет опыта разработки и из них 20 коммерческого, если я накручу 2-3 года, то никто не заметит :)
Линус тут жестко тупанул. Замените Rust на «детскую порнографию» и со азу станет понятно, что всё, что он написал - чушь полнейшая. Я понимаю тех разработчиков, которые говорят, что не хотят иметь никакого отношения к Rust (детской порнографии) и что Rust (детской порнографии) не место в ядре никак и никогда и что у них есть право голоса по поводу любых запретов Rust (детской порнографии)…
Логика стала понятнее? Вот для меня Rust еще хуже, чем детская порнография…
Очередные советы, которые делают только хуже :)
price с клиента в коммерции надо передавать ОБЯЗАТЕЛЬНО, а потом уже проверять на сервере соответствие и возвращать «Цена изменилась», если она изменилась, иначе пользователь откроет форму со старой ценой, будет думать, что покупает за старую цену, и пока он смотрит цена может поменяться и там дальше куча проблем, начиная от заказа с другой ценой, заканчивая списанием другой суммы…
Облако всё-равно это тупо. Облако выходит в 5-10 раз дороже собственных серверов… 14 лет уже этим занимаюсь и ни разу не было такого случая, чтобы облако было чем-то лучше или эффективнее…