Comments 35
Сын еврея-юриста недавно закончил университет, тоже стал юристом, получил практику и выиграл свой самый первый судебный процесс. Прибегает весь взволнованный домой:
- Папа, папа, я сегодня выиграл свой первый суд! И знаешь, папа, это то самое дело которое ты вел все прошлые 10 лет и не мог выиграть, а я его выиграл за один день!
Отец на это очень раздраженно отвечает:
- Вы только посмотрите на этого идиота! Он сегодня за один день закончил дело которое кормило нашу семью почти 10 лет! Кто нас теперь кормить-то будет?
Хорошая сказка. Вот только что-то мне подсказывает, что дело было совсем не в том, что "Его самая большая претензия заключалась в том, что если сервис не нужно дополнительно поддерживать, то трём инженерам не останется работы!", а из-за того, что нужно было нанимать еще трех новых человек, тогда как используя существующий стек технологий все можно было сделать уже имеющимися силами.
Директор посчитал бюджет и принял итоговое решение и конкретный язык программирования или framework тут не причем.
Мне кажется если заменить Rust на Go/Java/C#? в данной ситуации, то судя по описанию результат был бы таким же.
Странно, на такое 2 недели… На C++ давно уже пишем гораздо более сложные вещи за день примерно. Без проблем с производительностью, WS/бинарный протокол/rest. Без явного выделения памяти, RAII и так далее. Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун.
Так напишите статью как вы сделали гораздо более сложную вещь с нуля до продакшена за один день, всем будет интересно почитать.
+1
Зачем? Как это делать написано уже 100 раз до меня, просто возьмите архитектуру любого http сервера, например, nginx. STL + pthreads + OpenSSL + libev + Intel TBB + libfmt + rapidjson - основа.
Для бинарного протокола используем ULEB-кодирование и свой формат описания пакетов.
Парсер HTTP свой, для API-сервера не нужна полная поддержка протокола.
SSL проксирование через CloudFlare или через nginx, он же может и корректность протокола проверять.
У нас на этом написано несколько бэкэндов онлайн-игр, API-сервера для аналитики, различные сервисы.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
БД ClickHouse + MySQL, адаптер самописный.
Я так же написал свое расширение для ClickHouse для PHP (оно открытое), которое работает с ним по нативному протоколу и тоже базовая часть заняла около суток, остальное время уже реализация дополнительного функционала.
У вас что-то не так просто с эффективностью…
Как это делать
Сделать что? Вы же не знаете никаких требований по задаче, они не описаны в статье. Вы про свой проект пишите, как за один день сделали.
Для бинарного протокола используем ULEB-кодирование
А причем тут то, как вы кодируете неотрицательных числа, об этом кто-то спрашивал? Или это достижение какое? К чему перечисление стандартного стэка, кого это должно впечатлить? Проксирование через nginx - ого, вот это да.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
В статье не описано что было сделано за две недели, там был общий вижен без деталий чисто для статьи, без описания всех бизнес правил.
У нас на этом написано несколько бэкэндов онлайн-игр
У всех написаны бэкэнды сервис, к чему этот пассаж?
базовая часть заняла около суток
Я видел этот ваш проект, он действительно на уровне написания одного дня. Но мы о продакшен продуктах говорим.
У вас что-то не так просто с эффективностью…
Да не, Коля, это просто ты балабол и пустослов.
Нормальные сроки, для быстрого изучения новой технологии.
А ещё один срач cxx vs rust, зачем?
В вашем комментарии есть довольно много несоотвествий, мимо которых я не могу пройти, даже будучи опытным c++-разработчиком и горячим его сторонником:
если вы до этого написали N очень похожих серивсов - то N+1-й скорее всего в самом деле напишете довольно быстро
но для этого придётся взять десяток open source библиотек, обмазанных огромным количеством своего кастомного кода, т.к.:
многие библиотеки просто несъедобны в сыром виде, к сожалению
надо обеспечивать слои изоляции бизнес-логики от сторонних библиотек
да и вы сами пишете про много чего самописного
вот это всё самописное тоже надо учитывать в бюджете времени, потому что:
N+1-е повторение одного и того же - не есть общий случай и типовой сценарий. А на эти вещи с автотестами и отладкой уходят месяцы.
интеллектуальные права на этот код (он должен быть написан внутри компании)
день уйдёт только на то, чтобы собрать скелетик на CMake, и может успеете минимально запустить CI для всего этого
"без явного выделения памяти" - странноватая фраза, которая вообще непонятно что означает. А если вам по бизнес-логике надо работать с данными, объём которых зависит от конфигурации и прочих внешних факторов?
"Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун." - простите, но это вишенка на торте. Без комментариев.
У вас есть отсылки на то, что RFC в вашем самописном коде поддерживаются не в полном объёме, что означает, скажем так, риски всё это чинить в срочном порядке. Например, ваша реализация Websocket может отлично годами работать до тех пор, пока на вас не свалится multiframe-сообщение. Разработчик на поддержке, которого вы описали, вряд ли с этим справится.
Что мешало немного адаптировать код на Rust, сделав модуль под NAPI? Дальше уже расширять логику на жс. И овцы, как говорится, были целы, и волки...
Не выйдет: узкое место - прием и обработка соединений на одном ядре.
Переход контекста между виртуальной машиной и нативным кодом рушит весь перформанс в ноль. Джит не работает с уже скомпилированным. Пишешь сетевой код на виртуальной машине - пиши на ней же весь стек с начала и до конца, чтобы джит за оптимизировал все сетевые вызовы, тогда будет быстро.
В компании где работаю аналогичная ситуация. Десятки разработчиков на python + vue. Есть сложные высоконагруженные процессы, которые если переписать на rust даже сэкономят компании сотни тыс рублей в Яндекс облаке. Но на предложение переписать руководитель говорит - "А где мы потом будем искать разработчиков?"
Что за тупизна от руководства? Если переписать функционал на раст, то кто перепишет, тот и разработчик! Зачем их искать, когда они уже здесь?!
Как я понимаю, проблема в том, что раст разработчиков не много, соответственно потеря одного разработчика раста гораздо критичнее, чем потеря го/ноды/руби разраба.
CTO тоже не слишком много на рынке. Можем к ним тот же принцип применить и начать увольнять заранее?
Берешь любого C/C++ выше среднего и через пару месяцев он Rust разработчик, причем настолько, что смотреть на код на С++ будет с недоумением, я проверял на практике
Не понял. Если есть человек/человеки переписавшие на раст зачем ПОТОМ еще искать раст разрабов?
Представьте, что вы руководитель проекта, несете за него ответственность, вам выделяют утвержденный бюджет. В проекте сформирована команда разработчиков, она вас устраивает, в команде выстроены связи и есть стабильность.
В какой-то момент вам предлагают переписать работающий сервис на другой язык программирования, взять на себя риск, обновить команду и утвердить или простои сервиса, или доп бюджет на обновление (в какой-то момент нужно будет в штате иметь разработчиков нового языка и разработчиков старого языка для поддержки). Тут у вас, как руководителя, возникает вопрос: а потенциальное изменение затрат соответствует риску?
Наверное, поэтому руководители и отказываются от обновления.
Вы пост читали? Там буквально как раз про то, что есть сервис работающий, причем работающий так, как никому не снилось. У них есть команда, которая показала свою эффективность и способность решать проблемы. Но это не помешало эффективным менеджерам пропихивать его переписывание, простои и вот это все под соусом "а вдруг у нас завтра разрабы кончатся, да и эти что-то сидят слишком умные и работает у них все, тьфу".
Эффективным менеджерам в такой парадигме сложно, они не могут показывать всю глубину наших глубин и то как они превозмогают обстоятельства и решают несуществующие проблемы.
сэкономят компании сотни тыс рублей в Яндекс облаке
Которые, может быть, окупят содержание одного растовика
Async future блокировало среду выполнения на несколько секунд. Что за бред...
Надо было просто всех разработчиков компании переучить с JS на Rust, чтобы было кому тот сервис поддерживать. Заодно бы они переписали другие компоненты на Rust. Ну а потом бы всех уволили, ибо всё работало бы без нареканий и с минимальным потреблением ресурсов.
Жуткий текст!
История успеха, из-за которой компания перестала работать с Rust