Bench конечно есть в Rust, но вот такого же pprof как в Go нет. Только такое смог найти https://github.com/tikv/pprof-rs, но это не стандартный пакет. В Go что bench, что pprof идёт из стандарта и развивается основной командой ЯП.
В этом году тоже решали подобную задачу и остановились на OR-Tools.
Для определения скорости и времени от точки А до точки B использовали Open Source Routing Machine (OSRM) - он используется на https://www.openstreetmap.org/.
Правда нам пришлось его поставить на отдельную машину, чтобы быстрее считать сразу большой набор данных за 1 запрос. Информацию по пробкам надо загружать отдельно и с OSRM есть свои нюансы)
При использовании OR-Tools наткнулись как минимум на 2 проблемы:
На момент нашего исследования - не умела работать в многопоточном режиме, что приводило к долгому обсчёту (обещают поправить в CP-SAT);
При добавлении новых ограничений в модель OR-Tools, она легко может сломаться или уйти искать решение в бесконечность (пришли к выводу - что ей надо помогать, см ниже).
В итоге пришли к такому сценарию:
Создали отдельную модель кластеризации и разбили N-точек на группы для каждой машины;
Прогоняем уже в параллель модель на для каждой машины;
Проверяем, что все точки машина успешно прошла. Если нет - анализируем загрузку каждой машины и делаем перебалансировку точек на другие маршруты и заново идем в п.2 (обычно за 2-3);
Написали в Jupyter визуализацию каждого маршрута на карте - чтобы просмотреть результат модели.
Миграция - отдельный модуль или вообще можно использовать специализированное решение для этого https://flywaydb.org.
Таким образом, мы собираем нужный функционал из отдельных модулей - которые специализированно решают свою конкретную задачу. Лишних зависимостей в сервисе не будет при таком подходе. Я привел лишь примерный набор модулей - каждый сам выбирает нужное себе.
Обычно такие решения потом перерастают в корпоративный framework cо своей структурой и допиливаются под нужды организации (если мне память не изменяет - так как раз происходит в Авито).
И говорить:
Дикий запад PHP в его худшие годы.
С таким утверждением - не согласен, так как это уже работает в больших организациях)
Так же стоит отметить - что в Golang есть проекты, которые могут в той или иной мере подходить под определение framework:
Подход описанный автором - я не защищаю, а пытаюсь просто донести его основную мысль.
Если Вам комфортно работается c framework'ом и Вы не чувствуете проблем - то ок)
Главное: чтобы Ваша привычка к framework`у и его приятной экосистеме не привело к такому сценарию, что при реализации фичи - такого функционала не окажется в framework'е и Вы просто разведете руками и скажете нельзя сделать.
Если нужен wrapper на CatBoost для Golang - https://github.com/mirecl/catboost-cgo
Рекомендую попробовать делать такие bench c https://github.com/hatoo/oha
P.S. Интересно ещё было бы посмотреть результаты с mTLS.
Bench конечно есть в Rust, но вот такого же pprof как в Go нет. Только такое смог найти https://github.com/tikv/pprof-rs, но это не стандартный пакет. В Go что bench, что pprof идёт из стандарта и развивается основной командой ЯП.
За перевод спасибо!
В этом году тоже решали подобную задачу и остановились на OR-Tools.
Для определения скорости и времени от точки А до точки B использовали Open Source Routing Machine (OSRM) - он используется на https://www.openstreetmap.org/.
Правда нам пришлось его поставить на отдельную машину, чтобы быстрее считать сразу большой набор данных за 1 запрос. Информацию по пробкам надо загружать отдельно и с OSRM есть свои нюансы)
При использовании OR-Tools наткнулись как минимум на 2 проблемы:
На момент нашего исследования - не умела работать в многопоточном режиме, что приводило к долгому обсчёту (обещают поправить в CP-SAT);
При добавлении новых ограничений в модель OR-Tools, она легко может сломаться или уйти искать решение в бесконечность (пришли к выводу - что ей надо помогать, см ниже).
В итоге пришли к такому сценарию:
Создали отдельную модель кластеризации и разбили N-точек на группы для каждой машины;
Прогоняем уже в параллель модель на для каждой машины;
Проверяем, что все точки машина успешно прошла. Если нет - анализируем загрузку каждой машины и делаем перебалансировку точек на другие маршруты и заново идем в п.2 (обычно за 2-3);
Написали в Jupyter визуализацию каждого маршрута на карте - чтобы просмотреть результат модели.
Да) Gorilla Mux буквально 4 дня назад ушла в архив
Автор исходной статьи имел ввиду немного другое.
Приведу пример:
Допустим стоит задача разработать небольшой REST c n-ручками. В Golang есть выбор:
Можем взять сервер из стандартного пакета net/http;
Если понимаем, что нагрузка будет очень большая - можем посмотреть в сторону fasthttp/fiber и тд.
Идем дальше, нужен конечно routing:
Если скучно - можно написать самому? и как раз решать все нюансы с HEAD/OPTIONS/CSRF/XSS и тд;
Можно воспользоваться отдельными модулями для данной задачи - httprouter/gorilla и тд.
Куда ж без логирования - отдельный модули logrus/zap и тд.
Продолжаем, необходимо добавить метрики Prometeus + Tracing = берем отдельные модули
Нужно нам JWT - опять добавляем модуль + различные middelware.
Куда же без БД?:
Любим ORM - идем в GORM (использовать или нет ORM - это отдельный вопрос);
Хотим все контролировать и не боитесь SQL - sqlx.
Миграция - отдельный модуль или вообще можно использовать специализированное решение для этого https://flywaydb.org.
Таким образом, мы собираем нужный функционал из отдельных модулей - которые специализированно решают свою конкретную задачу. Лишних зависимостей в сервисе не будет при таком подходе. Я привел лишь примерный набор модулей - каждый сам выбирает нужное себе.
Обычно такие решения потом перерастают в корпоративный framework cо своей структурой и допиливаются под нужды организации (если мне память не изменяет - так как раз происходит в Авито).
И говорить:
С таким утверждением - не согласен, так как это уже работает в больших организациях)
Так же стоит отметить - что в Golang есть проекты, которые могут в той или иной мере подходить под определение framework:
Gin;
Go-kit;
Beego;
и тд.
Подход описанный автором - я не защищаю, а пытаюсь просто донести его основную мысль.
Если Вам комфортно работается c framework'ом и Вы не чувствуете проблем - то ок)
Главное: чтобы Ваша привычка к framework`у и его приятной экосистеме не привело к такому сценарию, что при реализации фичи - такого функционала не окажется в framework'е и Вы просто разведете руками и скажете нельзя сделать.