Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Забавно, в США наоборот, банки используют C#. По всем тем-же самым причинам, которые вы озвучили про Джаву. :)
Правда там в банках очень много дремучего легаси на старом до-core дотнете, поэтому народ туда не особо стремится.
Согласен, тут как раз видно что enterprise выбирает не "лучший язык вообще", а стек вокруг которого уже сложились legacy, команды, инфраструктура и процессы.
Описывал свой контекст: банковский enterprise, Java/Spring, Linux-контуры и требования к унификации стека. В США или в другом банке та же логика вполне может работать в пользу .NET
И старый до-Core .NET конечно лучше не смешивать с современным .net, это уже отдельный пласт legacy :)
Я думаю перейти с C# на развитие уже зрелого, хорошо документированного Java-проекта не составит труда. Подходы знакомые, вы правильно подметили, ибо .NET развивался подглядывая за Java и беря оттуда лучшее. Другой разговор - это если надо начать проект на Java с нуля. В .NET есть столбовая дорога Visual Studio, ASP.NET, EF... - это всё уже есть из коробки, продуманные, документированные и вылизанные до блеска решения.
В Java как сейчас дела обстоят - не знаю, но когда-то давно пытался вкатиться в мир Java-разработки и на каждом шагу были какие-то грабли, начиная c выбора среды разработки. С тех пор испытываю некое отторжение к Java и стараюсь держаться подальше, но это уже личное.
Согласен, поддерживать зрелый java/spring проект и начинать новый с нуля это разные истории.
В .net сильнее ощущается "столбовая дорога" asp net, ef, tooling, понятный набор типовых решений. В java выборов больше и если проект уже зрелый, эти решения за тебя в основном приняты. А вот на старте можно закопаться не в бизнес задачу, а в выбор ide, сборки, orm, конфигурации и соглашений.
У меня переход был именно в существующий enterprise контекст, поэтому он не ощущался болезненным. Если бы пришлось стартовать java проект с нуля возможно впечатления были бы другими.
Около пяти лет занимаюсь разработкой … сейчас есть Lombok
Это “сейчас” настало задолго до твоего начала разработкой.
Ну что, перед нами классический манифест капитуляции инженера перед корпоративной неповоротливой машиной, завернутый в обертку зрелого прагматизма. Автор пытается оправдать переход с C# на Java объективными факторами инфраструктуры, безопасности и долгосрочной стратегии. Но эта логика рассыпается в пыль, как только мы посмотрим на нее через призму реальной эффективности железа, стоимости и современных вызовов. Если бы архитектурные комитеты банков действительно выбирали стек на основе инфраструктуры, безопасности и долгосрочной стратегии, они бы бежали от Java/Spring дальше, чем видят. И целевым стеком становился бы Rust, а для аналитики и данных, AI-контуров — Mojo. Миф от автора Java идеальна для Linux-инфраструктуры и контейнеров. Реальность, Типичный микросервис на Spring Boot в Docker-образе весит по 400–600 МБ, запускается по 30–40 секунд (пока рантайм через тяжелую рефлексию распарсит тонны аннотаций) и сразу после старта жрет от 1 ГБ оперативной памяти вхолостую. В масштабах крупного банка, где крутятся тысячи таких микросервисов, организация юудерт платит миллионы в год за облачные кластеры просто для того, чтобы кормить прожорливую JVM. Как должно быть и происходит правильно:Микросервис на Rust компилируется в один плоский бинарник размером в 20–30 МБ, стартует за миллисекунды и потребляет 15–30 МБ RAM под нагрузкой. Для CI/CD пайплайнов и утилизации железа Rust экономит до 90% затрат по сравнению с тяжелым JVM-болотом. Второй миф автора: Банковская безопасность требует стандартизации на Java. В реальности: Java тащит за собой чудовищную экосистему легаси-библиотек. Настоящая безопасность памяти (Memory Safety) в Java,это иллюзия, зависящая от рантайма и подверженная вечным утечкам из-за кривого маппинга в Hibernate. Недетерминированное управление памятью (Garbage Collector) не позволяет гарантированно затирать сессии и ключи в RAM в ту же секунду, когда они стали не нужны. Как это решают сейчас в ответственных мьруктурах и инженеров:В Rust безопасность памяти гарантирована на уровне компилятора (ownership/borrow checker). Никаких NullPointerException, никаких уязвимостей типа double-free или утечек. Rust уничтожает целый пласт критических уязвимостей ИБ до того, как код вообще попадет в CI/CD. Еще автора:Стратегия банка — это просто гонять данные через Kafka и писать в БД. Реальность:Современная долгосрочная стратегия любого крупного финтеха завязана на AI/ML модели, скоринг, антифрод в реальном времени и обработку данных с ультра-низкой задержкой (low-latency). Java здесь абсолютно бессильна. Весь Data Science сидит на Python. Банкам приходится городить архитектурных монстров: собирать данные на Java, отдавать их в Python-сервисы, а потом возвращать обратно, теряя тайминги. Как делают правильно: Использование Mojo. Стек, который дает синтаксис Python, но компилируется в чистый машинный код с производительностью C++/Rust, нативно работая с GPU, векторами и тензорами. Вот это и есть современная стратегия. Сквозной стек от обучения моделей до их моментального инференса в жестком продакшене. Автор сами в таблице наглядно показал техническую боль C#-иста, вынужденного пересесть на Java, хоть и попытались её сгладить: Стирание типов в рантайме (Type Erasure) в Java-генериках после нормальных generic-типов .NET — это шаг назад. Напишите кастомный высокопроизводительный компонент для бинарных протоколов на Java без лишних аллокаций в куче — устанете собирать грабли. Stream API после цельного, глубоко интегрированного в компилятор LINQ (который в EF транслируется в чистый SQL) выглядит как костыльный синтаксический сахар поверх старых итераторов. АсинхронностьЮ в .NET модель async/await монолитна и нативна. В Java enterprise годами мучился с зубодробительной реактивщиной (WebFlux), где стек-трейс ошибки занимает 5 страниц, а теперь судорожно пытается прыгнуть в сырые Virtual Threads (Project Loom). По итогу денивый и жадный банковский Enterprise выбирает Java не потому, что она объективно лучше для безопасности и инфраструктуры, а потому, что их конкретно корпоративная машина слишком неповоротлива и ленива, чтобы внедрять по-настоящему эффективный, безопасный и быстрый технологический стек. Менеджменту проще штамповать спринговиков на кадровом конвейере после трехмесячных курсов, которые умеют только обвешивать классы аннотациями @RestController. А всю техническую неэффективность кода, просадки по памяти и лаги рантайма банк просто бездумно бкдет заливать деньгами, закупая новые стойки серверов. Это не стратегия, это расписка в неспособности построить гибкую инженерную культуру. Автор прав только в том, что разработчик в банке, это винтик. Но не нужно называть вынужденный компромисс с неповоротливой системой и ленью, объективной полезностью инструмента.
rust и low-latency стек, сильный аргумент для отдельных классов задач, с этим не спорю.
Но статья была не про "лучший стек в вакууме" а про то, как выбор технологий выглядит внутри большого enterprise: legacy, команды, найм, сопровождение, регламенты, аудит, стоимость миграции и эксплуатация.
Я не утверждал, что Java идеальна. Скорее наоборот, это компромисс. В крупных банковских системах компромисс часто выбирается не по максимальной эффективности рантайма, а по способности организации поддерживать стек годами.
Технически можно придумать более эффективный стек, но внедрить и сопровождать его в большом enterprise это уже отдельная задача и часто намного сложнее чем выбрать самый быстрый runtime.
Начнём с того, что rust слишком свежий язык программирования для банковской сферы. Немаленькая часть ПО была написана очень давно (примерно тогда, когда этот язык вообще появлялся), сейчас это нужно тупо поддерживать. Для нового - да пожалуйста, используйте, никто в технические рамки (за исключением, возможно, руководства) не вводит.
Все озвученные вами минусы всё ещё более предпочтительны, чем затраты на полное переписывание ПО на "модный" язык.
И небольшое отступление. Раз уж заговорили про новые версии, то там есть кучка оптимизаций, которые нивелируют некоторые из минусов (например, project Valhalla призван снизить нагрузку на оперативу и т.д.) - довести проект с условной Java 11 до Java 21 (а то и 25/26) будет дешевле.
Как раз это близко к мысли статьи, в enterprise почти никогда нет чистого листа. есть legacy, команды, инфраструктура, регламенты и стоимость миграции.
rust может быть отличным выбором для новых low latency компонентов, но переписать на него большой банковский backend это уже не оптимизация, а огромный проект с отдельными рисками.
Обновление java до более свежих версий выглядит куда реалистичнее чем замена всей платформы.
Гпт, промокни эту воду полотенчиком и покажи что осталось
Я кодил на шарпе, мне дали жава спринг бут, на нем тоже могу
Ниче не понятно, хотя тема интересная. В статье нейрослоп перемешан с личным мнением, начинаешь прокручивать нейрослоп и теряется вообще вся суть. Можете по-нормальному переписать?
Если убрать оценочные формулировки, суть статьи довольно простая, переход с c# на java/spring boot сам по себе не является самой сложной частью, если уже есть back опыт.
Основная мысль была в другом, в enterprise стек часто выбирается не только по удобству языка, а по инфраструктуре, legacy, командам, регламентам и сопровождению.
Если есть конкретный фрагмент где мысль теряется, можете указать предметную критику всегда полезно разобрать.
Вообще, это забавно и печально одновременно - как в одно идиотское политическое решение cделать .Net только под Windows, до сих пор не дает, технически куда более зрелому и совершенному .Net(C#) обойти Java(JVM) исключительно по политическим причинам. Один раз упустили, а потом все по привычке будут делать все только на Java.
Второй забавный момент - изначально именно Java/JVM делалась как инструмент под все платформы-задачи а сейчас все наоборот, C#/CLR - хороший инструмент для решения практически любой задачи, в то время как Java/JVM в подавляющей доле это инструмент написания корпоративного backend и практически ничего более.
Да, историческая инерция тут сильно влияет, у .net долго был шлейф windows экосистемы, хотя современный .net уже совсем другой linux, контейнеры, высокая производительность и нормальная кроссплатформенность.
Но enterprise меняется медленно, если технология годами воспринималась определённым образом, это ещё долго влияет на найм, архитектурные решения и внутренние стандарты.
Сейчас c#/clr действительно выглядит гораздо универсальнее чем его часто воспринимают по старой памяти, а java/jvm при этом остаётся очень сильной именно в корпоративном back где вокруг неё накопилось много практик и команд.
Из минусов шарпа - это отсутствие популярного ORM фреймворка, реализующего спецификацию JPA .
Из плюсов шарпа, которые не упомянул автор, это возможность помечать как сам класс, так и его элементы - методы/поля/свойства, классами-аттрибутами. Потом при помощи рефлектора можно через обработку аттрибутов работать с контентом такого классом или иерархией таких классов в нужном ключе. Это мощнейшая функциональная возможность, о которой почему-то редко упоминают в публикациях. Пользуюсь таким функционалом давно и практически во всех проектах. Даже есть небольшой ORM фреймворк для случая, когда EF избыточен в проекте.
Про attributes хороший пункт, это действительно сильная сторона c# удобно вешать метаданные на классы/свойства/методы и потом через reflection строить валидацию, маппинг, сериализацию, lightweight orm или внутренние соглашения проекта.
По jpa тоже согласен в .net есть ef core, dapper, nhibernate и другие варианты, но прямого аналога именно как общей enterprise спецификации вокруг orm нет, там чаще выбирается конкретный инструмент под задачу а в java подход более стандартизирован.
Из минусов шарпа - это отсутствие популярного ORM фреймворка, реализующего спецификацию JPA .
Чисто из любопытства: а зачем оно в НЕТе?
Вы пишите: "...Основной причиной был не технический провал C#, а движение в сторону импортозамещения...". Я понимаю, что Microsoft ушла из России, но ведь, вроде, современный dotNet распространяется по лицензии MIT: "делай с исходниками, что хочешь, только не забудь упомянуть лицензию". Если не принимать во внимание легаси на Java, то в чём опасность использования C# в российских банках (да и в госструктурах)? Можно же проверить исходники на всякие бэкдоры и т.п. В крайнем случае, если Microsoft опять вернет проприетарность новым версиям dotNet, можно же будет (наверно) развивать форки предыдущих версий dotNet ? А вообще, если честно, не совсем понятно - а что значит, по своей сути, импортозамещение языка программирования? Как понимаю народ пользуется всякими Java, Rust, Go, Nim и прочими; но, так ведь, все эти языки созданы за бугром, о каком импортозамещении тогда идёт речь?
Я бы не называл это "импортозамещением языка" в буквальном смысле, очевидно что java, c#, go или rust тоже не российские языки.
Речь про импортозамещение инфраструктурного контура ОС, СУБД, middleware, ci/cd, мониторинг, support, сертификацию, внутренние стандарты и снижение зависимости от конкретных вендоров.
Современный .net действительно open source и нормально работает на linux поэтому я не считаю c# технически опасным или непригодным, но в некоторых enterprise контурах java/spring проще ложится на выбранную инфраструктурную стратегию и уже существующие процессы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
C# мне нравится больше Java. Но в банковском enterprise мне всё равно понадобилась Java