Чому обирають Rust

Telegram dou#techПідписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привіт, в травні я готував статтю про перший випуск навчальної групи з Rust, зголосився готувати статтю за власним бажанням бо мені подобається Rust й звісно сама спільнота.
Це продовження травневої статті.

Чому бізнес вибирає Rust

Основна причина вибору Rust великими технологічними гігантами це те що Rust фінансово вигідний у довгостроковій перспективі із-за своєї надійності, що дуже важливо для хмарних провайдерів (AWS, GCP та Azure) у яких безвідмовна робота, ось ці 99.999% uptime, прописується в договорах.

Rust фінансово вигідний бо є енергоефективним, менші витрати за електроенергію то більший чистий прибуток у хмарних провайдерів.

Rust фінансово вигідний бо програми на Rust потребують менше ресурсів й відповідно запущених серверів за які потрібно платити.

Заради цікавості розглянемо наявність репозиторіїв з Rust у великих технологічних гігантів:

КомпаніяЧисло репозиторіївRust Foundation Membership
Mozilla56
Google + GCP71
Microsoft + Azure53
Sentry45
Cloudflare43
Dropbox16
Amazon + AWS10
Facebook8
Shopify8
ARM1
Apple0
Netflix0

Чому фахівці вибирають на Rust

Фахівці вибирають Rust із-за передбачуваності та сучасного інструментарію.
Відсутня потреба дізнаватись про undefined behavior які є в C та C++.
Відсутня потреба вивчати підводі камні та писати про це окрему статтю бо компілятор відловлює майже усі помилки й виводить читабельні повідомлення з варіантами рішення.
В мене відсутня потреба описувати в статтях про Rust можливі проблеми з data race, які описував в статтях про Go:

Навіщо навчальна група

В української Rust спільноти є амбіційна ціль стосовно навчання й вся ця передмова має на меті показати важливість регулярних випусків навчальних груп з Rust для розвитку української ІТ-індустрії в цілому.
Саме це уявлення я спробую передати вам, а від вас очікую конструктивну критику в коментарях.
Розглянемо Rust через порівняння українського рейтингу мов програмування від DOU та світового від Stack Overflow за три роки: 2020, 2021 та 2022 рік.
РікDOUStack Overflow
2020Рейтинг мов програмування 2021Developer Survey 2020
2021Рейтинг мов програмування 2022Developer Survey 2021
2022Рейтинг мов програмування 2023Developer Survey 2022
Хочу звернути вашу увагу на мови в секції Які мови ви збираєтеся вивчати наступного року в рейтингу від DOU й відповідну їй секцію Most loved, dreaded, and wanted на Stack Overflow.
В українському й світовому рейтингу, фахівці планують вивчити наступного року одну з п’яти мов програмування згідно результатів опитування 2022 року:
МісцеDOU%Stack Overflow%
1Go17.50Rust17.60
2Python16.70Python17.59
3Rust12.60TypeScript17.03
4JavaScript10.80Go16.41
5TypeScript10.20JavaScript12.98
Ці ж п’ять мов програмування фахівці планували вивчати в 2021 та 2020 роках також.
Й щоб скласти картину наскільки мови ростуть то потрібно порівняти бажання вивчити нову мову з приростом використання цієї мови у професіоналів наступного року.
РікStack Overflow (Wanted)Stack Overflow (Used)
2020Most Loved, Dreaded, and WantedMost popular technologies
2021Most Loved, Dreaded, and WantedMost popular technologies
2022Most Loved, Dreaded, and WantedMost popular technologies
Якщо ви відкриєте всі ці шість посилань то побачите, що JavaScript та Python майже без змін, а росте саме професійне використання TypeScript, Rust, а вже потім Go, ось відповідні проценти професійного використання по рокам:
Мова програмування% за 2020 рік% за 2021 рік% за 2022 рік
JavaScript69.7068.6267.90
Python41.6041.5343.51
TypeScript28.3036.4240.08
Go9.4010.5111.83
Rust4.806.408.80
Фахівці майже однаково хочуть вивчити одну з цим п’яти мов програмування наступною, але найменше поки вивчають Rust із-за високого порогу входу.

Rust це мова програмування з тестовим завданням, але компанія того варта.

Для всіх цих п’яти мов програмування вже достатньо якісних навчальних матеріалів в інтернеті, навіть для Rust, але із-за високого порогу входу то потрібно приділити більше часу для вивчення Rust, а мотивувати себе самостійно вчитись такий довгий час то також складно й щоб спростити цей бар’єр й була створена навчальна група з вивчення Rust, групу веде ментор, який чотири дні на тиждень по годині спілкується з групою.

Коли міжнародний бізнес втомлюється виправляти технічний борг, правити помилки, намагатись оптимізувати затримки GC то переписує на Rust, але на світовому ринку поки мало кваліфікованих Rust фахівців тому важливо зайняти цю нішу й дати можливість асоціювати Україну з кваліфікованою розробкою на Rust.

Агресивна стратегія для перекваліфікації на Rust

Спільнота Rust намагається перехопити розробників які збираються вивчити нову мову програмування через відповідні навчальні матеріали:
Й в такому випадку закриваються три цілі:
  1. Спрощується поріг входу для TypeScript розробників, Python розробників та Go розробників
  2. Показується наратив, що розробники з цим мов програмування переходять на Rust
  3. А третій, що переходячи на TypeScript, Python або Go то все одно будете потім переходити на Rust, то краще вже одразу на Rust
Звісно ви можете спробувати пошукати навпаки:
А також спільнота Rust намагається перекваліфікувати фахівців з популярних мов програмування:
А спроби Rust for C++ Developers вже вважаються застарівшими.

Альтернативи

Rust має високий поріг входу, й хоч українська Rust спільнота намагається спростити цей поріг входу через переклад оригінального Rust Book на українську мову Мова програмування Rust, а також через навчальну групу з ментором, але все одно є очікування що ось-ось розроблять нову мову програмування, яка буде мати всі переваги Rust й простотий поріг входу як у JavaScript чи Python.

Такою мовою програмування може бути Zig на якому розроблений новий Bun:

Bun is a fast all-in-one JavaScript runtime

Або такою мовою програмування може бути Mojo:

Mojo is a new programming language that bridges the gap between research and production by combining Python syntax and ecosystem with systems programming and metaprogramming features. Mojo is still young, but it is designed to become a superset of Python over time.

Епілог

За пару годин до початку написання цієї теми, я скасував підписку на Netflix.
Складність входу в Rust може збільшитись тому хутчіше
👍ПодобаєтьсяСподобалось5
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Funny article with Rust vs Go syntax comparison — arriqaaq.substack.com/...​ust-anxiety-insights-from

Працюю на Go, через простоту мови — доводиться постійно «писати колесо».
Працював с C# - вважаю гарна мова, але вендор-лок та є біг хейт усього від МС :)

Rust на перший погляд сподобався, але знову ж таки — шаблонізація та макроси присутні (що є скоріш негативом по досвіду з С++).
Rust цікавий, але поки вакансій немає. Поки що на Go, вакансії є.

Як щодо таких раритетів, як Nim та Julia? :)

В Расті нема шаблонізації, в Расті є справжні дженерики, які тайпчекаються до розкриття.

і макроси, трохи не такі як в ++

Працюю на Go, через простоту мови — доводиться постійно «писати колесо».

Цікаво, що це означає
Я якось спробував подивитись на кількість бібліотек на го — їх просто дофіга і трошки

Ну швидше не бізнес, а ряд інженерів яким кортить щось нове використати. Rust доволі складна мова, складність приблизно рівня С++. Та враховуючи той факт, що з Java та C# - сьогодні головні технічний стеки бізнес застосунків, прив’язані до корпорації Oracle та Microsoft, інші технічні гіганти, зокрема Google, META, Netflix, Apple та Amazon активно розглядають альтернативи. З цієї точки зору новітні концепції які доступні зокрема в Rust — підходять дуже добре, при чому в них нема головних недоліків віртуальних машин — часткової інтерпретації, оптимізації в рантаймі, алгоритму збірки сміття. Це за великим рахунком добре коли программа росповсюджується як частина флеш чи апплет, концепція Java — чудова ідея, байткод який вже не похідний код та віртуальна машина. Для випадків серверної програми, або мобільного застосунку — це непотрібно, більше за те долає додаткові накладні витрати на пам’ять та процесор під час роботи програми. Усі інші часто просто повторюють за лідерами ринку те що вони роблять. Якщо сьогодні MAANG займаються Rust та AI — завтра ним починав займатись уся індустрія, навіть коли воно може бути зовсім не релевантно для типу бізнесу яким займається компанії десь із третього ешелону.

Rust доволі складна мова, складність приблизно рівня С++.

датишо!

А ні хто не порівнював Java Native Image і Rust по перформансу і фічам ?

Пошукав Java Native Image vs Rust, але знайшов лише кеш з Reddit:

Even with native images Java is incapable of reaching the performance and memory management offered by Rust

Ось знайшов
blog.consol.de/...​-native-vs-spring-native

Шкода що повноцінного порту кафка стрімс на расті нема

Зато Pulsar у себе зробив github.com/streamnative/pulsar-rs У Kaffka кращій маркетинг за Pulsar, але в реалі хто кого то велике питання. Ідея з масштабування в обох брокерів однакова.

Можна, та за сенсом — власне зокрема через бібліотеку та відсутність алгоритму збірки сміття чисто за номінальним перфомансом Rust має Java в лоскути порвати. Хоча С++ 20 він усе такі програє, тому що існуючі компілятори не дуже добре оптимізують, та вставляють занадто багато перевіряючого бінарного коду, тоді як він часто є непотрібним. Замість цього краще би було вставити статичний код аналіз з AI на рівень самого компілятора. Щодо збірки сміття, для програми яка працює в продакшені місяцями, алгоритм із дефрагментацією пам’яті типу G1 навпаки може бути кращим і т.д. і т.п. Щодо швидкості кодування — навпаки Java за рахунок існуючих фреймверків та інструментів, розірве Rust в лоскути. Умовний джуніор на Spring чи скажімо RxJava — зробить типовий застосунок методом компоновки існуючих компонентів та декларативним аспектним підходом, на тиждень швидше за Senior-а на Rust, якому доведеться написати купу велосипедів на усі випадки життя. Rust ще не дістався рівня абстракцій мови для написання прикладних бізнес застосунків, навідміну від Java та C#. Rust розроблений для іншого рівня абстракцій, це той самий рівень що і C++.

чисто за номінальним перфомансом Rust має Java в лоскути порвати

Але якщо глянути бенчмарки, то виходить взгалі не так радужно, бо в топі раст з джавою у перемішку, тобто ні про який «порвати» не йде мова навіть близько.
Тестив я ще якось, що там з перформансом у расту з більш-меньш високорівневим програмуванням тобто брав actix, щось там для ORM (різні варіанти були), або просто навіть драйвер для SQL — й сюрприз, так раст дійсно швидший за java-spring, але берем вже якийсь мікрофреймворк націлений на перформанс — й все, раст повільніший.

Ось ще можна подивитись чисто framework overhead web-frameworks-benchmark.netlify.app/result — бенчмарк чисто роутінгу. Раст тут не на першому місці.

Але він обходить там, де є багато обчислень, причому значно. Але ніхто ж не буде обирати раст для всього проекту, для такого зазвичай пишуть лише цей кусок на С/C++/Rust й викликають через ABI або HTTP (якщо це мікросервіс).

П.с. я не згоден що на расті писати довше ніж на джава через відсутність абстракцій. Ви взагалі бачили наприклад стандартну лібу раста? Да вона в 100 разів краще ніж Java, в який постійно свої util методи доводиться писати. Важко писати саме через borrow checker. Ти наче такий продуктивненько пишеш, все супер, а потім бах й на 2 дні фіксиш якусь помилку borrow checker.

та відсутність алгоритму збірки сміття чисто за номінальним перфомансом Rust має Java в лоскути порвати

Не так вже і часто та збірка сміття викликається, але згоден що по швидкості девелопменту джаву дуже важко подвинути

а по ціні підтримки, багофіксингу ?

багфіксинг мабуть раз в сто легше на джава

Ну добре не раз в сто але джава для суппорту це самий затюнений варік

тому що там бізнес модель як в з принтерами:
заробляти на картриджах, так із джава/с++

Та не які картриджи )) код пишуть )

бізнес модель писати код, чи потім його нескінченно фіксити?
в Русті, кажуть, раз написав, і якщо запустилося без креша, то 99.9% вже ніяких гонок, мертвих петель і невизначених ситуацій

раст нікому не потрібний, навіщо обманювати людей щоб ті витрачали свій час, в містах-мільйонниках сша вакансій на раст не більше 0-10. Для всіх задач крім написання коду для операційних систем можна брати тайп скрипт і створювати рішення в рази швидше при цьому рівень когнітивного навантаження в рази нижчий. А джава з пітоном все ще королі

Я ж навів посилання на результати опитувань тому ви можете перейти й порахувати число розробників на Rust

А по-друге я навів розділ з альтернативами Rust-у

А по-третє великі технологічні компанії чомусь то обирають Rust

ті великі компанії вам нічого не покажуть і не розкажуть. чи ви про discord? хД

Я ж навів у статті посилання на репозиторії з Rust

С++ нікому не потрбіний, навіщо обманювати людей, щоб витрачали свій час, для всіх задач крім написання коду для ОС (там С та асемблер) можна брати тайп скрипт і створювати рішення в рази швидше, при цьому рівень когнітивного навантаження в рази нижчий.

C++ це база, основа, фундамент

C база, фундамент, а С++ понти зі свистоперділками
З останньої аналітики джинні:
t.me/djinni_official/1001
Найменше відгукуються в категоріях C++, Rust i Salesforce, по 2 відгуки на вакансію.

djinniblog.substack.com/p/djinni
Шанси знайти роботу найкращі у Lead Generation, Rust I Data Engineer

Порахували, який відсоток кандидатів, що активували профіль за перші три місяці 2023, уже повідомили про найм. Серед Lead Generation таких аж 20%. Rust i Data Engineer — по 10%. Для порівняння, у категорії JavaScript це 3,5%. Навіть в QA більше — 3.8%. Середній відсоток наймів без розподілу на категорії — 4,8%.

а Rust це C++ з цікавим механізмом володіння пам’яттю

прям війна клонів і імперія дає відсіч
dou.ua/forums/topic/43717

Як на мене, Rust обирають більше через concurency та ADT. Якщо у нас сума типів, то компілятор сам вкаже, які ситуації в нас необроблені. Якщо у нас ООП та сума реалізується через наслідування, то є проблема ієрархії, також дуже часто ти просто забуваєш подумати про якийсь можливий варіант.

Це не однозначна перевага над наслідуванням на классах насправді. Тому що поведінка інкапсульована в классах, а не pure фунціях. Тому росширити ооп наслідування набагато легше там де є взаємодія обʼєктів і логіка з цим повʼязана — достатньо перезавантажити метод при наслідуванні, а в adt треба іти і оновлювати всі місця в коді де цей union зачепили в різних місцях програми або defaultити ці кейси(що з точки зору безпеки типів просто вирубить перевірку компілятора в цьому місці на union type цьому).

Ну... с точку зору безпеки та коректності коду, як на мене, це перевага. Так, ООП дозволяє кодити швидше, але контроль втрачається. Як на мене, то у разі доробки простіше пробіжатися по всім можливим кейзам, та переконатися у тому, то ти нічого не пропустив, та ручками прописати кожну дію, ніж обрати клас та розраховувати на «замовчення», доки межконтинентальна ракета, яка унаслідована від літака, одного разу не скаже «нельотна погода, повертаюся на базу».

У adt може бути така сама проблема, тому щось десь в коді тисяч функцій хтось в pattern marching задефолтив обробку union case. Головна перевага ооп — в тому що поведінка і внутрішня логіка інкапсульована в тому самому классі. У випадку adt моделі свій біль — як організувати всю логіку у зовнішніх модулях по відношенню до моделі.

Звісно це не панацея. Якщо тільки не заборонити використовувати wildcards... Ну і взагалі, доки в тебе немає математичного доказу, код може містити помилки.

Але, мій поінт полягає у тому, що я не додаю нові класи у проект два рази на день, або розширюю базові ADT типи. Зазвичай така операція дуже ризикована з точки зору щось недогледіти. Тому мій особистий вибір, це отримати від компілятора якмога більше інформації щодо того, де нам треба прийняти рішення щодо поведінки. На відміну від ООП, де більшість таких рішень приймається автоматично. Тому якщо брати

росширити ооп наслідування набагато легше

, то так, я з цим згоден, але я більше дбаю про безпеку та хочу усі конфлікти обробити ручками.

Rust фінансово вигідний у довгостроковій перспективі із-за своєї надійності

Це як подивитись, потреба у такій мові давно назріла, але з мувами типу недавньої історії з копірайтами, я б на місці бізнесу обирав щось більш передбачуване.

Перед публікацією перевіряв число репозиторіїв з Rust у великих технологічних гігантів, зросло, тому вважаю зайве перейматись подібними огріхами

А спроби Rust for C++ Developers вже вважаються застарівшими.

Чому?

То такий гумор як й з COBOL

тому що цепепе головного мозку не виліковний у 99.9% випадків

у тебе травма з минулого що ти так ненавидиш с++ та плюсовиків? ))) або просто ти «ніасіліл»? :D

Певний час платили погано, суттєво гірше за Java та C#.

А, це ви, Айсман...

Ні, не витягуєш...

Підписатись на коментарі