Что сейчас можно на JVM

Я вообще твоего вопроса не понял.

scala

Скала?

Java ван лав [/thread]

Свитчер попортил тему. Вопрос: «Какие языки сейчас лучше использовать на JVM и почему именно их (кроме Java)?»

использовать на JVM

Котлин и джава? Да и то первый сначала в джаву компилится.

Котлин

А что там с нативной версией?

Да и то первый сначала в джаву компилится.

Wat? И то, и то компилится в JVM байткод.

Wat? И то, и то компилится в JVM байткод.

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

Scala вроде как умеет в native (а ещё в js), хотя не уверен, насколько это стабильно и готово.

Фактически в проде только Java и Kotlin, Scala была умеренно популярна несколько лет назад, сейчас её практически не встретишь.

Есть GraalVM, на нем запилили уже поддержку Python, JS и пр. Но в проде тоже не видел.

Ну так-то котлин тоже может, что в js, что в native. Да и яву тоже можно граалем в нативный код скомпилить.

Можно грабить корованы.

clojure

https://dev.to/markm208/series/12289

Не туда смотришь. Рановато scala хоронить. Разве что после 3.0…

Groovy, Scala, Clojure, Kotlin.

Groovy

Про груви инфа сотка? Я думал, что оно сдохло. Три остальных уже завоевали себе бессмертие, а вот по груви даже не знаю.

Scala 3

Ну последний релиз год назад был. Хайпу особо нет, но по сути в своей нише альтернатив ему нет (простой динамический ЯП для ЖВМ).

ЕМНИП, то скрипты на Gradle - валидные программы на Groovy. Аналогично с JMeter.

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

Почему? По-моему ничего лучше Java пока не придумали. Разве что Rust хорош, но всё же ниша c Java не особо пересекается. Всё остальное строго хуже.

По-моему ничего лучше Java пока не придумали

Go.

Go неимоверно убог, как язык. И реализация оставляет желать лучшего.

Apache Netbeans 12.3 недавно вышла. Если скачать zip-архив, то из коробки доступна разработка сразу на популярных ЯП, поддерживаемых JVM (правда, некоторые удивятся).

Перед тем, как запускать, в файле конфигурации etc/netbeans.conf найдите строчку и отредактируйте путь к каталогу (open)jdk. Остальное - в настройках самой среды.

Go неимоверно убог, как язык

А типа Java не убога? И JVM, для которой нельзя написать байткод так, чтобы он сразу был оптимизирован, без необходимости JIT-компиляции. Причем, эту же ущербность унаследовал CLR.

А типа Java не убога?

Нет.

И JVM, для которой нельзя написать байткод так, чтобы он сразу был оптимизирован, без необходимости JIT-компиляции.

Ничего не понял. JVM оптимизирует байткод под конкретный процессор, причём с учётом статистики выполнения конкретной программы. Как его можно «сразу» оптимизировать?

Но таки можно, AOT-компиляция в Java уже сто лет есть, вариантов полно. Модный-молодёжный это Graal. Ну и Android, естественно, там Java не на 100% настоящая, но в целом можно считать, что так.

Причем, эту же ущербность унаследовал CLR.

Write Once, Run Anywhere это не ущербность, это очень круто.

А типа Java не убога?

Нет

Ну в новых версиях, с лямбдами и примитивным выводом типов, еще более-менее терпимо. Про старую же лучше не вспоминать. А простой возврат сложных типов завезили? Перестали уже под каждый простецкий тип данных из двух полей делать отдельный файл c классом на 20 строчек? Да. Go тоже не фонтан, но по простоте-чистоте он жаву уделывает.

JVM оптимизирует байткод под конкретный процессор, причём с учётом статистики выполнения конкретной программы. Как его можно «сразу» оптимизировать?

Под конкретный процессор можно и AOT оптимизировать. Но не в JVM. Потому что когда у тебя выполнение раздроблено на мелкие контейнеры, мельче, и еще мельче — там уже не ясно, кого инлайнить, кого скаляризовать, кто уйдет из локального контекста, а кто — нет. И самый большой камень преткновения — это виртуальные методы с интерфейсами. Из которых сделана вся стандартная библиотека. И волшебные обобщения через стирание типов, которые дают еще меньше подсказок для оптимизитора. Как ни странно, эти проблемы роднят Java с такими языками, как JS, Python, Lua.

Единственный способ — это выполнить программу хотя бы разок, и надеяться, что второй раз она будет выполняться так же и не придется выполнять резервную неоптимизированную версию кода из-за того, что при выполнении поменялась фабрика. Ну или же выдавать сразу неоптимизированный код с кучей переходов по vtable, который будет бегать раза в два медленнее JIT-компилированного.

Но таки можно, AOT-компиляция в Java уже сто лет есть, вариантов полно. Модный-молодёжный это Graal

Только кто им пользуется? В принципе, они в 19.2 ввели profile-guided optimization (PGO), которая по производительности выдает немногим меньше JIT:

https://res.infoq.com/presentations/graalvm-performance/en/slides/sl19-156381...

То есть, PGO быстрее ровно до тех пор, пока JIT не сгенерирует более оптимальную версию кода под реальное исполнение, а не абстрактное профилирование.

Ну и Android, естественно, там Java не на 100% настоящая, но в целом можно считать, что так

Давай не будем о грустном. Сам гугл давным-давно хочет уйти от жавы.

Причем, эту же ущербность унаследовал CLR.

Write Once, Run Anywhere это не ущербность, это очень круто

Run anywhere ровно до тех пор, пока твоя приложуха не имеет GUI и вообще не общается со внешней системой, то есть, живет сама в себе. Есть два примера, когда на подобных VM смогли написать успешные GUI платформы — это виндовый дотнет и андроид. Естественный итог — эти штуки ни с чем не совместимы, до гип апушнеге там как до киева раком.

Есть два примера, когда на подобных VM смогли написать успешные GUI платформы

Сейчас просто десктопный софт уходит, но еще N лет назад зачастую в жабаконторах писали корпоративный софт под linux, а работал он в винде.
Я думаю что наличие мультиплатформенного UI toolkit одна из причин успеха java в энтерпрайзе. Swing под виндой выглядел очень нативно. Под linux MotifLookAndFeel выглядел не очень но работал отлично, а вот на GTKLookAndFeel что-нибудь съезжало, но под windows все было отлично. Пользователи отправляли нам баги со скриншотами, и я вообще не помню проблем с лейаутом и swing.
В нашем случае приложение было тонким клиентом на машинах пользователя с бекенд хостящимся на linux или solaris.

А еще я java видел как пользователь пользуясь банком как ИП/ФЛП, через банковский апплет (позднее webstart) ставил токеном электронную подпись на платежках.

Но теперь наверное это уже дни метнувшего прошлого. На прошлой работе писал банковский софт, все в броузере крутилось. Java там была только на backend. Для подписи доков пользователями использовали крипто-про, тот еще монстр, я его не осилил поставить под linux, пришлось скачать с сайта крипто-про их версию chromium.

В нашем случае приложение было тонким клиентом на машинах пользователя с бекенд хостящимся на linux или solaris

Вот, тонкий клиент. А как только попытаешься сделать что-то в пределах локалхоста — вот и усё. По этой причине серверная индустрия перешла к модели «сделал контейнер один раз — можешь запустить на любом линуксе с той же архитектурой процессора».

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

Go это язык уровня Java 1.4. Только хуже, т.к. исключений нет. Go с шаблонами может быть дотянет до 1.5, но тоже не до конца, т.к. там всё равно останется «волшебство» со встроенными типами коллекций, невыразимое средствами языка.

Лямбды и вывод типов это ерунда, оно что есть, что нет, ничего не меняет.

Перестали уже под каждый простецкий тип данных из двух полей делать отдельный файл c классом на 20 строчек?

Посмотри на records, думаю, это то, что ты хочешь видеть.

Только кто им пользуется?

Лично я не пользуюсь, т.к. не вижу никакого смысла в таком подходе. Но кому-то нравится, вроде в твиттере всё на нём.

Run anywhere ровно до тех пор, пока твоя приложуха не имеет GUI и вообще не общается со внешней системой, то есть, живет сама в себе.

Чогой-то? AWT, Swing, SWT, JavaFX - вполне себе Run anywhere решения. Ну с мобилками забуксовало, да, но пока мы смотрим на десктопы, тут вообще проблем 0. Про файлы, сеть - всё это покрыто кросс-платформенным API, не знаю, что тебе ещё нужно от общения с внешними системами.

Есть два примера, когда на подобных VM смогли написать успешные GUI платформы — это виндовый дотнет и андроид. Естественный итог — эти штуки ни с чем не совместимы, до гип апушнеге там как до киева раком.

Мало приложений на свинге что ли? Я лично несколько штук писал. Прекрасно работает.

На экранах HiDPI всё по прежнему печально?

Не тестировал — HiDPI мало где есть. Тулкит Nimbus Look&Feel в Swing как раз для этого применения создан, поскольку он векторный, в отличие от предыдущих системно-независимых тулкитов.

Понял, спасибо, попробую.

Go это язык уровня Java 1.4. Только хуже, т.к. исключений нет.

Повеселил. Отказ от исключений — лучшее, что случилось с ЯПами со времён изобретения структурного программирования.

Отказ от исключений — лучшее, что случилось с ЯПами со времён изобретения структурного программирования.

Отказ от реализации сигнальной системы для борьбы с ошибками времени выполнения — это обречение программы от борьбы за собственную живучесть, а программиста — на выполнение дополнительных действий по повышению надёжности разрабатываемого ПО.

Отказ от исключений повлекли зарождение отвратительной архитектуры, с обработкой ошибки по месту и применением monkey patching, кучей if/else и прочей жести. Если это вы называете лучшим, что случилось с программированием за такое время - у вас очень с(т)ранные понятия о лучше. Скобки опциональны

А я считаю, что худшее. Если в случае Rust я это могу понять, т.к. у исключений нетривиальная цена и язык с бесплатными абстракциями может захотеть от них избавиться, то в случае любого другого языка это идиотизм чистой воды.

Простой пример, из мира frontend. Как раз таки не принято там работать с исключениями и во всех компонентах стараются городить свою ошибку. Вопрос, как SPA должно узнать об ошибке в компоненте где-то в глубине VDOM, если какой-то прекрасный человек сделал if/else и обрабатывает эту ситуацию по месту. Что делать, чтобы это обойти? React, для примера решают вот так (https://ru.reactjs.org/docs/error-boundaries.html) для декларативного вида. И таких вещей можно найти в приложении вагон а маленькую тележку. Дебаг становится прекрасным…

Go, Ada, C. А про жит и явоговно забудь.

Разрешаю ТС-у всё. Можно! :)

Если котлета компилируется в JS, какие фреймворки есть уже, задействующие данную возможность? Я еще GWT помню…

Лямбды и вывод типов это ерунда, оно что есть, что нет, ничего не меняет

Формально, на уровне байткода, действительно разницы нет. Но если по твоему судить, то ведь можно было бы на байткоде программы и писать? Да, код в текстовом представлении будет совершенно нечитаемым — но это не беда, у меня ведь есть IntelliJ Idea, которая поможет мне решить все проблемы. Но если подходить к вопросу трезво, то отсутствие лямбд и вывода типов сильно снижает читаемость текста программы, следствием чего является рост затрат на разработку и повышение частоты багов.

Посмотри на records, думаю, это то, что ты хочешь видеть

Да, совсем забыл про эту фичу. Еще лет через десять докинут наконец в язык ADT, расширят вывод типов, уберут из языка классы — и наконец на нем можно будет писать. Примерно по этому пути идет C#, к слову, перенимая кучу фичей из языка F#.

AWT, Swing, SWT, JavaFX - вполне себе Run anywhere решения. Ну с мобилками забуксовало, да, но пока мы смотрим на десктопы, тут вообще проблем 0. Про файлы, сеть - всё это покрыто кросс-платформенным API, не знаю, что тебе ещё нужно от общения с внешними системами

Run anywhere в реальной жизни работает, но плохо. Я имею в виду не просто «запустилось», а что-то делать на приложении, взаимодействовать с десктопным окружением и другими службами. Помимо того, что в системах есть некие общие фичи для тех же файлов и сети — но есть и различия. А еще есть какой-нибудь drag-n-drop, который с радостью сведет с ума разраба даже самого продвинутого кроссплатформенного фреймворка. Реально успешные решения, UWP/WPF и android, забили на кроссплатформенность и работают с одной конкретной платформой. Серверные микросервисы тоже забили и перешли к linux-only, да еще и stateless.

Попытка зайти с другой стороны, в виде Electron-а, получилась тоже унылой, и не загнулась она только потому, что гугл вкладывает чудовищный объем ресурсов для напичкивания своего браузера кучей мелких фичей, вроде доступа к контактам, микрофону, камере, для того, чтобы заткнуть эту брешь между родным приложением и вебсайтом. И все равно брешь большая, все-равно для более-менее родного поведения нужна какая-нибудь Cordova, которая будет выступать в роли родного Java приложения, передавая интерфейсы для приложения на веб-сайте.

Мало приложений на свинге что ли? Я лично несколько штук писал. Прекрасно работает

Не помню, когда последний раз работал с жава-приложением. Зато помню, когда последний раз работал с электроном и вебсайтами. Справедливости ради, успехом современная версия VS Code не в последнюю очередь обязана WebAssembly — турбореактивный парсинг сорцов сделан именно нем.

Отказ от исключений — лучшее, что случилось с ЯПами со времён изобретения структурного программирования

Ты забываешь, что программирование начиналось именно без исключений. Одним из первых исключения получил лисп, который немного из другой весовой категории. Первым же статическим языком с исключениями была Ada, которая, на мой взгляд, стала провальным языком. Потом уже этот подход подхватил C++, и за ними уже все кто ни попадя начали пихать исключения в свои ЯП. Что никак не отменяет существования языков без исключений.

Основная проблема с исключениями для статически комплиированных языков заключается в том, что если у тебя нет вывода типов, то тебе руками нужно описывать обработку исключений для каждого вызова функций — это можно сделать, и это таки делали в Си, но это весьма трудозатратно и сильно засоряет код. А для того, чтобы писать подобный код эффективно — нужны сложные полиморфные типы в возвращаемом значении, нужны RAII-подобные конструкции для того, чтобы не писать лишний раз руками высобождение и лесенки из условий (или goto). По-хорошему ведь тип возможной возвращаемой ошибки тоже нужно проверять статично, и не допускать из нашей функции вызова случайной функции, которая может выкинуть странную ошибку, которую мы не сумеем обработать.

Под виндой есть, пожалуй, единственное исключение, которое может потенциально выкинуть почти любая функция — это Access Violation. И она для приложения, вообще-то, значит только одно — немедленное завершение. Кроме случаев, когда некий вполне конкретный код с пониманием пытается разыменовать какой-то потенциально нулевой указатель, и сознательно перехватывает ошибку доступа по нулевому указателю. Сама же ошибка доступа по некорректному указателю в основном происходит из-за плохой безопасности работы с указателями в ЯП, на котором написана программа — а это еще один гроб в крышку гроба Си, потому что написать большую программу без ошибок работы с памятью на Си можно, но только если вы — господь бог.

Отказ от исключений — лучшее, что случилось с ЯПами со времён изобретения структурного программирования.

Отказ от реализации сигнальной системы для борьбы с ошибками времени выполнения — это обречение программы от борьбы за собственную живучесть

В каком месте отказ от исключений запрещает приложению бороться за свою живучесть? Ничего уже не хотите видеть за рамками привычного undefined-behaviour-driven development.

как SPA должно узнать об ошибке в компоненте где-то в глубине VDOM, если какой-то прекрасный человек сделал if/else и обрабатывает эту ситуацию по месту. Что делать, чтобы это обойти? React, для примера решают вот так (https://ru.reactjs.org/docs/error-boundaries.html) для декларативного вида. И таких вещей можно найти в приложении вагон а маленькую тележку. Дебаг становится прекрасным

Проблема тут даже не в том, что реакт решил проблему как-то не так. Проблему тупо в отладке, которую не получается делать штатными отладчиками так же удобно, как это делалось раньше. И это общая проблема вообще всех реактивных либ. Вот так вот напишешь на очередной реактивно-асинхронной либе что-то, а потом понимаешь, что вход — рубль, а выход — десять.

Более того, я пишу многозадачную обработочку, и внезапно сталкиваюсь с проблемой, что средств отладки онных почти нету. Вот никто не пишет приложения так, что они работают в виде нескольких тесно связанных процессов. Даже отладочный лог некуда вывести, чтобы потом можно было прочитать с четкой хронологией как по всем процессам, так и по каждому в отдельности. И, очень важно, отправка сообщения в лог должна иметь околонулевую стоимость для отправителя, без системных вызовов и переключений контекста — потому syslog сразу не подходит.

Буду благодарен, если кто-то подскажет тулзу логирования, которая бы отвечала этим требованиям. Целевая ОС, очевидно, Linux.

Это конечно всё здорово, но каким образом перечисленные «недостатки» jvm и в частности java делают go пригодным для чего-то кроме devops-са?

В каком месте отказ от исключений запрещает приложению бороться за свою живучесть?

Ответ во второй части моего предложения.

Формально, на уровне байткода, действительно разницы нет. Но если по твоему судить, то ведь можно было бы на байткоде программы и писать? Да, код в текстовом представлении будет совершенно нечитаемым — но это не беда, у меня ведь есть IntelliJ Idea, которая поможет мне решить все проблемы. Но если подходить к вопросу трезво, то отсутствие лямбд и вывода типов сильно снижает читаемость текста программы, следствием чего является рост затрат на разработку и повышение частоты багов.

Для меня лямбды это синтаксический сахар над анонимными классами, которые в Java были почти всегда. А вывод типов это вообще спорная фича, в какой-то мере противоречащая основам Java (например var l = new ArrayList() даёт переменную типа ArrayList, хотя любой Java-ист написал бы List l = new ArrayList<>).

Да, совсем забыл про эту фичу. Еще лет через десять докинут наконец в язык ADT, расширят вывод типов, уберут из языка классы — и наконец на нем можно будет писать. Примерно по этому пути идет C#, к слову, перенимая кучу фичей из языка F#.

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

Run anywhere в реальной жизни работает, но плохо.

То-то каждый суслик нынче на электроне клепает аппы и пофиг ему на десктопное окружение и драг-н-дропы.

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

У тебя всё всмятку. Гугл не имеет отношения к Electron-у и его API работают в браузере, а не в Electron. Electron это нативное приложение и оно имеет доступ к любым API операционной системы, в крайнем случае надо FFI дописать в несколько строчек.

Не помню, когда последний раз работал с жава-приложением. Зато помню, когда последний раз работал с электроном и вебсайтами.

У JVM есть определённые проблемы, мешающие использовать её в GUI. В первую очередь это странная система управления памятью, когда нужно настраивать Xmx и она освободившуюся память системе отдавать не хочет. Вроде в последних версиях что-то исправляли, но вряд ли кардинально и до конца. Как следствие - низкая популярность JVM в этой области и не слишком развитые GUI-фреймворки. Насколько я понимаю, Electron этих проблем лишён.

Справедливости ради, успехом современная версия VS Code не в последнюю очередь обязана WebAssembly — турбореактивный парсинг сорцов сделан именно нем.

Он в любом случае медленней JVM.

Язык умирает когда о нем даже срача нету

Это конечно всё здорово, но каким образом перечисленные «недостатки» jvm и в частности java делают go пригодным для чего-то кроме devops-са?

Go разрабатывался не для девопса, Go разрабатывался для писания сервисов. И эту задачу от отлично выполняет. Как ни странно, это основная ниша и для жавы.