Небольшой выигрыш в rust дает, если вместо использования pool запускать несколько инстансов сервиса на одном порту (каждый в своем отдельном потоке, потоков по количеству процессоров ) и в каждом инстансе отдельное соединение к postgresql.
Почему если делают RAD систему, то обязательно придумывают свой уникальный язык (DSL)? Все равно код будет писать не менеджер или бухгалтер, а программист. Программистам же проще использовать привычные языки для разработки. Использовали бы, например, Python или Kotlin, на которых можно вполне сделать подходящий DSL и возможно RAD бы пользовалась большим спросом.
В 1с например просто присваивают значения полю, как указано в разделе "В начале было Active record" и проблем нет. Есть правда события, например "ПередЗаписью" где мы можем проверить и дозаполнить необходимые поля. Я думаю в Go по аналогии нужно не в метод Apply передавать разные функции, изменяющие объект, а сделать метод Save(ctx) и в нем закодировать логику расчета доп полей перед помещением в БД.
Понятно, что бизнес диктует на чем писать и какой стек использовать. Но рынок Go разработчиков растет, а вот c Rust пока все плохо. Но если писать с нуля, в стартапе например, то выбирают обычно последние инструменты и технологии и в частности часто выбирают между Go и Rust. Java требует очень много памяти, python медленный и т.п. И может лучше вложиться немного в разработчиков, чем потом годами переплачивать за железо и бороться с тормозами.
Языки сравниваются через программы на них написанные. В данной статье сравниваются стеки Fiber-lib/pq vs Axum-sqlx как одни из самых популярных библиотек для разработки web-сервисов. Возможно кому то это сравние даст дополнительную пищу для размышлений и сделает перевес в ту или иную сторону.
Смысл в том, что вот думает разработчик на чем писать новый проект, выбирает из нескольких вариантов, а для объективного выбора не хватает информации - люди пишут одно, в тестах выходит другое. И вот чем больше будет разных сравнений, тем лучше.
Результаты скриншотами мне показались красивее, чем просто текст с терминала копировать. Или вы про то, что нужно графики сделать?
Скорее всего не в этом дело. Я запускал сервис и последовательно выполнял по 3 замера с 10,50 и 100 соединениями не перезапуская сервис (9 замеров). Таким образом пул бы "прогрелся" уже после первого замера
Tokio используется. Через него создаются инстансы. Пример rust_axum_pg в github из статьи.
Так не запрещено же из одного метода вызывать другие процедуры и функции.
Я про IsFusion. В 1с язык более менее привычный.
Небольшой выигрыш в rust дает, если вместо использования pool запускать несколько инстансов сервиса на одном порту (каждый в своем отдельном потоке, потоков по количеству процессоров ) и в каждом инстансе отдельное соединение к postgresql.
Почему если делают RAD систему, то обязательно придумывают свой уникальный язык (DSL)? Все равно код будет писать не менеджер или бухгалтер, а программист. Программистам же проще использовать привычные языки для разработки. Использовали бы, например, Python или Kotlin, на которых можно вполне сделать подходящий DSL и возможно RAD бы пользовалась большим спросом.
В 1с например просто присваивают значения полю, как указано в разделе "В начале было Active record" и проблем нет. Есть правда события, например "ПередЗаписью" где мы можем проверить и дозаполнить необходимые поля. Я думаю в Go по аналогии нужно не в метод Apply передавать разные функции, изменяющие объект, а сделать метод Save(ctx) и в нем закодировать логику расчета доп полей перед помещением в БД.
Еще можете глянуть здесь: https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=yyku7z-cn3
Все, все что с sqlx находится внизу списка
Добавил в git стек ntex + deadpool-postgres + tokio-posgtres (с кешированием statements).
Без lto проигрывает Go на 0,5%, c lto выигрывает 0,5%. В общем на фоне погрешности. Замена axum на ntex преимущества не дало.
Преимущество Rust только в потреблении памяти получается.
У меня на tokio-postgres показатели почему то как на sqlx. Какой пул использовали или без пула?
Изменил указанный параметр и провел замеры. По итогу Go и Rust сравнялись у меня. Дополнил статью.
Запустил с параметрами -c 300 -n 100000
Go: 10489 Req/s
Rust: 4327 Req/s
В чем то у Rust явно проблема, возможно в sqlx. Переделаю на diesel и проверю еще раз.
Ну я думаю у Grafana Cloud и нагрузка большая. Или "высоконагруженные" это только Google да Яндекс?
Понятно, что бизнес диктует на чем писать и какой стек использовать. Но рынок Go разработчиков растет, а вот c Rust пока все плохо. Но если писать с нуля, в стартапе например, то выбирают обычно последние инструменты и технологии и в частности часто выбирают между Go и Rust. Java требует очень много памяти, python медленный и т.п. И может лучше вложиться немного в разработчиков, чем потом годами переплачивать за железо и бороться с тормозами.
После замены lib/pq на pgxpool показатели увеличились на 52% до Req/s: 9193.11
Языки сравниваются через программы на них написанные. В данной статье сравниваются стеки Fiber-lib/pq vs Axum-sqlx как одни из самых популярных библиотек для разработки web-сервисов. Возможно кому то это сравние даст дополнительную пищу для размышлений и сделает перевес в ту или иную сторону.
Смысл в том, что вот думает разработчик на чем писать новый проект, выбирает из нескольких вариантов, а для объективного выбора не хватает информации - люди пишут одно, в тестах выходит другое. И вот чем больше будет разных сравнений, тем лучше.
Результаты скриншотами мне показались красивее, чем просто текст с терминала копировать. Или вы про то, что нужно графики сделать?
Но на Go пишутся не вспомогательные сервисы, а высоконагруженные сложные системы. Например Kubernetes, prometheus, вроде Grafana.
Но ведь "настройка" работает для обеих сторон. Т.е. если "донастроить" например библиотеки Go, то он получит еще большее преимущество?
Скорее всего не в этом дело. Я запускал сервис и последовательно выполнял по 3 замера с 10,50 и 100 соединениями не перезапуская сервис (9 замеров). Таким образом пул бы "прогрелся" уже после первого замера
Если этот так, то можно как то в Rust подготовить заранее подключения не выполняя запросов?