Может ли Раст полноценно заменить Джаву в сфере финансовых технологий?

Question

[VinVega]

Подходит ли Раст для написания всего того, что пишется на Джаве в финтехе? Например банковские веб-приложения, платежные системы и т.п.. Подходит ли он для написания бизнес-логики больших корпораций?
Чем он уступает Джаве в этих задачах?

Answer 1

[Василий Банников]

На Java пишется очень много разных вещей, в тч не требовательных к утилизации ресурсов и задержкам так что предположу, что многие вещи просто нецелесообразно переписывать.

Кроме Java в финтехе вообще много разных языков используется. Даже такая экзотика как Haskell и F# бывает.

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

Раньше примерно то же самое писалось на плюсах.

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

Comments

[VinVega]

А каким образом вы бы комбинировали Джаву и Раст, если бы, скажем, разрабатывали банковское веб-приложение? Или их не стоит совмещать вовсе?

[d-stream]

VinVega, собственно современные тенденции микросервисности - это микросервисы, сцепляющиеся между собой по тем или иных рестообразным протоколам либо шинам сообщений (кафки, раббиты и т.п.). И в этом плане сервису А абсолютно до лампочки на чём написан сервис Б и на чём его перепишут завтра. Больше того - сервисов Б (как собственно и А) скорее всего будет много и ничего не мешает каждому экземпляру быть написанным на своём языке (ну если амбиции например перевесят здравый смысл))

[Василий Банников]

VinVega, ну вот как d-stream написал)

[VinVega]

d-stream, спасибо

[Сергей]

Василий Банников, тоже думали на Rust писать критический сервис, но потом руководство решило взять Go. Мол, для веба лучше и быстрее нет.

Answer 2

[Сергей Горностаев]

Нет. У них разные области применения. Java проектировалась именно как предельно простой и лёгкий для восприятия язык, максимально препятствующий выстрелу в ногу. Никогда этим параметрам не будет соответствовать язык одновременно пригодный к системному программированию. И это не учитывая тот фактор, что инвестиции в переписывание всего финтеха с Java на Rust потребуются больше, чем планетарный ВВП.

Comments

[VinVega]

Но Rust, насколько я знаю, ведь тоже является языком препятствующим выстрелу в ногу - он же безопасен (p.s. поправьте если не прав).
Как я понял, вы считаете и новые финтех-приложения на нем тоже не целесообразно писать?

[Сергей Горностаев]

VinVega, он безопаснее, чем C или C++, но не опаснее, чем Java. И он намного сложнее. Так что писать на нём имеет смысл только отдельный небольшие части систем, критичные к потреблению ресурсов. То есть то, что сейчас в банках пишут на C++.

[VinVega]

Сергей Горностаев, большое спасибо!

[mayton2019]

Я полностью согласен с Сергеем с оценкой стоимости разработки. И тут может быть дело даже не в плантарном ВВП а просто в мотивациях. Никто не сможет провести подобный эксперимент.
Проще наверное выписать табличку сходных по функционалу проектов и сравнивать их
backlog и стоимость разработки и поддержки. Взять например Rocket и Jetty. Сколько стоит
запихнуть новую фичу? Исправить баг? И прочее.

Answer 3

[Dmitry Roo]

На сколько я знаю, на сегодняшний день у раста проблемы с интеграциями. Брошеные либы, зависимости от версии и платформы и вот это все... (я рад бы ошибаться, возможно, г-н Василий Банников меня поправит).
В джаве же есть спринг-бут, который умеет интегрировться хоть с чертом лысым, при этом поддерживается, развивается, выходят новые версиии...
В большом энтерпрайзе это важно.

Ну и у джавы, нерешаемых проблем довольно мало, чтобы от нее отказываться. На рынке есть много персонала разной квалификации, JVM - прекрасная, развивающяяся платформа.
На расте же писать никто не умеет (по сравнению с джавой), не понятно какие у технологии перспективы, есть вышеуказанные проблемы. Чем он может заинтересоваться большой бизнес?
Производительностью? Так и jvm достаточно производительна, во-первых, а во вторых, есть куча приложений, для которых никакой хай-лоад и никакое лоу-латенси не предусмотренно...

Comments

[VinVega]

Спасибо!

[Сергей Горностаев]

Даже в случае хайлоада в энтерпрайзе популярна позиция типа "Написать надо быстро и просто, производительность не нужна, просто выделим ещё стопицот жирнючих серверов."

[Орхан Гасанлы]

Ну и GraalVM тоже никто не отменял в случае Хайлоада.

[Василий Банников]

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

А в Rust есть tokio - по сути уже экосистема всего что связано с асинхронщиной. Там есть tower как основа для реализации middleware в других фреймворках и Axum - фреймворк для разработки бэкенда.
При этом с tower совместимо ещё много других фреймворков помимо Axum.

На расте же писать никто не умеет (по сравнению с джавой)

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

[Dmitry Roo]

Василий Банников, как бы вы оценили текущую ситуацию с поддержкой баз данных (sql/nosql), брокеров сообщений, кубернетесов, азуров, авс-ов, и т.д.?
Насчет инетереса к расту - у меня похожие впечатления.

[Василий Банников]

Dmitry Roo, мне кажется, уже достаточно хорошо всё такое развито.
Тот же Axum например умеет подрубаться к AWS Lambda - задержки и холодный запуск будут сильно лучше, чем в случае с другими языками. Да и денег потреблять такое решение будет меньше.

По базам данных и брокерам - все крупные и востребованные поддерживаются. Может немного сложно будет со всякими MSSQL, Oracle, DB2 и прочими проприетарными решениями.
Слава богу что их всё меньше и меньше применяют.

Эффективная сборка в Docker возможна (с кэширование слоёв), но не тривиально, благо Docker уже из коробки поддерживает Rust и генерит хороший Dockerfile.
(Вот кстати: Почему в Docker собирается не тот Rust?)

[Roman K]

Чем он может заинтересоваться большой бизнес? Производительностью?

Безопасностью же

[Dmitry Roo]

Roman K, Безопасностью? Давайте тут поподробнее

[Dmitry Roo]

Василий Банников, когда я работал в последний раз в банке, там в основном были oracle, db2, mssql))

[Василий Банников]

Roman K, безопасность и в Java есть и как уже не в одном ответе пишут - Rust скорее конкурент C++.

Кроме безопасности тут ещё и дешевле разработка/поддержка.

[Василий Банников]

Dmitry Roo, ну сейчас активно от oracle в пользу postgres идёт отказ благодаря санкциям)
(Вот уж где они реально на пользу)

Любые новые проекты сразу на pg

[Roman K]

Василий Банников, я не эксперт в джаве (тем более, последних версий), но достаточно ли её системы типов для конкуренции с растом в безопасности? Например, есть ли exhaustiveness checks, adt, можно ли переходы fsm выразить в системе типов и невалидные переходы ронять на этапе компиляции? Конечно я не про безопасность уровня памяти.

FYI Dmitry Roo

[Василий Банников]

Roman K, в Java есть null, исключения, наследование, вроде есть adt, но при этом одновременно всё ещё существуют обычные енамы без проверок на exhaustiveness.

И в принципе вроде как нет инструментов, чтобы внести новые проверки на этап компиляции.
К примеру в Rust есть sqlx который валидирует SQL ещё во время компиляции. Такого в Java я не видел никогда.

+ ковариантные массивы.

[Сергей Горностаев]

Roman K,

есть ли exhaustiveness checks

Есть. Правда, пока в статусе preview, то есть в следующих релизах детали поведения могут меняться.

adt, можно ли переходы fsm выразить в системе типов и невалидные переходы ронять на этапе компиляции

Это не Scala, конечно, но тоже есть. Вот только энтерпрайз как раз хочет, чтобы не было. Например и Сбер, и Тинёк немало скаловых проектов перетащили на Java.

Answer 4

[Saboteur]

Раст же вроде планируется как замена С/С++ и является более низкоуровневым.
Ему прямой путь в системное программирование. А финтех это немного другое

Comments

[Василий Банников]

Будто в финтехе не бывает системного программирования

[Saboteur]

Василий Банников,
Сколько там системного программирования в процентах?
Прошивка в банкоматы? и то вряд ли.

[Василий Банников]

Saboteur, не ноль. Этого в принципе достаточно.
1. А что инфраструктуры нет больше? Или вдруг крупные компании перестали себе инфраструктуру велосипедить?
2. Есть всякие штуки (HSM-ы например), с которыми общение идёт с их собственным бинарным протоколом.

Хотя может я неправильно воспринимаю термин.

[Saboteur]

Василий Банников,

не ноль. Этого в принципе достаточно.

Недостаточно.
Вопрос звучит как "полноценно заменить java".
java, это не инфраструктура и не системное программирование. Это как раз в основном аппликейшн и бэкенд, и зачастую в финтехе джава это процентов 50 и выше

Answer 5

[mayton2019]

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

Comments

[VinVega]

спасибо!

Answer 6

[GavriKos]

Любой язык, который является NP-полным, подходит. А вот может ли замениьт это вопрос другой.

Answer 7

[Roman K]

Да, может и, вероятно, заменит. Уступает очень крутой кривой обучения на старте

Comments

[Сергей Горностаев]

Пусть сначала Кобол попробует заменить.

[Roman K]

Сергей Горностаев, чего там пробовать? Дождаться, пока оставшиеся 1.5 землекопа уйдут на пенсию?)

[Сергей Горностаев]

Roman K, ну, ждите ) Уже вижу, как мировая финансовая система решает потратать пару-тройку триллионов долларов с нулевым коэффициентом возврата инвестиций.

[Дмитрий Кинаш]

Сергей Горностаев, заменить можно, но точно не на Раст!
https://apptractor.ru/develop/ibm-predlagaet-ii-dl...

[Roman K]

Сергей Горностаев, если мировая финансовая система не переписала что-то на коболе, значит, оно и так работает и его не нужно поддерживать. А если оно просто работает, то какая разница, что там сбоку?

[CityCat4]

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

[Сергей]

Rust - это замена С++. И то неполная. В некоторых областях пока что. Полной может и не станет вообще никогда.

[Сергей]

CityCat4, не заменит полностью. Никто не станет вкладывать кучу денег в переписывание миллионов программ на плюсах. Новые проекты, да, заменит в будущем.

Answer 8

[Владимир Коротенко]

Нужно понимать логику развития языков.

С создавался что бы переносить программы между компами
С++ что бы делать большие программы
Java - что бы не иметь проблем с памятью
C# - Мы поругались с SUN и запилим свою яву с куртизанками и казино (вышло кстати клево)
Rust - ну типа мы для тупых программеров C++ добавим Jail

Вот примерно так. В итоге остается Java и C# это стандарт, типа красной и синей пилюли

Comments

[Василий Банников]

Rust - ну типа мы для тупых программеров C++ добавим Jail

Как-то сильно поверхностно. Я бы скорее сказал, что Rust по сравнению с C++ делает следующее:
1. Вносит в язык такие фичи, с помощью которых можно тривиально на этапе компиляции проверять на много разных очевидных или не очень ошибок
2. Убирает всё наследие из синтаксиса, которое накопилось за полвека.
3. Вносит минимальное количество фич в синтаксис, чтобы при этом:
а) Эти новые конструкции можно было использовать для большого количества разных вещей
б) Эти конструкции не противоречили друг другу.

Вот например есть в Rust енамы. С помощью них можно:
1. Использовать их как собственно самые обычные сишные енамы
2. Делать безопасные union-ы
3. Они заменяют собой null
4. На них строится вся обработка ошибок
5. С помощью них можно делать более безопасные абстракции (вот уже упомянули в соседних комментах FSM, корректность переходов которой гарантируется при компиляции).
6. Их можно использовать там, где возможно в C# или Java захотелось бы использовать наследование.

И это ещё не предел. И так со всеми фичами - если что-то вводится как синтаксис, а не как макрос, то это можно использовать для множества разных вещей. По этой же причине в Rust просто нет тернарного оператора и двух switch-ей как в C#.

[Сергей]

Из Java и C# энтерпрайз чаще всего (особенно в России) выбирает Java.

[Владимир Коротенко]

Сергей, У вас видимо и статистика есть? Если вы так говорите?
Энтерпрайз выбирает то что лучше подходит и зачастую там и то и то и третье и куча другого

Answer 9

[Пума Тайланд]

Да тут вопрос только выбора и умений поддерживать
Да и с чего вы взяли что финтех пишут только на Джан у нас он на рельсе и го

Answer 10

[Сергей]

Сколько уже было убийц Java/JS/C++? Да всё без толку. Java/JS/C++ также остались монополистами в своих областях.