Comments 33
One of Kotlin’s goals is to be a language that is available on multiple platforms and this will always be the case. We’ll keep supporting and actively developing Kotlin/JVM (server-side, desktop and other types of applications), and Kotlin/JS. We are working on Kotlin/Native for other platforms such as macOS, iOS and IoT/embedded systems.
если коротко есть Kotlin/JVM и Kotlin/JS, а в планах и macOS, iOS и IoT/embedded systems.
Тогда смысл есть на перспективу, если начинать новый проект, лишь бы его не шатало как python, swift и т.д.
Kotlin умеет в JavaScript
Как бы и Java умеет в JS тоже и весьма неплохо. В бытность одного из моих сайтов мне надо былло дешифровывать ссылки, которые были на другом ресурсе закодированы в aes256 (в JS был код от А до Я). Декодирование на оригинале было на aes256 с пост обработкой (перестановки символов и т.д.). Чтобы не ломать бошку, я просто зарядил код в ScriptEngineManager, чтобы не тратить время на реализацию на самой java.
Средняя продолжительность сборки Java составляет 15,5 секунд, Kotlin – 18,5 секунд
При этом на графике для Java почти все результаты попадают в 20-25 сек (и выше), а Kotlin — более 30 сек.
К тому же сомнительно, что код, полученный автоматической конвертацией, является оптимальным. И ещё мне кажется, что Gradle под Kotlin ещё пока не так хорошо заточен, как Maven.
И ещё мне кажется, что Gradle под Kotlin ещё пока не так хорошо заточен, как Maven.
Там обратная ситуация. В Gradle и скрипты можно теперь писать на Kotlin и в нем раньше появилась инкрементальная компиляция для него.
Да и сама система сборки создавалась не жестко под один определенный язык (по сравнению с Maven), и как результат, имеет более гибкую систему настройки.
В каком месте у мавен жестко определеный язык?
… сама система сборки создавалась не жестко под один определенный язык
Вот я и спрашиваю, где вы это вычитали? Мало того, что уже много лет существуют скажем плагины для сборки .Net проектов (потому что эта сборка в общем-то ничем не отличается от сборки java проектов), или скажем Flexmojo, мало того, что сами плагины пишутся на Groovy, кложе, и еще на некоторых разных языках.
В мавене нет никакой привязки к языку, кроме той, что он сам на java написан. Мавен — это лишь формат POM (который в целом language agnostic, да еще и сам давно уже может быть переписан например в виде yaml). Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок — которые тоже ни к какому языку не привязаны отродясь.
Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок…
Поэтому и существуют некоторые сложности для сборки других языков.
П.с. пока искал нашел еще одну интересную статью: Maven is broken by design
Сложности? Не большие, чем у любого другого средства сборки. Попробуйте для примера, использовать какой-нибудь современный менеджер зависимостей, типа bower, на машине в интранете, с доступом вовне через прокси, которая генерирует на лету SSL сертификаты. Проникнитесь с ходу.
А соглашения кстати соблюдать не обязательно. Я писал плагины, работающие вообще без наличия POM, это вполне возможно. Пишете на груви, внутри делаете вообще что хотите.
Статья кстати дурацкая. Не, не вся, разумные мысли там есть — только вот решений проблем автор все равно не предложил. А местами просто ржака:
The POM as used in repositories is too verbose for its intended use, and could be vastly improved. Slimming it down would be possible, but enhancing it by making it no longer immutable would break everyone. Unfixable.
Ха (три раза). POM в репозитории — это единственная вменяемая форма модели, с которой вообще можно работать. Я бы сказал, что все другие модели значительно хуже, но опыт применения скажем npm маловать для столь категоричного высказывания.
Чтоб было понятнее — автор этой статьи считает, что возможность построить модель проекта динамически, используя для этого groovy — это хорошо. На мой же взгляд — это ужасно.
Чтобы так делать, нужно чтобы у вас был gradle в наличии. Причем желательно — той же версии, с теми же плагинами. И надо сборку фактически выполнить, чтобы модель получить. Мало того, что это делает импорт скажем gradle проектов в IDEA просто на порядки медленнее — это еще и не позволяет работать с проектами из других языков. При этом с pom я успешно работал любым инструментом — потому что это xml.
Ну и кто тут привязан к одному языку?
Понятно, что у него другие use cases, но совершенно очевидно, что он обобщает без оснований.
Оно отвратительно. Говорю как админ.
А зачем ставить oracle-java? Почему не openjdk? Почему не zulu?
Оно вроде как «чистое OpenJDK»
Kotlin vs. Java: скорость компиляции