Comments 11
лол, "мы не смогли нормально написать на Го, потому мы написали на Расте" А потом еще удивляются чего так хейтят растаманов)
как я понимаю писал клод, а вы руководили?
спецом до конца прочитал статью но так и не увидел функционала, который бы действительно оказался бы тонким местом для Го. То есть изначально проблема в архитектуре была, и тогда из этого вытекает вопрос - а где гарантия что версия на расте получилась нормально? Может вы просто размазали проблемные места из-за чего "нормально работает" оно только у вас, а на других платформах или более слабых сборках начнутся приколы которые вытекают из архитектуры?
мы не смогли нормально написать на Го, потому мы написали на Расте
Видимо, го очень сложный при таких требованиях. Парадокс. Причём тут хейтеры не понял
да нет там ничего такого
у Го известное "тонкое место" со сборщиком мусора потому реально высокопроизводительные системы где важен каждый байт каждую миллисекунду таки лучше не на Го писать
Но тут они просто "не справились с управлением" то есть они написали решение "в лоб" и оно ожидаемо начало захлебываться на нагрузках так как много точек перехода меж зонами ответственности. Лишние сериализации и тд.
Это буквально база и основа для подобных проектов. Любой кто пытался что-то подобное делать (серьезно, а не просто пет-проект) знаком с этим. Это и есть архитектура - правильно паковать, передавать и обрабатывать данные, рассчитать структуры что бы можно было бы брать "напрямую" без серилизации если есть необходимость переносов меж подами прочее, прочее
И тут же появляется проблема - если изначально вообще не было понимания как оптимально работать со своими данными, то смена языка максимум размажет эту проблему. То есть у них те самые проблемы с сериализацией в наличии, просто они стали менее заметны. Я еще более чем уверен что это все гонялось на топовых ПК с кучей ядер и оперативной памяти - то есть проблема не ушла, а просто замелась под ковер, проблема перестала резать глаза именно у них на тестах, но скорее всего вернется с новыми "друзьями" на других сборках и платформах где уже язык не сможет "размывать" наличие проблемы.
Я плохо понял статью. Впечатление, что на Go больше точек сериализации, особенно при переходе в среду выполнения JS кода. В новом решении это как-то устранили. Возможно, через FFI
На Go FFI не получится
gRPC "просто существует"
Protobuf это тоже сериализация. Чуть дешевле по памяти и ЦП, но не бесплатно
ну так про это и речь
если хочется супер-оптимальности то данные выбираются без сериализации, просто проверка на целостность и длинну, то есть прочитали и сразу в обьект перекинули. У Го есть прям целый воз подобных особенностей заточеных как раз под такое во имя оптимизации.
Уж что что, но сериализация в Го всегда была меж быстро и надежно. Можно мега быстро, буквально бесплатно но только в рамках доверенных обьектов где уверен в входных данных. Тут как раз тот самый случай
понять бы зачем это
Жалко, очень мало подробностей. Что насчёт GC? Как именно он реализован? Как в памяти хранятся JS-структуры? Как делали аллокацию памяти под динамическую память — использовали ли bumpalo или что-то схожее? Как происходит трансляция из UTF-8 (Rust) в UTF-16 (JS)? Есть ли event loop в рантайме? Как именно и что мерили бенчмарком (wrk, отдельная машина или докер, прогрев турбофана и прочих кешей на V8)?
интересно, а почему выбрали Rust а не C++ - нативные привязки на C++ имеют лучшую поддержку в нодовском API, или преимущество в безопасности памяти перевешивает?
Чему мы научились, написав на Rust среду выполнения для TypeScript