Comments 48
Почему третий пункт приписан, как killer-feature раста? Он, конечно, хорошо туда собирается, но плюсы и go тоже умеют в wasm. И у всех трех есть zerodep embedded рантаймы для запуска модулей по типу wasmi, wasm3, wazero.
Автор зашел вчера на Хабр, запостил 4 сгенерённые LLM статьи, и... дальше что?
Если сгенерировал, то хотелось бы знать чем было сгенерировано вот это:
Вот алгоритм, который позволит вам спать спокойно, используя GPT-5:
Декомпозируйте задачу. Разбейте её на мелкие, атомарные части.
Пишите детальные промпты. Представьте, что пишете ТЗ для джуниора, который склонен делать именно то, что ему сказано, и не более.
Генерируйте код небольшими порциями. Не целый модуль, а одну функцию, один класс, один метод.
Проверяйте ВСЁ. Линтеры, тесты, внимательный код-ревью. Никаких исключений.
Рефакторите и интегрируйте. Вставьте проверенный код в свою кодобазу, приведите к своим стандартам.
Очень неплохо на мой взгляд. Сам(а) GPT-5 дает советы как строить ракботу с ней (ним)?
Не согласен. На мой взгляд, плохо и низкокалорийно. Ну давайте по пунктам.
Редукционизм изобрели в пятом веке до нашей эры. Тоже мне откровение. Совет понятный, но очевидный. Куда полезнее очертить оптимальный объём работы для каждого промпта. Сколько оптимально токенов должно быть в вводе и выводе? Человек с опытом немедленно покажет примеры, большая языковая модель будет давать общие указания.
Писать детальный промпт — самый хороший совет. Я бы разве что рекомендовал представлять не младшего разработчика, а дьявола, который будет делать всё наоборот (вразрез с вашими ожиданиями), если вы не оговорили обратное. Для начала нужно задуматься, какие из ваших ожиданий остаются невысказанными и, собственно, высказать эти ожидания.
См. пункт 1.
Проверять вывод БЯМ — тоже неплохой совет. Обратите внимание, что он опять дан словами Капитана Очевидность, без примеров из практики.
См. пункт 4.
Итого пять советов, из которых в реальности будет три. И все даются максимально общими словами.
Именно так пишут дешёвые языковые модели: мало смысла, слов избыток. Модель не назову, но не думаю, что здесь бесплатный тариф. Думаю, БЯМ была без reasoning.
Тут похоливарить можно только на тему осознанности выбора, потому что судя по приведенным плюсам и минусам она где-то не с нами
Автор провокатор и выдумщик.
Вопросы:
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
"переписать самые горячие пути" - а интегрировать как? Есть много тонкостей.
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?
Где цифры, Билли?!
З.Ы. Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой?
в старой системе из коробки Map<Long, Long> а в новой open addressing на примитивах)
То есть, переписать всё оказалось проще, чем оптимизировать Map[Long, Long]?
Ключевое слово тут «переписать», переписывание с джавы на джаву даст тот же эффект) при условии конечно что разрабы не совсем валенки и хотя бы примерно представляют во что компиляется и как исполняется их поделие. Исключение - ультралоулатенси которое на гц физически невозможно сделать, но судя по паузам в 300мс тут был не тот случай (если он вообще был)
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
Когда затраты на инфраструктуру превышают зарплату нескольких мидлов, то могли и разрешить.
Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Раст очень гибок в плане представления. Я до сих пор натыкаюсь на свой собственный код 1-2 летней давности с mut и match на Optional, хотя через полгода интенсивного литкода освоил кучу идиом, которые приближают код к идеалу на хаскеле.
Хотелось бы увидеть какие-нибудь картинки с тестами, что ли. А то написать сейчас так можно про что угодно:)
В топе бенчмарков techempower стабильно фреймворки на Rust, C и C++, иногда NodeJS.
Для разработки лучше может оказаться использовать не топ-3 фреймворки (поскольку они подгоняются под тесты соревнования), и в процессе вполне можно написать глубоко неоптимальный тормозной код, но некоторые языки просто удобнее для написания высокопроизводительного кода, чем другие (за счёт отказа от виртуальной машины, сборщика мусора и прочих вещей, которые облегчают жизнь разработчикам, но не потребителям).
На задачах компании ТСа рейтинг языков и фреймворков может быть другой, разумеется (на скриншоте - просто RPS статичной страницы).
У нас в компании Java (SpringBoot) пока всё равно остается на первом месте просто потому что вся экосистема на это завязана - генераторы кода и прочее - ну и компетенции разработчиков тоже. Однако, самые высоконагруженные сервисы потихоньку переезжают на Go. Лично меня это пока не коснулось, но в планы аттестаций MSA разрабов Go уже залетел как обязательный пункт.
в минусах С++ - специалист
а типо на на расте и го не нужен специалист?
Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Поднять еще нод, не вариант?
А почему не рассматривался C# ?
Современный .NET позволяет даже работать напрямую с памятью с нулевым оверхедом.
На самом деле хотелось бы увидеть примеров: контроллера, ORM и обращений в БД, легирования (желательно сквозного там c OTel и Jaeger), юнитов под это добро написанных и тд, DI особенно после Spring-экосистемы.
При том я к Rust’у отношусь крайней положительно, но ни разу не видел продовый код на нем, а очень хотелось бы.
UPD: дописал про DI
Вот кстати с логировагием и телеметрией есть tracing, он нас устраивал до определённого момента, но начал бесить своей не гибкостью и мы приняли решение на fastrace переезжать.
Про fastrace не слышал, спасибо, запишем.
да фаст штуки можно хоть на С++ написать и будет быстро, вот интересно если сравнивать 2 бвх дерева на раст и С++, кто быстрее кастует в обьект, я клоню к тому, что процесс может быть в дереве, и можно отсекать всё что не связано с запросом
я просто почитал про фаст трейс и подумал про бвх
тоесть если упростить вопрос чей рейтрейс быстрее раста или С или С++
У меня такой есть, не большой, но деньгами ворочает. Работает стабильно и эффективно по памяти. И главное - я могу ему доверять, компилятор и механизмы паттерн-метчинга гарантируют мне что неожиданностей не будет. Для финтеха очень важно.
В нынешней реальности надо ещё анализировать качество перегонки кода туда сюда LLMками
Забавно, что мы со скалы на rust переписали сервис и примерно такие же порядки цифр по памяти и процессору получили. Ну и в результате там теперь 8 подов, а не 32.
Скорость работы это хорошо, а скорость стабильной работы сравнивали? А то вот убунтоводы тоже на ржавом переписали 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 тоже нужны, и их чаще всего не завезли, и кто-то будет переучиваться с плюсов или джавы.
Go, Rust или всё же C++? Куда мы переписываем наш высоконагруженный бэкенд в 2025