Rust лучший язык для WEB

[RichAsHell]

Сегодня мы обсудим почему Rust лучший язык для WEB на примере фреймворков Actix и Laravel.

Главная цель бекенда - производительность и безопасность.
Actix — один из самых производительных веб-фреймворков благодаря Rust.
Laravel, использующий PHP, заметно уступает Actix в быстродействии и производительности под высокой нагрузкой.

Actix — один из самых быстрых веб-фреймворков в мире:
Примерные показатели:
На простых запросах JSON (бенчмарки TechEmpower (https://www.techempower.com/benchmarks/#section=data-r23)):

• Actix: до ~2,720,330 RPS.
• Node.js (Express): ~350,000 RPS.
• Laravel (PHP): ~26,000 RPS.

Таким образом, Actix превосходит Laravel по RPS примерно в 105 раз.


Почему Actix (Rust) настолько производителен?

Главная причина — язык Rust и подходы, которые он использует:

• Компилируемый в машинный код (LLVM).
• Zero-cost абстракции: абстракции (типы, структуры данных, асинхронность) не создают дополнительной нагрузки в runtime.
• Асинхронность: Actix активно использует асинхронные runtime-ы, такие как tokio, что позволяет эффективно обрабатывать огромное количество одновременных соединений.
• Эффективное управление памятью: Rust не имеет сборщика мусора, поэтому отсутствуют паузы GC, а память используется крайне рационально.

Чем Rust лучше C++?
Сравниваю их, тк С достойный низкоуровневый соперник и до недавнего времени был одним из двух самых сильных решений в web вместе с Java.

Rust считается «следующим шагом» после C++ благодаря нескольким ключевым преимуществам:
a. Гарантия Memory Safety без оверхеда
Rust практически полностью исключает ошибки работы с памятью (buffer overflow, use-after-free, data race).
В C++ такие ошибки могут происходить регулярно, если программист не очень аккуратен.
b. Современная, удобная асинхронность
Rust с Tokio или async-std предоставляет простое и удобное API для асинхронного программирования без дополнительных библиотек.
В C++ асинхронность гораздо сложнее и требует глубоких знаний о многопоточности и работе с памятью.
c. Мощная система типов и строгий компилятор
Rust выявляет большинство ошибок на этапе компиляции.
C++ менее строг и позволяет больше ошибок в runtime.
d. Простота параллельного программирования
Rust изначально проектировался с упором на удобство многопоточности.
Безопасное параллельное программирование доступно практически любому разработчику в Rust, в отличие от C++, где оно требует особых навыков.
e. Более лёгкое управление зависимостями
Cargo и crates.io в Rust — простейшая система управления пакетами.
В C++ dependency management традиционно проблематичен и менее удобен.

Итогo:
1) Очень быстрый:
Rust работает быстрее почти всех других языков, включая PHP и Python. Программы на Rust «летают»!

2) Не тратит память зря:
Он аккуратно распоряжается памятью компьютера. Это значит, что компьютер не будет тормозить, а игры и сайты будут работать плавно.

3) Безопасный:
На Rust сложно случайно создать ошибку, которая сделает программу уязвимой. Это как автоматическая защита, чтобы ничего не сломалось.


Что это значит на практике?

Быстрые сайты и API
Веб-сервисы будут отвечать мгновенно даже при тысячах одновременных посетителей.
Пользователи не заметят задержек и тормозов.

Экономия денег на серверах
Благодаря высокой производительности и низкому расходу памяти, для сайта потребуется меньше серверов.
Хоть разработчики на раст не самое дешёвое удовольствие

, но поверьте, это всё окупится сполне при виде чека с AWS либо количества серверов для одной нагрузки. Разница в 105 раз это не просто различие скорости, а сколько вам понадобится серверов, чтобы выдержать ту же нагрузку, что и Actix.

Стабильная работа под нагрузкой
Даже если неожиданно придёт много людей, сервис на Rust не упадёт и будет работать стабильно.

Безопасные платежи и данные
Веб-приложения на Rust гораздо сложнее взломать или заставить утечь данные, потому что он защищает от ошибок программиста автоматически.
Это значит что шанс иметь потери от взломов близок к нулю, только если в коде допущены логические ошибки. В случае с Ларавель вы будете больше чинить всё
чем создавать новые функции для клиентов. Как по мне лучше тратить 8000$ на кодера на Раст, чем терять всю кассу проекта раз в месяц вместе с постоянными
лагами, падением проекта и тд.

Лёгкое масштабирование
Если проект станет успешным и число пользователей вырастет, расширить приложение и увеличить его мощность будет гораздо проще и дешевле.
Раст уже поддерживает все самые важные библиотеки для крупных проетков. Redis, NATS, Cassandra, ClickHouse, RabbitMQ.

Лучшее качество приложений
Сайты на Rust открываются быстрее, страницы загружаются моментально, что улучшает SEO и пользовательский опыт.



Ожидаю ваши вопросы.

 

[shrekushka]

I believe tokio executor’s work stealing queues borrow from 1990s papers: the same for ULE scheduler in FreeBSD 8. Web kids rediscovering kernel ideas: .

 

[r11492962]

Сравниваю их, тк С достойный низкоуровневый соперник

С как и Rust высокоуровневые языки программирования. Низкоуровневый это Assembler

 

[shrekushka]

С как и Rust высокоуровневые языки программирования. Низкоуровневый это Assembler

If you’re writing the part of the stack that is essentially a userspace device driver (encrypt + compress + route packets) C is king and will be for years.

 

[RichAsHell]

I believe tokio executor’s work stealing queues borrow from 1990s papers: the same for ULE scheduler in FreeBSD 8. Web kids rediscovering kernel ideas: .

Я не говорю, что в С/С++ этого нет
Весь код так или иначе всё равно 0 и 1 --> на каждом языке можно написать что угодно, только раст удобный и сделан отлично в плане памяти и безопасности

 

[shrekushka]

Я не говорю, что в С/С++ этого нет
Весь код так или иначе всё равно 0 и 1 --> на каждом языке можно написать что угодно, только раст удобный и сделан отлично в плане памяти и безопасности

You could reimplement every one of those guarantees in C: we did remember libevent, libuv, libdispatch, libwhatever? Each shipped with its own CVE graveyard because a doublefree slipped into the hot path and left a chalk outline around the sandbox.

So I'm not anti Rust (cough cough... weaver ). I genuinely admire Rust's ambition + tons of value it brings to lots of people. After almost 70 years of compiled lang research (since Fortran) it’s refreshing to see some rules enforced in the type system instead of in a postmortem. But I don't think Rust is the way to do this. That said, I still prefer C.

 

[1mpossible City]

Недавно начал изучать язык раст, сложный язык но тем не менее безопасный.
Самое привлекательное в расте это - управление памяти на основе модели владения/заимствования, раст всё за вас безопасно организовывает избегая утечек в памяти.

 

[DildoFagins]

Я уже говорил раньше, но в общем я понимаю в чем причина существования Ржавого (как языка), и в отличии от тех же Цэ и Плюсов его всратость и сложность более менее оправдана благими целями. Но всё равно мне как практику (а не теоретику) крайне сложно найти причины писать на Ржавом. Какую-то специфичный софтину (ну вы понимаете) под Венду я куда быстрее и проще напишу на Шарпах, какой-то веб интерфейс я куда быстрее и проще сделаю на Петухоне, шеллкод я сделаю на Цэ, тем более, что шеллы обычно маленькие и не стрелять себе по ногам в Цэ и Плюсах за 20 лет кодинга я научился, по фану для чего-то быстрого можно упороться в Ним или в Дэ. Вот и выходит, что Ржавый, хоть и интересно, смысла учить и страдать в нем особо нет.

 

[RichAsHell]

Я уже говорил раньше, но в общем я понимаю в чем причина существования Ржавого (как языка), и в отличии от тех же Цэ и Плюсов его всратость и сложность более менее оправдана благими целями. Но всё равно мне как практику (а не теоретику) крайне сложно найти причины писать на Ржавом. Какую-то специфичный софтину (ну вы понимаете) под Венду я куда быстрее и проще напишу на Шарпах, какой-то веб интерфейс я куда быстрее и проще сделаю на Петухоне, шеллкод я сделаю на Цэ, тем более, что шеллы обычно маленькие и не стрелять себе по ногам в Цэ и Плюсах за 20 лет кодинга я научился, по фану для чего-то быстрого можно упороться в Ним или в Дэ. Вот и выходит, что Ржавый, хоть и интересно, смысла учить и страдать в нем особо нет.

Раст больше веб язык, на крайняк эмбед / tauri. Малварь это другое совсем, я не особо в малварь хочу лезть

 

[reqwest]

Я уже говорил раньше, но в общем я понимаю в чем причина существования Ржавого (как языка), и в отличии от тех же Цэ и Плюсов его всратость и сложность более менее оправдана благими целями. Но всё равно мне как практику (а не теоретику) крайне сложно найти причины писать на Ржавом. Какую-то специфичный софтину (ну вы понимаете) под Венду я куда быстрее и проще напишу на Шарпах, какой-то веб интерфейс я куда быстрее и проще сделаю на Петухоне, шеллкод я сделаю на Цэ, тем более, что шеллы обычно маленькие и не стрелять себе по ногам в Цэ и Плюсах за 20 лет кодинга я научился, по фану для чего-то быстрого можно упороться в Ним или в Дэ. Вот и выходит, что Ржавый, хоть и интересно, смысла учить и страдать в нем особо нет.

О расте стоит думать как о C++ здорового человека, области применения примерно те же. По моему опыту - раст гораздо проще и выразительнее тех же ++, после Си не заметил никаких сложностей с переходом. Касательно сложности - это присуще всем системным языкам без GC, тот же borrow checker (одна из причин жопоболи у новичков) - в плюсах разве не нужно следить за тем что куда мувается? Но разве не удобнее, когда компилятор следит за этим сам? Писать веб (перекладывать джсончики) на расте ни чуть не сложнее, чем на питоне, я бы сказал даже удобнее. Какую-либо системщину писать ни капли не сложнее, чем на си или плюсах. После перехода на раст я не помню когда последний раз пользовался отладчиком (зачастую даже не настраиваю его в редакторе), хотя реализуя проекты на си в прошлом я половину времени тратил на дебаг (но это скорее skill issue).
Под каждую задачу свой инструмент, но тем не менее, попробовав раст практически во всех нишах - остался вполне доволен.

 

[shrekushka]

Я уже говорил раньше, но в общем я понимаю в чем причина существования Ржавого (как языка), и в отличии от тех же Цэ и Плюсов его всратость и сложность более менее оправдана благими целями. Но всё равно мне как практику (а не теоретику) крайне сложно найти причины писать на Ржавом. Какую-то специфичный софтину (ну вы понимаете) под Венду я куда быстрее и проще напишу на Шарпах, какой-то веб интерфейс я куда быстрее и проще сделаю на Петухоне, шеллкод я сделаю на Цэ, тем более, что шеллы обычно маленькие и не стрелять себе по ногам в Цэ и Плюсах за 20 лет кодинга я научился, по фану для чего-то быстрого можно упороться в Ним или в Дэ. Вот и выходит, что Ржавый, хоть и интересно, смысла учить и страдать в нем особо нет.

О расте стоит думать как о C++ здорового человека, области применения примерно те же. По моему опыту - раст гораздо проще и выразительнее тех же ++, после Си не заметил никаких сложностей с переходом. Касательно сложности - это присуще всем системным языкам без GC, тот же borrow checker (одна из причин жопоболи у новичков) - в плюсах разве не нужно следить за тем что куда мувается? Но разве не удобнее, когда компилятор следит за этим сам? Писать веб (перекладывать джсончики) на расте ни чуть не сложнее, чем на питоне, я бы сказал даже удобнее. Какую-либо системщину писать ни капли не сложнее, чем на си или плюсах. После перехода на раст я не помню когда последний раз пользовался отладчиком (зачастую даже не настраиваю его в редакторе), хотя реализуя проекты на си в прошлом я половину времени тратил на дебаг (но это скорее skill issue).
Под каждую задачу свой инструмент, но тем не менее, попробовав раст практически во всех нишах - остался вполне доволен.

Same talking points on both sides:
1. intentions good + complexity unjustified
2. Rust = C++ for sane people
3. learning curve
4. experienced C/C++ coder has little problem with memsafety
5. borrow checker annoyance < manual lifetime bookkeeping
6. interesting but not worth it
7. big drop in bug hunting time
8. niches applicability
9. syntax
10. ABI
11. it doesn't solve memsafety (cough cough weaver)
12. I know better than the compiler

I'll do something else but that's extremely critical to us.
For some of us the comfort zone isn't "memsafety by default" but its knowing exactly what the compiler spits out. I add restrict / __attribute__((alias)) and know nothing else'll flip the table behind my back. Now do this in Rust: let mut x to let x: Cell<_>, the guarantee is annihilated. I can open -o2 disasm: confirm the loop hoisted its invariant loads + handrolled SSE memcpy inlined + vtable layout I expected + I could go on and on.

После перехода на раст я не помню когда последний раз пользовался отладчиком (зачастую даже не настраиваю его в редакторе), хотя реализуя проекты на си в прошлом я половину времени тратил на дебаг

I don't want to turn this into a debugger debate)) but I'll say this much: a debugger isn’t just for “when everything’s on fire”: there are "unknown unknowns".

 

[RichAsHell]

Same talking points on both sides:
1. intentions good + complexity unjustified
2. Rust = C++ for sane people
3. learning curve
4. experienced C/C++ coder has little problem with memsafety
5. borrow checker annoyance < manual lifetime bookkeeping
6. interesting but not worth it
7. big drop in bug hunting time
8. niches applicability
9. syntax
10. ABI
11. it doesn't solve memsafety (cough cough weaver)
12. I know better than the compiler

I'll do something else but that's extremely critical to us.
For some of us the comfort zone isn't "memsafety by default" but its knowing exactly what the compiler spits out. I add restrict / __attribute__((alias)) and know nothing else'll flip the table behind my back. Now do this in Rust: let mut x to let x: Cell<_>, the guarantee is annihilated. I can open -o2 disasm: confirm the loop hoisted its invariant loads + handrolled SSE memcpy inlined + vtable layout I expected + I could go on and on.


I don't want to turn this into a debugger debate)) but I'll say this much: a debugger isn’t just for “when everything’s on fire”: there are "unknown unknowns".

Dont forget about async, races, buffer. Also check stats from techempower (link above)

 

[Quake3]

Уже и до веба секта .растов добралась.

Все эти бенчмарки говно и не объективны.

 

[xChimera]

Интересно сколько соли было въебано перед написанием статьи

 

[r11492962]

Вы крутые ребят... Каким то образом заметить что язык 2010 года выпуска, как то поудобнее языка 1970-80... Это надо уметь)
Я уж молчу о том что размеры памяти у рядового пользователя в этих эпохах несравнимые. Поэтому и необходимость беречь её тоже радикально разные.

О расте стоит думать как о C++ здорового человека

 

[RichAsHell]

Уже и до веба секта .растов добралась.

Все эти бенчмарки говно и не объективны.

Интересно сколько соли было въебано перед написанием статьи

Походу не зря я на хсс не заходил...
Аргументы уровня лолз


Имеется ли возможность составить полное предложение, чтобы начать адекватный спор и в нём найти истину? Или цель форума в сраче и смайликах?

 

[cmpzx]

 

[Quake3]

Аргументы уровня лолз

Ты хочешь объективных аргументов? А у тебя достаточно знаний по тому же С++ , чтобы что-то обсуждать? Потому что в статье я вижу аргументы вида "в раст безопасно кодить, а в плюсах буфер оверфлоу, раст выбрали миллионы мух, а плюсы устарели". Вот и все. Что тут обсуждать.
Или ты кодер, который решил проблему 10к соединений на плюсах и расте, и там выиграл какие-то % производительности?

 

[RichAsHell]

Ты хочешь объективных аргументов? А у тебя достаточно знаний по тому же С++ , чтобы что-то обсуждать? Потому что в статье я вижу аргументы вида "в раст безопасно кодить, а в плюсах буфер оверфлоу, раст выбрали миллионы мух, а плюсы устарели". Вот и все. Что тут обсуждать.
Или ты кодер, который решил проблему 10к соединений на плюсах и расте, и там выиграл какие-то % производительности?

По С++ у меня мало знаний. Ну со стороны эти аргументы звучат лучше чем слова про соль или 3.14раст. Я делал хай лоад обработку бд на раст и переводил выдачу биг даты на раст с go и Laravel, разница 2-30 раз по производительности.

 

[Quake3]

Ну со стороны эти аргументы звучат лучше чем слова про соль или 3.14раст.

Потому что в моем понимании раст это сектанты, как на хабре не зайдешь в тему по плюсах - везде суют раст, типа это лучше.
А бенчмарки это мусор, помню это еще по двухтысячных, когда в блоге по РНР лидировал РНР, в блоге по руби он всех обходил, и так далее. Конечно раст обойдет какой-то пхп (архитектура другая, натив всегда будет лучше скрипта), но с другим нативом сомнительно (даже наоборот, все эти сборщики мусора или что там есть для "безопасного" кодинга тоже ведь занимают такты процессора).

В C++ асинхронность гораздо сложнее и требует глубоких знаний о многопоточности и работе с памятью.

Спорный вопрос. Какие либы, кто с чем сравнивал? Чем сложен тот же буст? Вот почему и говорю за секту..

В C++ dependency management традиционно проблематичен и менее удобен.

С этим согласен, зависимости и либы в целом - огромная проблема плюсов и Си.