Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 35
Забавно, в США наоборот, банки используют 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
Это “сейчас” настало задолго до твоего начала разработкой.
Замечание справедливо, но не имел в виду что lombok появился недавно, хотел сказать, что в современной java разработке boilerplate часто закрывают ombok/records/ide generation, но в enterprise всё зависит от версии java и правил конкретного проекта.
в современной java разработке boilerplate часто закрывают lombok/records/ide generation
Ну как в "современной"... Некоторые эти инструменты (ide generation) были ещё в 2008.
Что ide generation существует давно, согласен. Более точная формулировка "в текущей Java практике есть несколько способов уменьшить boilerplate ide generation, lombok, records."
Но для статьи это второстепенная деталь. Основная мысль была в том, что в enterprise многое зависит от версии Java, правил проекта и соглашений команды.
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 .
Чисто из любопытства: а зачем оно в НЕТе?
Чтобы использовать типовые подходы обработки данных, которые наработаны в 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 проще ложится на выбранную инфраструктурную стратегию и уже существующие процессы.
Знакомая история. Пришёл в финтех с .NET-бэкграундом — через полгода читал про Spring Boot, потому что все интеграции с процессингом, АБС и регулятором были на Java. Не потому что лучше — просто «так исторически сложилось» и «вендор поддерживает только JVM». Язык выбирает не разработчик, а легаси и оргструктура. Обидно, но честно.
В двух словах: у нас в банке на джаве пишут, на шарпе не пишут. Поэтому писал на джаве, вот
Статья - сплошной нейрослоп
А могла выйти хорошая статья, но столько воды от нейросетей, что под конец тонешь)
Не раскрыто вообще ничего, например, в чем проблема новые сервисы стартовать на дотнете, весь девопсовский обвес индифферентен к технологии бэка, они уже давно видят только образы. И все остальное, вроде otel.
С точки зрения контейнеров, otel, пайплайнов и деплоя .net и java действительно во многом равноправны. Здесь как раз нет принципиальной проблемы, современный .net нормально живёт в linux/контейнерах.
Но я и не писал что новые сервисы технически нельзя стартовать на .net. Вопрос в другом "какие стеки уже согласованы внутри организации, какие есть команды, шаблоны проектов, библиотеки, требования иб, экспертиза и кто потом будет это сопровождать".
То есть выбор стека в enterprise обычно шире чем "runtime + devops обвязка", devops может видеть образ, но организация всё равно видит людей, процессы, стандарты и стоимость поддержки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
C# мне нравится больше Java. Но в банковском enterprise мне всё равно понадобилась Java