Ну мое мнение: C++ тормозит, да еще и падает с сегфолтами. А если серьезно то Kotlin генерирует байткод очень похожий на байкод языка Java, т.е. перформанс тут не будет отличаться от Java. Но т.к. в Kotlin например можно заинлайнить лямбду, то он даже выигрывает в производительности. И таких мелких примеров много, и еще больше будет (я очень жду связки when + sealed class).
На jpoint и jet будут доклады от Дмитрия Жемерова про производительность Kotlin с JMH бенчмарками, рекомендую.
> А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option.
Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.
> его можно проверить только в runtime
С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML
Ну не сахар это :) Это система типов блин, String? это именно тип, который может быть String | Null.
Кстати подписочная модель дешевле чем в год по версии покупать, а еще подарили год, когда переходил на подписку. У меня стойкое ощущение что разозлились в основном те, кто пиратил :)
> Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой «нестабильности» инспекций никогда не было.
Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.
> По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
site:kotlinlang.org bla-bla? pdf?
В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.
> Допустим, я вам верю, хотя это не так. Как именно будут происходить compile-time проверки для результатов вызова Java-методов из внешних библиотек? Kotlin вводит для них понятие nullable-типа, т.е. делает инверсию: non-nullable типы становятся «по умолчанию», а nullable требуют специального обращения. И все nullable проходят все необходимые проверки, причем в runtime, потому что иначе все в рантайме просто развалится: в Java нельзя полагаться на результаты анализа внешних библиотек, в runtime может быть совершенно другой JAR с совершенно другой реализацией указанных интерфейсов. ManagedExecutorService и вот это все. В результате string? a = someFunc(); Type? b = a?.someMethod();, и все это в runtime будет полностью аналогично Option(someFunc()).map(_.someMethod). Такой же «кривой слой абстракции с runtime-penalty», как Option, только в профиль. Если очень прям так хотелось этого, можно было патч для javac написать, или annotation processor какой-нибудь, чтобы проверял наличие Optional в nullable-типах, а не аж целый язык изобретать.
Хватит троллить, честное слово.
1. Если мы говорим про чистый Котлин без вызова Java — то там в худшем случае есть nonNull проверки в начале метода.
2. Если мы говорим про интероп Kotlin и Java, то на границе с Java создается nonNull check, что есть просто вызов функции.
Никаких объектов и if(o.isPresent()) {o.get()}.
Так что никак это не аналогично. Пожалуйста, разберитесь в субъекте, прежде чем обсуждать его.
> Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
А также реальность что JetBrains пишет внутри на Kotlin и делал язык в первую очередь для себя, маркетинга у них мало, в основном такое вот сарафанное радио. В отличии от M$ которые пропихивают за откаты продукцию в гос органы и в учебные заведения. Или вот, трек Kotlin на jetconf.by, как ты думаешь, сколько JetBrains заплатила за него? Ответ — 0.0$.
> Spring Boot-то тут при чем?
@EnableAutoConfiguration избавляет от большого колличества конфигураций, многое можно прямо в application.yml подхачить, а если нужен свой бин — то да, JavaConfig. Ваш легаси с XML, ну да, придется отставить XML видимо. Мои же два последних проекта были вообще без единого XML (если говорить про настройку фрэймворков).
> я уже сделаю нужную страницу на JSF
А потом это нужно поддерживать и дорабатывать, делать API для мобильного приложения и вот это все. Зато за пять минут наколенке! Кстати из последнего Technology Radar от ThoughtWorks JSF выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.
Достаточно было прочитать первое предложение из доки, чтобы не писать столько бессмысленных вопросов: https://kotlinlang.org/docs/reference/inline-functions.html
> JIT уже делает inlining
Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.
Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
> Сделали conditional dereference — круто, но это просто синтаксический сахар над Optional.map (Java) или Option.map (Scala).
Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.
> Java-код ведь не дает никаких гарантий относительно возврата NULL.
Всё так, именно поэтому Котлин автоматически расставляет nonNull проверки на границе с Java кодом. А также обращает внимание на аннотации @Nullable/@Notnull
> Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы.
Со scala-lang.org:
Accessing Java classes from Scala code is no problem at all. Using a Scala class from Java can get tricky, in particular if your Scala class uses advanced features like generics, polymorphic methods, or abstract types.
По факту когда ты просто пишешь код на скале, а потом просто пытаешься вызвать его из Java получается куча странных имен и долларов в коде, но так и надо конечно, никаких проблем.
> Попробуйте Lombok
Летали, знаем, закапайте стюардессу.
> JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Нужно больше конспиративных теорий! Еще раз, есть плагин для Eclipse, нравится Eclipse? Пользуйтесь им, в чем проблема. Также сообщество сделала подсветку в Sublime/Atom, возможно уже есть vim плагин.
> но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц
На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
Там где в Java вы бы использовали Optional, вы не используете ничего, когда у вас есть маленькая вспомогательная функция — вы её инлайните. Думаю больше о производительности будет рассказано тут: http://javapoint.ru/talks/jemerov/
Jtalk Конечно открытой IDE и плагина для эклипса недостаточно чтобы победить Java, именно поэтому в котлине решена «billion-dollar mistake», идеальный интероп с джавой. Рантайм очень маленький(6К методово, 500кб) и скорость кода на Котлине зачастую превосходит джава код, и при этом глаза не обязаны фильтровать тонны мусора. Время компилиции такое-же как у Java, идеальная поддержка в той же открытой IDE(Intellij Idea Community Edition, Android Studio).
Scala — тормозит в IDE и при сборке проекта, не интерабельна с джавой (в обе стороны) и имеет слишком богатую библиотеку.
Groovy — заслужил звания языка с пазлерами, и в первую очередь для многих это динамический язык со всеми вытекающими.
Gosu, Phantom — очевидно эти языки изначально были мертворожденными, за ними никто не стоит их никто не продвигает.
Ceylon — хорошая попытка, действительно интересный язык… Но он напоминает Scala со своими наваторскими идеями и задвигает интероп с Java на второй план.
Итого получается что Kotlin это тот язык который имеет смысл тянуть в существующий проект, использовать его бок обок с написанным Java кодом, при этом это современный язык, с высокими гарантиями безопасности(smart-casts,NPE-free code) и умным компилятором.
Мне интересно, все те люди которые в опросе «Используется ли Kotlin в вашей компании?» ответили «Нет, и не собираемся пробовать» не знают что такое Котлин, или у них какие-то объективные причины? Потому что из всех JVM языков, Котлин единственный который может конкурировать с Java.
На jpoint и jet будут доклады от Дмитрия Жемерова про производительность Kotlin с JMH бенчмарками, рекомендую.
Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.
> его можно проверить только в runtime
С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML
> А что это такое?
Пожалуй гугл лучше справится с этой задачей
так как это применяется к higher-order functions то логично что никак, продолжать?
Если говорить про interop, то это будет просто статический метод в соответсвующем пакете.
была, после выхода java 8 инспекции могли подсвечивать правильный java 8 код, хотя поддержка джавы 8 была объявлена :) это так, почему-то вспомнил
Если сравнивать с Java, то да, десятилетием разрабаттываемая поддержка джава действительно выглядит серьезнее и в ней меньше багов (хотя случаются)
Но мой поинт был именно в том, что среди других альтернативных JVM языков, Kotlin имеет действительно хороший тулинг с рождения.
Кстати подписочная модель дешевле чем в год по версии покупать, а еще подарили год, когда переходил на подписку. У меня стойкое ощущение что разозлились в основном те, кто пиратил :)
Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.
> По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
site:kotlinlang.org bla-bla? pdf?
В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.
Хватит троллить, честное слово.
1. Если мы говорим про чистый Котлин без вызова Java — то там в худшем случае есть nonNull проверки в начале метода.
2. Если мы говорим про интероп Kotlin и Java, то на границе с Java создается nonNull check, что есть просто вызов функции.
Никаких объектов и if(o.isPresent()) {o.get()}.
Так что никак это не аналогично. Пожалуйста, разберитесь в субъекте, прежде чем обсуждать его.
> Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
А также реальность что JetBrains пишет внутри на Kotlin и делал язык в первую очередь для себя, маркетинга у них мало, в основном такое вот сарафанное радио. В отличии от M$ которые пропихивают за откаты продукцию в гос органы и в учебные заведения. Или вот, трек Kotlin на jetconf.by, как ты думаешь, сколько JetBrains заплатила за него? Ответ — 0.0$.
> Spring Boot-то тут при чем?
@EnableAutoConfiguration избавляет от большого колличества конфигураций, многое можно прямо в application.yml подхачить, а если нужен свой бин — то да, JavaConfig. Ваш легаси с XML, ну да, придется отставить XML видимо. Мои же два последних проекта были вообще без единого XML (если говорить про настройку фрэймворков).
> я уже сделаю нужную страницу на JSF
А потом это нужно поддерживать и дорабатывать, делать API для мобильного приложения и вот это все. Зато за пять минут наколенке! Кстати из последнего Technology Radar от ThoughtWorks JSF выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.
> JIT уже делает inlining
Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.
Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.
> Java-код ведь не дает никаких гарантий относительно возврата NULL.
Всё так, именно поэтому Котлин автоматически расставляет nonNull проверки на границе с Java кодом. А также обращает внимание на аннотации @Nullable/@Notnull
> Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы.
Со scala-lang.org:
Accessing Java classes from Scala code is no problem at all. Using a Scala class from Java can get tricky, in particular if your Scala class uses advanced features like generics, polymorphic methods, or abstract types.
По факту когда ты просто пишешь код на скале, а потом просто пытаешься вызвать его из Java получается куча странных имен и долларов в коде, но так и надо конечно, никаких проблем.
> Попробуйте Lombok
Летали, знаем, закапайте стюардессу.
> JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Нужно больше конспиративных теорий! Еще раз, есть плагин для Eclipse, нравится Eclipse? Пользуйтесь им, в чем проблема. Также сообщество сделала подсветку в Sublime/Atom, возможно уже есть vim плагин.
> но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц
На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
Scala — тормозит в IDE и при сборке проекта, не интерабельна с джавой (в обе стороны) и имеет слишком богатую библиотеку.
Groovy — заслужил звания языка с пазлерами, и в первую очередь для многих это динамический язык со всеми вытекающими.
Gosu, Phantom — очевидно эти языки изначально были мертворожденными, за ними никто не стоит их никто не продвигает.
Ceylon — хорошая попытка, действительно интересный язык… Но он напоминает Scala со своими наваторскими идеями и задвигает интероп с Java на второй план.
Итого получается что Kotlin это тот язык который имеет смысл тянуть в существующий проект, использовать его бок обок с написанным Java кодом, при этом это современный язык, с высокими гарантиями безопасности(smart-casts,NPE-free code) и умным компилятором.
Так какие объективные причины не взлететь Kotlin?
Сюда явно можно относить только тот код, который бежит на проде.
> Используется ли X в вашей компании?
А вот сюда как раз «вы знаете X» и «написали один класс для билда в проекте на X»