Не знаю переводил кто данную статью (даже не искал пока), просто все равно не понятно для чего переходить на Kotlin, тем более samsung выпустил Tizen OS, google готовит fuchsia c dart плюс progressive web app, microsoft подсаживает на typescript, это я к чему, хотя и был плохой опыт с phonegap, и не понятно кто выживет из всего этого зоопарка, мобильная разработка движется к кроссплатформенности через ecmascript, ну или Dart. У Вас кстати есть хороший пример по работе с сенсорами используя rxjava было бы интересно посмотреть как это бы выглядело на Kotlin.
Kotlin умеет в JavaScript.
Посмотрел точно, спасибо за подсказку, еще приведу цитату с официального блога
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 можно и php скрипты запустить, а вот проект с Java на JavaScript
Речь о транспилере с языка на язык.
Так есть еще GWT от гугл, который транспайлится в js, на замену которому пришел dart… Под dart есть angular 2, fuchsia… А что есть под Котлин?
Dart как бы это уже давно умеет из коробки, и даже намного лучше…
А да еще буквально полгода назад только начинал осваивать AR (ARToolkit, OpenCV, Google mobile vision), а уже https://awe.media/ или вот еще.
Не хватает сравнения скорости при компиляции с оспользованием кодогенерации apt/kapt, так же при таргетах java6/8(dasugar, retrolambda) а так же multidex. По сути статья в таком виде не имеет ничего общего с реальными крупными проектами, где скорость компиляции действительно важна.
Средняя продолжительность сборки Java составляет 15,5 секунд, Kotlin – 18,5 секунд

При этом на графике для Java почти все результаты попадают в 20-25 сек (и выше), а Kotlin — более 30 сек.
Действительно. К счастью автор выложил исходные данные, поправил цифры в переводе.
Какая версия kotlinc использовалась при компиляции? Почему для тестов был выбран Gradle 2.14 а не 3.5?
Ну да, упомянули 1.0.2, которая уже даже не вчерашний день, а позавчерашний.

К тому же сомнительно, что код, полученный автоматической конвертацией, является оптимальным. И ещё мне кажется, что Gradle под Kotlin ещё пока не так хорошо заточен, как Maven.
И ещё мне кажется, что Gradle под Kotlin ещё пока не так хорошо заточен, как Maven.

Там обратная ситуация. В Gradle и скрипты можно теперь писать на Kotlin и в нем раньше появилась инкрементальная компиляция для него.
Да и сама система сборки создавалась не жестко под один определенный язык (по сравнению с Maven), и как результат, имеет более гибкую систему настройки.

В каком месте у мавен жестко определеный язык?

… сама система сборки создавалась не жестко под один определенный язык

Вот я и спрашиваю, где вы это вычитали? Мало того, что уже много лет существуют скажем плагины для сборки .Net проектов (потому что эта сборка в общем-то ничем не отличается от сборки java проектов), или скажем Flexmojo, мало того, что сами плагины пишутся на Groovy, кложе, и еще на некоторых разных языках.


В мавене нет никакой привязки к языку, кроме той, что он сам на java написан. Мавен — это лишь формат POM (который в целом language agnostic, да еще и сам давно уже может быть переписан например в виде yaml). Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок — которые тоже ни к какому языку не привязаны отродясь.

Использование Apache Maven – обратная сторона медали
Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок…

Поэтому и существуют некоторые сложности для сборки других языков.

П.с. пока искал нашел еще одну интересную статью: 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, но совершенно очевидно, что он обобщает без оснований.

Это перевод статьи 2016
Насколько я понял, на момент публикации оригинала (9 сентября 2016 года), Gradle 3.5 не был релизнут. Ближайшая стабильная версия — 3.0 (15 августа 2016 года), но есть шанс, что оригинальная статья писалась на пару месяцев раньше, чем была опубликована, что объясняет выбор 2.14 версии (ближайшая стабильная версия на предполагаемый момент подготовки статьи).
Ключевой проблемой для kotlin является java, а точнее, юридический отдел oracle. Процесс появления джавы на сервере или на слейве для сборки окутан юридическим маразмом для роботов на 200% процентов. Специальный хук в pbuilder для того, чтобы принимать лицензию до установки пакета.

Оно отвратительно. Говорю как админ.

А зачем ставить oracle-java? Почему не openjdk? Почему не zulu?

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

Какая связь рассмотрения альтернатив с переводом отдела?

Его теперь будут писать индусы.

А почему решили отдать разработку индусам вместо петербуржцев?

на РБК статья была
Что насчёт Zulu от Azul?
Оно вроде как «чистое OpenJDK»
openjdk не решает ваших проблем? обязательно нужен hotspot? просто интересно
Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.