Комментарии 6
Подписка от Oracle, по моему это уже не про РФ. Инструменты сборки проектов Java почти не развиваются, появился разве что Gradle. Но в Gradle ощущение, что настроек не уменьшилось, хоть и код там проще воспринимать чем в maven. Пытаются сделать Amper, это штука как раз и будет равняться на современные сборщики, но она я так понял чисто под Kotlin.
Короче говоря, порог входа в сборку и ведения проекта на Java до сих пор останется очень сложным, по сравнению со многими современными языками.
Не совсем понятно чем jar отличается от среды Python, при этом все можно упаковать в один исполняемый файл.
Вы написвли про var в Java 10, а я только недавно узнал, что в Java 15 добавили multi-line string. В свое время бесило это страшно. Но сейчас есть Kotlin, на котором гораздо приятней вести разработку по JVM, тем более с опытом разработки на Python
Про Spring AI забыли упомянть
Питон стал стандартом де факто в ДС и МЛ не потому что он прост и легко читаем, а потому что его синтаксис и возможности перегрузки операций позволяет эффективно записывать математические нотации и работать со всякими срезами. Ну типа matrix_a * matrix_b, или красиво делать слайсы list[1::], а не matrixA.mul(matrixB). Ну и там ещё куча всего, что позволяет писать крайне компактный и наглядный для математиков код . Т.е. грубо говоря, математик придумал какую-то теорию, быстренько написал на питоне нужный код и запустил его. Ему не нужно греть голову с ООП и прочими абстрактными фабриками адаптеров фабрик.
По поводу производительности. Тут видите какое дело. Никому эти тысячи РПС не нужны, потому что числодробилки банально не работают с таким количеством запросов. А производительность, которую абстрагирует питон на видяхи и прочие SIMD не идет ни в какое сравнение с классическим вычислением на ядрах процессора, хоть вы на ассемблере напишите. Это означает, что вы днем с огнем не найдете программиста на джаве, который бы забабах какие то вычисления на CUDA ядрах, да ещё и эффективно.
Вот в комментариях выше минут Spring AI и Tribuo - но это же, грубо говоря, инфраструктурные вещи, которые программист просто настраивает уже под конечные задачи. В питоне же библиотеки чисто математические.
То что на питоне не стоит писать большой интерпрайс - полностью согласен, всё таки лучше это делать на статически типизированных языках. Но ничего не запрещает вам создать микросервис к какой нибудь мл модели и вызывать его из других языков.
Я бы сказал, что JVM и Java - хоть и связанные, но разные животные. Есть и другие языки в экосистеме.
А вот питон - это не только читаемость, но и низкий порог вхождения. Им способен овладеть даже слабоумный. Именно то, что нужно людям, для которых нужен инструмент, чтобы создать модельку, не сильно вникая в язык. На мой взгляд, абсолютно нормальное желание, но вот вместо питона подошел бы какой-то другой узкоспециализированный DSL, заточенный именно на построение и тестирование моделей, а не на код.
Питон - это, в принципе, тоже DSL над C/C++/Java/Rust. Главная его цель в бизнесе - сделать много дешевых программистов, даже если для этого придётся пожертвовать качеством.

Java против Python: Призрак с LTS-подпиской стучится в AI