Comments 67
Почему третий пункт приписан, как killer-feature раста? Он, конечно, хорошо туда собирается, но плюсы и go тоже умеют в wasm. И у всех трех есть zerodep embedded рантаймы для запуска модулей по типу wasmi, wasm3, wazero.
Автор зашел вчера на Хабр, запостил 4 сгенерённые LLM статьи, и... дальше что?
Если сгенерировал, то хотелось бы знать чем было сгенерировано вот это:
Вот алгоритм, который позволит вам спать спокойно, используя GPT-5:
Декомпозируйте задачу. Разбейте её на мелкие, атомарные части.
Пишите детальные промпты. Представьте, что пишете ТЗ для джуниора, который склонен делать именно то, что ему сказано, и не более.
Генерируйте код небольшими порциями. Не целый модуль, а одну функцию, один класс, один метод.
Проверяйте ВСЁ. Линтеры, тесты, внимательный код-ревью. Никаких исключений.
Рефакторите и интегрируйте. Вставьте проверенный код в свою кодобазу, приведите к своим стандартам.
Очень неплохо на мой взгляд. Сам(а) GPT-5 дает советы как строить ракботу с ней (ним)?
Не согласен. На мой взгляд, плохо и низкокалорийно. Ну давайте по пунктам.
Редукционизм изобрели в пятом веке до нашей эры. Тоже мне откровение. Совет понятный, но очевидный. Куда полезнее очертить оптимальный объём работы для каждого промпта. Сколько оптимально токенов должно быть в вводе и выводе? Человек с опытом немедленно покажет примеры, большая языковая модель будет давать общие указания.
Писать детальный промпт — самый хороший совет. Я бы разве что рекомендовал представлять не младшего разработчика, а дьявола, который будет делать всё наоборот (вразрез с вашими ожиданиями), если вы не оговорили обратное. Для начала нужно задуматься, какие из ваших ожиданий остаются невысказанными и, собственно, высказать эти ожидания.
См. пункт 1.
Проверять вывод БЯМ — тоже неплохой совет. Обратите внимание, что он опять дан словами Капитана Очевидность, без примеров из практики.
См. пункт 4.
Итого пять советов, из которых в реальности будет три. И все даются максимально общими словами.
Именно так пишут дешёвые языковые модели: мало смысла, слов избыток. Модель не назову, но не думаю, что здесь бесплатный тариф. Думаю, БЯМ была без reasoning.
Осталось 2 статьи. И автора отправляли в read-only. Администрация бдит!
Тут похоливарить можно только на тему осознанности выбора, потому что судя по приведенным плюсам и минусам она где-то не с нами
Автор провокатор и выдумщик.
Вопросы:
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
"переписать самые горячие пути" - а интегрировать как? Есть много тонкостей.
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?
Где цифры, Билли?!
З.Ы. Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой?
в старой системе из коробки Map<Long, Long> а в новой open addressing на примитивах)
То есть, переписать всё оказалось проще, чем оптимизировать Map[Long, Long]?
Ключевое слово тут «переписать», переписывание с джавы на джаву даст тот же эффект) при условии конечно что разрабы не совсем валенки и хотя бы примерно представляют во что компиляется и как исполняется их поделие. Исключение - ультралоулатенси которое на гц физически невозможно сделать, но судя по паузам в 300мс тут был не тот случай (если он вообще был)
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
Когда затраты на инфраструктуру превышают зарплату нескольких мидлов, то могли и разрешить.
Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Раст очень гибок в плане представления. Я до сих пор натыкаюсь на свой собственный код 1-2 летней давности с mut и match на Optional, хотя через полгода интенсивного литкода освоил кучу идиом, которые приближают код к идеалу на хаскеле.
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?
Ну любой нативный язык по памяти уделает Java в десятки раз, если не в сотню. Поэтому я даже удивлен почему только в 5 раз стало меньше. У меня сейчас сервис на плюсах, и под нагрузкой он отъедает 50МБ оперативы. До этого он был написан на Java и умудрялся выжирать со временем всю свободную оперативу сервера, что мы только не делали с ним и как только его не дебажили. Но потом пришла сертификация и нам сказали писать нативно на плюсах. Теперь мы довольны результатом.
Ну любой нативный язык по памяти уделает Java в десятки раз, если не в сотню.
Берите выше, как минимум в тысячу, всем известно что джава вообще меньше чем на терабайте оперативы не запускается) инт в джаве занимает как минимум 400 байт, а в военное время может даже 1000
что мы только не делали с ним и как только его не дебажили
Вот из этой истории получилась бы хорошая статья на хабр)
Хотелось бы увидеть какие-нибудь картинки с тестами, что ли. А то написать сейчас так можно про что угодно:)
В топе бенчмарков techempower стабильно фреймворки на Rust, C и C++, иногда NodeJS.
Для разработки лучше может оказаться использовать не топ-3 фреймворки (поскольку они подгоняются под тесты соревнования), и в процессе вполне можно написать глубоко неоптимальный тормозной код, но некоторые языки просто удобнее для написания высокопроизводительного кода, чем другие (за счёт отказа от виртуальной машины, сборщика мусора и прочих вещей, которые облегчают жизнь разработчикам, но не потребителям).
На задачах компании ТСа рейтинг языков и фреймворков может быть другой, разумеется (на скриншоте - просто RPS статичной страницы).
Покликал по разным вкладкам на страничке этого проекта, там худший результат у джавы 80% от топа (в каких то тестах при этом 99,9)
эти тесты не имеют никакого отношения к реальной жизни - вы хоть раз видели чтобы кто-то использовал эти макетные http сервера? по сути они тестируют качество реализации socket api и не более тк внутри примитивный парсинг http 1.1 (уверен что http2 или 3 никто из первой сотни не поддерживает) - и не полный, а только того, что нужно для этих простых тестов. в принципе проскакивала инфа, что в java под линукс все еще нет нормального асинхронного IO апи, раньше в нем просто не было необходимости пока не появились виртуальные потоки, наверно этим объясняется разница этого теста, на сколько помню они ж засыпают сервак конкурентными запросами и по сути больше ничего не тестируют.
в java под линукс все еще нет нормального асинхронного IO апи
раньше те кому это было нужно просто делали такой апи, в томкетике например есть реализация, в одноклассниках есть one-nio, так что это не блокер)
С одной стороны, хочется с вами согласиться. С другой стороны, на скриншоте выше, на седьмой позиции, стоит axum, который и h2 поддерживает, и в проде встречается. Чтобы далеко не ходить: https://github.com/rust-lang/crates.io
У нас в компании Java (SpringBoot) пока всё равно остается на первом месте просто потому что вся экосистема на это завязана - генераторы кода и прочее - ну и компетенции разработчиков тоже. Однако, самые высоконагруженные сервисы потихоньку переезжают на Go. Лично меня это пока не коснулось, но в планы аттестаций MSA разрабов Go уже залетел как обязательный пункт.
в минусах С++ - специалист
а типо на на расте и го не нужен специалист?
Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Поднять еще нод, не вариант?
Судя, по 200-300ms пауз в пике, сервис наоборот надо было разрезать на более мелкие кучи и запустить с нормальным современным GC.
Если там уже затраты на инфру исчислялись зарплатами мидлов, то ответ очевиден.
очень наивно, т.е. нужно потратить условно не один человеко год сеньоров, менеджера, еще неопределенное время qa не реализовав ни одной новой фичи при этом, никакой новой ценности для клиентов чтоб сэкономить сколько? тысячу уе в месяц тратя при этом минимум 6 (это если мы захантим еще самых скромных, фактически мидлов, и это без налогов и прочих расходов) на протяжении нескольких лет? Плюс java еще в том, что ее очень легко профилировать и мониторить, лично я уверен что можно малыми силами в любом проекте закрыть главные проблемы в производительности на уровне вашего приложения. Все остальное не про джаву это или желание моментального старта без лишних усилий или потребление памяти на уровне 20 мб, а не 200 + 20*3 мб, при этом получая 20 мб и быстрый старт вы лишаетесь абсолютно всех фичей java и spring, ибо им нет нормальных аналогов в go-rust-c++. а go кстати еще и довольно странный, как только дело доходит до числодробилок, то он пригрывает java, и еще интересно будет посмотреть расклады через пару лет когда в java завезут value типы - виртуальная машина конечно останется, но памяти станет кушаться наверно в пару раз меньше.
А почему не рассматривался C# ?
Современный .NET позволяет даже работать напрямую с памятью с нулевым оверхедом.
нам джавистам не очень понятно о чем вы, если что в java сто лет как можно работать с памятью без оверхеда, это и так называемый off heap которым балуются кэши, базы на java типа кассандры. На мелком уровне есть библиотеки где коллекции реализованы уже под конкретные типы. Ну а терпеливые ждут value типы когда Map<Long, Long> наконец станет работать как на примитивах - пилят 10 лет, 8 прототипов, но наконец появился свет в конце туннеля.
На самом деле хотелось бы увидеть примеров: контроллера, ORM и обращений в БД, легирования (желательно сквозного там c OTel и Jaeger), юнитов под это добро написанных и тд, DI особенно после Spring-экосистемы.
При том я к Rust’у отношусь крайней положительно, но ни разу не видел продовый код на нем, а очень хотелось бы.
UPD: дописал про DI
Вот кстати с логировагием и телеметрией есть tracing, он нас устраивал до определённого момента, но начал бесить своей не гибкостью и мы приняли решение на fastrace переезжать.
Про fastrace не слышал, спасибо, запишем.
да фаст штуки можно хоть на С++ написать и будет быстро, вот интересно если сравнивать 2 бвх дерева на раст и С++, кто быстрее кастует в обьект, я клоню к тому, что процесс может быть в дереве, и можно отсекать всё что не связано с запросом
я просто почитал про фаст трейс и подумал про бвх
тоесть если упростить вопрос чей рейтрейс быстрее раста или С или С++
У меня такой есть, не большой, но деньгами ворочает. Работает стабильно и эффективно по памяти. И главное - я могу ему доверять, компилятор и механизмы паттерн-метчинга гарантируют мне что неожиданностей не будет. Для финтеха очень важно.
В нынешней реальности надо ещё анализировать качество перегонки кода туда сюда LLMками
Забавно, что мы со скалы на rust переписали сервис и примерно такие же порядки цифр по памяти и процессору получили. Ну и в результате там теперь 8 подов, а не 32.
Пример кода в студию, пожалуйста
так скала не про перформанс ;) она ощутимо проигрывает java, на столько, что ее частенько решают гонять на graalvm (даже платный) ибо он хорошо умеет оптимизировать ее оверхед. ну и хотелось бы больше специфики что там у вас и во что был упор. ну и как я понимаю код на rust все равно не такой высокоуровневый по итогу...
Скорость работы это хорошо, а скорость стабильной работы сравнивали? А то вот убунтоводы тоже на ржавом переписали gnu coreutils и сразу начали огребать: https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself
Haskell не хватает в списке ;)
раст хороший язык, сейчас многие переходят на него наверное
Открою секрет: на си еще быстрее будет) просто надо его не напрямую через хттп использовать
херня какая-то
известны проблемы стандартного net/http в Го, именно потому если важна скорость или распределенность то есть куча других пакетов которые дышат в затылок найтивкам на си и раст
В Го есть встраиваение, сетевой уровень вы могли бы написать на Си и встроить, а уже на го работать с самими данными
За WASM просто смешно, на этот моменте я начал думать о том что это написано нейронкой. При чем тут вообще WASM? Единое что - сторонние модули которые подключаются на нем. Это удобно но это тонкое место для таких высоконагруженных систем, оптимальнее разбить на микросервисы если у вас там монолит с модулями.
UPD
к слову про тонкие моменты - есть абсолютно рабочий способ добиваться великого даже на net/http - шардирование.
на одном инстансе поднимаем сразу десяток одинаковых серверов которые написаны по принципу шарда и имеют общую память в том же редисе. настраиваем nginx как балансировщик (он может) что бы раскидывал запросы между этими 10 шардами и вуаля
Не существует идеального языка, кроме c++ конечно же
Щас бы но сравнивать с раст или плюсами... Го такой же, как условный с# или джава. Только со своим обрыганным синтаксисом, меньшим количеством либами и хуже комьюнити. Быстроты в нем нет, если сравнивать с плюсами или растом. Да даже нет преимущества в быстроте с тем же с# или джава
Может надо было распилить монолит для начала? И на самом деле интересно какая предметная область? Если телеком, ну может быть в каких то случаях rust, но для обычного энтерпрайза мне кажется перебор
Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.
Не особо в теме, но разве go/cpp не может?
Предположу что любой компилируемый язык использующий llvm как бекенд имеет тулчейн для компиляции в wasm
Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.
Эммм и с++ и go также умеют в wasm, каким образом это стало киллер фичей?
Автор, ну Вы бы хоть указали сколько строк кода в старом монолите, больше/меньше 1млн ?
C++23: старый добрый друг с новыми трюками
Модули наконец-то работают как надо
Подключить библиотеку std можно только в MSVC. Модули только для своего проекта - так себе.
Coroutines в стандартной библиотеке
std::generator только если. Корутины есть в языке в виде co_await/co_yield/co_return, а дальше надо брать какую-то стороннюю библиотеку, типа cppcoro или Boost::ASIO.
До сих пор нет нормальной системы пакетов (хотя vcpkg и Conan спасают)
cmake с FetchContent или сразу CPM.cmake.
Нужны очень опытные разработчики
На Rust тоже нужны, и их чаще всего не завезли, и кто-то будет переучиваться с плюсов или джавы.
Подключить библиотеку std можно только в MSVC. Модули только для своего проекта - так себе.
Эммм libc++ c 17 версии llvm поддерживает import std , а libstdc++ с 15 версии gcc ( 15 версия вышла весной этого года)
По факту не готово.
C++ compiler support Standard Library Modules (FTM)* P2465R3
GCC libstdc++ 15*
Clang libc++ 17 (partial)*
MSVC STL 19.35* (partial)*
Apple Clang* 19.36*
Хаха, через полгода вынесли функционал из монолита и уже увидели профит. Хз как так, обычно полгода идет анализ монолита (если это реально что-то серьезное, как говорит автор, судя по стоимости инфры) , сбор бизнес требований, обсуждение выносимого функционала, описание интеграции этого функционала, всевозможные репликации для поддержки работы старого монолита в параллель с обновленным. Потом еще пишется и согласовывается вязанка ТЗ, происходит аудит всего и вся, типа архитектуры, безопасности и т. д. Потом выделяется инфра для всех окружений (не забыв согласовать бюджет). И вот, через полгода-год, можно начинать что-то писать.
Для сравнения не хватает чисел, графиков, тестов.
ИМХО. Думаю джаву все же можно было затюнить, что бы она держала нормально трафик на себе. Тк свежая джава довольно производительна. В основном я склоняюсь к тому, что просто появился шанс зауюзать раст. Надеюсь ребята внедряли его с оглядкой на то, что если вся команда со временем разбежится из конторы, то будет довольно трудно искать людей на поддержку этого проекта.
Go, Rust или всё же C++? Куда мы переписываем наш высоконагруженный бэкенд в 2025