Kotlin классная штука

То есть Java больше не нужна, только JVM?

Смотрел его доку как то давно, создалось такое же впечатление

Хотя Scala как то повеселее будет, а Kotlin мне кажется идеален для Андроида (там где не нужно согласовывать с энтерпрайз заказчиками)

Берите свой любой Java-класс и переписывайте на Kotlin

в идее вроде даже кнопка была «make java as kotlin»

если работает ок, то и переписывать ничего не нужно

То есть Java больше не нужна, только JVM?

Java уже давно в первую очередь JVM и только во вторую очередь язык, как мне кажется. Scala и Clojure это зрелые проекты, которые это доказывают.

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

А может .NET всех съест, кто его знает.

Несколько лет назад немного общался с инженерами JetBrains по поводу этого языка, и они сказали что планируют аж всю IDEA'ю переписать на нём. Мне тогда такие планы показлись сомнительными, интересно насколько широко его сейчас используют внутри компании.

Конвертер из джавы в скалу тоже встроен в Идею. Просто копипастаешь код из файла с расширением .java в файл с раширением .scala, и вставится уже отконверченый код. Конечно, качество сконвертированного кода весьма низкое - отображение будет 1 в 1, а большинство людей хотело бы видеть не кальку, а идеоматичный код

какие неудачные решения в джаве? Я на своей шкуре ощутил только одно - нельзя делать циклы в аннотациях (н-р вложить аннотацию в саму себя), что сводит на нет всё метапрограммирование на них

Интероп с Java замечательный, можно сказать — идеальный. Берите свой любой Java-класс и переписывайте на Kotlin.

отличный интероп, бро

Что со скоростью компиляции?

Нужен вам хаскель-подобный язык для яйцеголовых зигоморфизмов — берите Scala.

Шо за фигня? На скале можно писать как на яве. А котлин последних версий - та же скала, только в профиль и без адвансед фич. Я с ним не стал разбираться именно по этой причине. Да и перманентная альфа уже в течение 3 с лишним лет, без какого-либо просвета.

отличный интероп, бро

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

Java уже давно в первую очередь JVM и только во вторую очередь язык

java это в первую очередь java и её здоровенный api, не зря гугл копирнул по мимо java, еще и api, за что и отхватил от оракла.

То, что там 2.5 человека юзают scala, clojure или groovy (оно еще живо?) не ставит на первое место jvm.

Нужна Java как язык или нет — это вопрос времени.

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

просто потихоньку пользователи будут размываться по другим языкам.

По каким? Kotlin, Ceylon? Эти поделия уже сколько лет не приходят к успеху. Напоминает историю D как замена СPP. А Scala так вообще, для особо упоротых.

слишком большой груз неудачных решений в прошлом

Тем не менее, добавили лямбды, предлагают compact strings в 9-ке (на 20% буст перформанса и до 30% меньше памяти), обещают value types и генерики починить, может быть даже с нарушением совместимости.

Какие еще проблемы? Геттеры/Сеттеры? Так это проблема решается с помощью фреймворков, аннотаций и плагина к IDE. Да, не идеально, но это работает.

Шо за фигня? На скале можно писать как на яве.

Можно, но будет много оговорок. Интероп с Java будет с приседаниями, если специально не стараться. Стандартная библиотека коллекций другая. Код получится не идиоматичный. В исходники какого-нибудь scalaz залезешь и сойдёшь с ума. В общем примерно то-же, что и с C++. Теоретически можно писать как на C с классами и шаблонами, на практике нужно уметь себя ограничивать, чтобы не пойти вразнос.

Да и перманентная альфа уже в течение 3 с лишним лет, без какого-либо просвета.

В следующей идее (выйдет в декабре) Kotlin будет в стандартной поставке, что как бы намекает.

какие неудачные решения в джаве?

Generics type erasure, bloated JDK, java.util.Date, кривая XML-библиотека, нет ко(нтра)вариантности шаблонов, нет иммутабельных интерфейсов в стандартной библиотеке коллекций, checked exceptions, nullable типы, мутабельность по умолчанию. Это только то, что сходу в голову пришло. Что-то пытаются исправлять, но получаются половинчатые решения: то же API для работы со временем в Java 8 — переизобрели хорошо, но теперь в стандартной библиотеке два API. Причём JDBC, JSTL и куча сторонних библиотек поддерживают старый, так что от него никуда не деться, придётся на ровном месте рожать кучу конвертаций туда-сюда-обратно.

Конечно, качество сконвертированного кода весьма низкое - отображение будет 1 в 1, а большинство людей хотело бы видеть не кальку, а идеоматичный код

Я думаю что это нереально, а вот _почти_ идеоматичный код из Java в Kotlin получить автоматически все же реальнее

Generics type erasure

Со временем должны починить

bloated JDK

В 8-ке его уже разделили на три профиля. Минимальный из них занимает 15 Мб. В 9-ке, как я понял, можно вообще будет собирать свой API под приложение. Т.е. можно будет собирать все в один executable пакет без завязки на JRE.

java.util.Date
но теперь в стандартной библиотеке два API
на ровном месте рожать кучу конвертаций

И что? Это теперь повод менять ЯП, на поделие типа Kotlin?

кривая XML-библиотека

Ну подключи не кривую, какие проблемы?

ко(нтра)вариантности шаблонов

Хз че это, но судя по всем большинству разрабов это не нужно.

нет иммутабельных интерфейсов в стандартной библиотеке коллекций

Подключи/напиши либу если тебе это надо.

checked exceptions

Ну в Go, тоже считают, что нужно каждую ошибку проверять и говорят, что это даже фича.

Какие-то надуманные проблемы.

Спасибо! Просматривал пару презенташек. Пока ждём релиз кандидата чтобы потрогать.

Generics type erasure,

да. Но непонятно, может это и фича. Вот если бы erasure можно было вручную включать и выключать...

но заметь, что в рантайме в байткоде инфа о дженериках остаётся, и её можно вытащить например через asm.ow2.org: http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/signature/SignatureVi...

bloated JDK

не пользуйся. Есть Maven Central, вот это и есть «настоящее» SDK для джавы :)

java.util.Date

не пользуйся. Есть же LocalDate в JDK. Или какое-нибудь Joda Time (от использования его тебя отделяют не более чем несколько строчек в мавене).

нет ко(нтра)вариантности шаблонов

good point :(

мутабельность по умолчанию

и вообще имхо это фича. fine-grained performance control. особенно что касается многопоточности. Пердолиться с многопоточностью - это основная задача джавы :)

нет иммутабельных интерфейсов в стандартной библиотеке коллекций

https://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained

checked exceptions

так это же фича! В чем проблема?

nullable типы

Optional.ofNullable спасёт атца русского функционального программирования

ахда, джава - не функциональный язык, а императивный. Это фича.

то же API для работы со временем в Java 8 — переизобрели хорошо, но теперь в стандартной библиотеке два API.

всё забываю, что ты на C++ не писал :))) Всего два API? :)))

Причём JDBC, JSTL и куча сторонних библиотек поддерживают старый, так что от него никуда не деться,

эээ, вроде бы Hibernate у мну отлично работает с LocalDate. Возможно я как-то диалект подправил, не помню, кода щаз нету под рукой

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

что касается конкретно JSTL, то по крайей мере в связке с Tiles и Spring MVC, у меня понаписаны конвертеры-форматтеры-едиторы и подправленые версии тэгов, в т.ч. и для LocalDate, и после этого всё работает прозрачно. Без этого всё равно жить невозможно, н-р люди часто держат дату в БД в виде инта, и не обязательно это стандартный unixtime, и руками конвертить это говно туда-сюда (между UI/DTO/DAO) - спасибочки

Да, да только за него денег не платят 8)

За все деньги платят, вопрос продажи ;) какому-нибудь разработчику на андроиде который пилит на котлине вполне себе платят

В следующей идее (выйдет в декабре) Kotlin будет в стандартной поставке, что как бы намекает.

а для MPS так вообще отдельная IDE. И на нем написан их ютрак и форум. Одна проблема - никто кроме джетбрейнсов не желает MPS юзать.

nullable типы

Использую из 8-ки Optional и получается очень здорово. Повыкидывал из кода все эти isEmpty, isNotEmpty.

Kotlin с Андроидом дружит? А Scala?

но заметь, что в рантайме в байткоде инфа о дженериках остаётся, и её можно вытащить например через asm.ow2.org: http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/signature/SignatureVi...

Можно и через стандартный reflection вытащить, если я тебя правильно понял. Но это только из параметра метода/поля класса/специализированного наследника. А вот если тебе в метод приходит List<T>, то никакую инфу ты вытащить не можешь. В лучшем случае пройтись по всем элементам, определить их тип и принять за тип списка их наистарший суперкласс.

не пользуйся. Есть Maven Central, вот это и есть «настоящее» SDK для джавы :)

Определённое API должно быть общим. Те же временные типы данных. У меня Spring MVC конвертирует строки в даты, потом Hibernate эти даты через JDBC сохраняет в базу, потом через какой-нибудь JSP или Thymeleaf они показываются пользователю. Когда типы везде общие — проблем нет. А вот когда они разные — мы начинаем весело писать конвертеры, адаптеры и прочие переходники, вместо того, чтобы заниматься делом.

C++ шикарный антипример. Неюзабельный класс std::string, который даже строкой в современном смысле не является и прорва альтернативных реализаций в каждой второй библиотеке. И прорва увлекательного кода при попытке скрещивать эти библиотеки между собой.

мутабельность по умолчанию

и вообще имхо это фича. fine-grained performance control. особенно что касается многопоточности. Пердолиться с многопоточностью - это основная задача джавы :)

Почти во всех новых языках переменные иммутабельны по умолчанию (или пользователь должен выбрать нужный тип: val vs var). Тут даже не в многопоточности дело, а в багах от опечаток. Если у тебя в методе все переменные иммутабельны кроме одной-двух мутабельных, то при опечатке у тебя будет ошибка компиляции. Если все мутабельны, то не будет.

нет иммутабельных интерфейсов в стандартной библиотеке коллекций

https://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained

Это не иммутабельные интерфейсы. Тебе ничего не мешает передать ImmutableList в другой метод как List, и этот другой метод его попробует модифицировать. Да, в рантайме всё вылетит, но у нас же не PHP. Так-то никакая гуава не нужна, Collections.unmodifiableList делает то-же самое (разве что менее удобно), но это не решение, а попытка сделать хоть какой-то workaround.

checked exceptions

так это же фича! В чем проблема?

Проблема в куче библиотек, которые их кидают. В первую очередь стандартных. SQLException, NamingException и прочие CloneNotSupportedException, лол.

Optional.ofNullable спасёт атца русского функционального программирования

Optional для другого сделан. Если ты его будешь юзать везде, у тебя просто на ровном месте станет в 2 раза больше объектов. GC тебе спасибо не скажет. Правильный ответ — @NonNullable. Но это дополнительная конфигурация проекта, это дополнительная писанина, это отсутствие поддержки этого почти во всех библиотеках.

ахда, джава - не функциональный язык, а императивный. Это фича.

Функциональность тут особо не при чём.

что касается конкретно JSTL, то по крайей мере в связке с Tiles и Spring MVC, у меня понаписаны конвертеры-форматтеры-едиторы и подправленые версии тэгов, в т.ч. и для LocalDate, и после этого всё работает прозрачно. Без этого всё равно жить невозможно, н-р люди часто держат дату в БД в виде инта, и не обязательно это стандартный unixtime, и руками конвертить это говно туда-сюда (между UI/DTO/DAO) - спасибочки

А мог бы писать код, который решает полезные задачи, вместо написания конвертеров-форматтеров-едиторов, если бы не было бардака и гуляния.

На Kotlin-е вроде люди пишут под Android. На Scala кажется тоже, тут менее уверен.

Да, да только за него денег не платят 8)

Я не проверял, но я глубоко убеждён, что любой вменяемый Java-разработчик через день будет без каких-либо проблем писать на Kotlin. Причём про Scala я этого сказать не могу.

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

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

А вот если тебе в метод приходит List<T>, то никакую инфу ты вытащить не можешь

а вот и можешь :) асм берет информацию о дженериках не из рефлекшена, а напрямую из байткода. Или например Spring знает имена параметров в конструкторе, хотя через рефлекшен такая информация недоступна. Эту инфу зашивает в байткод сам конпелятор джавы в момент конпеляции. Наверное, можно написать свою аннотацию, которая будет форсировать рантайм-чекинг дженериков, или что-то такое. Конечно, конпелятор должен быть преднастроен, чтобы генерить дебажную информацию, и ты не можешь доверять коду из чужих джарок из мавен-централа (где её может не быть). Ну и есть ньюансы, типа что дженерики из сигнатуры метода доступны всегда, а из локальных переменных - не всегда (я не разбирался, как это настраивать).

Ну хорошо, допустим в котелке починили коллекции и допилили иммутабельность. А если тебе захочется что-нибудь еще? Паттерн-матчинг блобов, чтобы парсить tcp/ip? Акторы? Рекурсивные аннотации? Еще что-нибудь? Теперь новый язык/платформу на каждую новую хотелку брать, так что ли?

может лучше сообразить какой-нибудь способ, чтобы возможности языка могли добавляться в виде библиотек, и докидывать их по вкусу. В том числе синтаксис: добавил либу - появились новые синтаксические конструкции. Как с этим у этого вашего Котлина? И если «никак» (или «почти никак как в скале»), может тогда начать обсуждение сразу с jetbrains MPS?

а вот и можешь :) асм берет информацию о дженериках не из рефлекшена, а напрямую из байткода.

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

Или например Spring знает имена параметров в конструкторе, хотя через рефлекшен такая информация недоступна.

Начиная с Java 8 доступна. А вообще это просто обычная debug-информация. И если ты скомпилируешь своё приложение без debug-символов, то нифига Spring не узнает.

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

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

В более простых случаях вроде

<T> T myNew() { 
   return new T();
}

можно обойтись скрытым параметром (так можно делать в Scala).

идеоматичный

потому что идея сконвертила? :D

Ну хорошо, допустим в котелке починили коллекции и допилили иммутабельность. А если тебе захочется что-нибудь еще? Паттерн-матчинг блобов, чтобы парсить tcp/ip? Акторы? Рекурсивные аннотации? Еще что-нибудь? Теперь новый язык/платформу на каждую новую хотелку брать, так что ли?

Я исхожу из моих задач. Для них Kotlin выглядит идеальным. Серебряную пулю я не ищу.

может лучше сообразить какой-нибудь способ, чтобы возможности языка могли добавляться в виде библиотек, и докидывать их по вкусу. В том числе синтаксис: добавил либу - появились новые синтаксические конструкции. Как с этим у этого вашего Котлина? И если «никак» (или «почти никак как в скале»), может тогда начать обсуждение сразу с jetbrains MPS?

Ну тут смотря что ты имеешь в виду. В Scala можно очень нехилые DSL-и наворачивать, по виду неотличимые от встроенных конструкций. В Kotlin есть перегрузка операторов, есть infix-нотация для вызовом методов, можно опускать скобки для последнего лямбда-параметра, так что в какой-то мере DSL-и писать можно.

Про MPS я почти ничего не знаю, так что тут я пас. Вроде Nemerle на этом поле играет.

Exception in thread «main» java.lang.NoSuchMethodException.

добавлять в сам объект скрытое поле, в котором сохранять информацию о генерике

а ведь можно попробовать? Исходники жабацэ валяются в меркуриале. Надо «всего лишь» найти место, куда наговнокодить генерацию дополнительного поля, пока еще информация о полях доступна в текстовом виде, чтобы просто скопипастать туда весь текст поля, например...

кстати, где-то на Stackoverflow забавное решение для такого на шаблонах для C++ видел, жаль ссылку просрал

О, вот же я когда-то писал: Как вывести содержимое C-структуры? (комментарий)

Там нужно еще добавить один шаг, и как-то сгенерить REFLECTABLE часть автоматически :)

> <T> T myNew() { 
>   return new T();
> }

on an unrelated note, вот так в Gson можно извернуться, чтобы передать тип generic коллекции, чтобы правильно сериализовать её в Json:

Type fooType = new TypeToken<Foo<Bar>>() {}.getType();
gson.toJson(foo, fooType);
gson.fromJson(json, fooType);

если память не изменяет, там под капотом фича в том, что оригинальный Type из JDK прозрачно приводится к Class<?>.

А TypeToken<T>, даже суженный до Type - не приводится! И кто-то теперь будет на скалу ругаться...

http://habrahabr.ru/company/jugru/blog/263905/#comment_8521263

У него большой рантайм? В Андроиде приходиться методы считать, чтобы не привысить лимит.

Да и восьмая джава ничего так, и javafx - годная штука.
Но уж так сложилось, что java это ejb, glassfish, hibernate, а всеми остальными вещами (kotlin, groovy, scala и т.п.) пользуется не так уж много народа.

У него большой рантайм? В Андроиде приходиться методы считать, чтобы не привысить лимит.

kotlin-runtime 272 KB, kotlin-stdlib 788KB

на первый взгляд в kotlin-stdlib ничего критичного для языка нет, предположительно его можно выбросить или почикать.

А что за лимиты в андроиде? Там же каждое второе приложение по 100 мегабайтов весит.

65000 методов на APK. Когда много библиотек, можно упереться в лимит.

Добавляет методов не больше чем та же Guava или Google Play Services. Считаете методы - используйте ProGuard. Вот тут есть небольшое описание по части создаваемого оверхеда на методы и размер полученного приложения.

А что там взамен паттерн-матчинга? Уж больно я привык к нему в скале, очень мощная вещь. Что с этим в котлине? Или он на уровне какого-нибудь свитча?

Там же каждое второе приложение по 100 мегабайтов весит.

Это не значит, что там методов на 100 мегабайт. Еще со времен 98 виндов, екзешник 1-2 Мб, а остальные сотни мегабайт - ресурсы.

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

http://habrahabr.ru/company/jugru/blog/263905/

Глянь видео, там про котлин рассказывается. Скоро будет жэава-конференция он там будет рассказывать как котлин используется во внутренних разработках и они уже, походу, начали потихоньку идею переписывать в котлин.

Ну вот ты тут порасписал проблемы, а этих проблем в дуднете нет искаропки :)

Да и кроссплатформенность становится чуть ли не больше, чем у джавки.

Но уж так сложилось, что java это ejb, glassfish, hibernate, а всеми остальными вещами (kotlin, groovy, scala и т.п.) пользуется не так уж много народа.

Зачем сравнивать теплое с мягким? Сделайте легковесные и удобные фреймворки под java и будут её юзать. А kotlin сранивать с hibernate...

switch на стероидах:

open class Node
class Leaf(val value: Int) : Node()
class Parent(val left: Node, val right: Node) : Node()

fun sum(node: Node): Int =
        when (node) {
          is Leaf -> node.value
          is Parent -> sum(node.left) + sum(node.right)
          else -> throw AssertionError()
        }

guard-ов нет (хотя напрашиваются, может потом будут), деструктурирования тоже нет.

Вся прелесть скалы в том, что у нее своя экосистема, свои либы. Я кстати пришел к выводу, что языковые фичу в основном разрабам библиотек нужны. Скала-стек весь такой асинхронно-реактивно-тайпсейфный. А с котлином будешь дергать тоже допотопное уг, что и из жавы.

guard-ов нет (хотя напрашиваются, может потом будут), деструктурирования тоже нет.

Убогонько.