Вышел Kotlin 1.0

https://nulab-inc.com/blog/nulab/backlog-android-from-java-to-kotlin-with-lot... - вот тут еще примеров сравнения kotlin и java кода несколько.

А про не доверие к JetBrains -у них то как раз больше опыта работы с языками, имхо им доверять можно куда больше, чем Oracle. Тем более что JetBrains не собираются никого судить за использование Kotlin

Сразу видно крупного специалиста с большим опытом :)

Немного пробовал Kotlin, вот этого в Java очень не хватает:

if (a != null && a.b != null && a.b.c != null) {
    a.b.c.d();
}

a?.b?.c?.d()

Да, в Jython JIT работает. По-большому счету он работает в любых jvm компилируемых языках. В т.ч. и в jruby. Плюс там тоже легкая интеграция с java, настоящая многопоточность без блокировки главного потока и т.п. Скорость работы - до 5-ти раз быстрее обычного python (cpython), есть ещё pypy, там до 10 раз, но жрёт рамы больше.

Ни мобильной ни Web разработкой я профессионально не занимаюсь. Мой основной удел - это вообще C++/C# под винду сейчас.

P.S. Вот тут есть пример кода компилируемого в JS - http://try.kotlinlang.org/#/Examples/Canvas/Traffic light/Traffic light.kt (впрочем я думаю на try.kotlinlang.org абсолютно все примеры компилируются в JS и испольняются в браузере)

Пруфы давай.

Вот тут говорят что всё не так https://youtu.be/VAg-UuieTUw?t=1445

a != null && a.b != null && a.b.c != null

Если тебе приходится писать такие конструкции, ты определенно делаешь что-то не так.

Optional почти то же самое, но это выглядит удобнее.

Например есть класс, в который десериализуется сложный вложенный json от сервера. Сервер может вернуть null на любом уровне вложенности. Как предлагаешь избежать проверок?

Проблема не в том, скомпилится или нет, а сколько места займет. И ты еще заколебешься отлаживать кросс-компилированный код.

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

пока разрабатывались различные «улучшенные Java» типа Kotlin, Ceylon и Scala, сама Java обновилась до восьмой версии, где появились практчески все востребованные программистами-модниками фичи

Смешно. Джава 8 по возможностям не достигла даже C# 3.0. Со скалой или цейлоном ее нелепо даже сравнивать.

блин, ну расскажи про горести и страдания ведройд разраба? Интересно, честно.

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

Уже два года как активно используют.

Чем и для каких задач хаскель лучше джавы - понятно

Мне непонятно, расскажи.

Например? Что там есть такого, что вызывает непреодолимое желание на него переползти?

Крупные плюсы: null-safety, properties, val, when, хороший API для работы с коллекциями, data-классы, operator overloading, отсутствие checked exceptions, this-коллбэки (такого я вообще ни в одном языке не видел, шикарное изобретение), extensions, вложенные функции, destructuring, правильно перегруженный ==.

Огромный плюс в сравнение со всеми остальными JVM-языками — очень прозрачная интеграция с Java-кодом. По сути тут я видел единственную проблему — по умолчанию в Kotlin классы final и всякие аспектные библиотеки не могут от них отнаследовать свою проксю (реально это проблема этих библиотек, конечно, но кому от этого легче). Больше проблем нет. Использовать из Kotlin любую библиотеку не сложнее, чем из Java и наоборот — использовать любой Kotlin-код из Java очень просто.

Минус я могу сказать только один: нет try-with-resource. Есть ограниченная имитация через лямбды, но она неудобна, когда ресурсов много.

Чем и для каких задач хаскель лучше джавы - понятно

Мне непонятно, расскажи.

Можно написать на нём важную программу и значительно повысить свой Job Security Index.

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

Угу, код на C можно вообще не конвертировать и напрямую использовать в C++. Значит профит от C++ минимален? Феерическая логика. Любой язык автоматом конвертируется в машинный код, значит профит от любого языка минимален. Лол.

нормальные Java 8, Scala, Groovy, Clojure, etc.

Groovy явно лишний в этом списке.

Groovy явно лишний в этом списке.

Да и джава.

Я по задачам в вакууме не консультирую. Как только ты сформулируешь ограничения конкретного сценария, мешающего написать по-человечески - решишь все сам.

Значит профит от C++ минимален?

По сравнению с С - да, не фонтан.

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

Ты серьезно не понимаешь разницу между компиляцией и sed'ом?

По сравнению с С - да, не фонтан.

Фонтан, да ещё и какой.

Ты серьезно не понимаешь разницу между компиляцией и sed'ом?

А причём тут sed?

Забей на него, если человек не видит пользы от C++ в сравнении с C, то и пользы от Kotlin он не увидит.

По сравнению с С - да, не фонтан.

C, по сравнению с C++, просто фонтатище :-)

Забей на него, если человек не видит пользы от C++ в сравнении с C, то и пользы от Kotlin он не увидит.

Именно. Это как какой-то CoffeeScript и JS.

String json = getJson();// {"a":{"b":{"c":{"d":"value"}}}} или что угодно
MyClass m = new Gson().fromJson(json, MyClass.class);
String value = m.a.b.c.d; // NPE

class MyClass {
    A a;
}

class A {
    B b;
}

class B {
    C c;
}

class C {
    String d;
}

Что я делаю не так? И как это написать по-человечески?

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

        String value = m.getA().flatMap(A::getB).flatMap(B::getC).flatMap(C::getD).orElse(null);

class MyClass {
    private A a;

    public Optional<A> getA() {
        return Optional.ofNullable(a);
    }
}

class A {
    private B b;

    public Optional<B> getB() {
        return Optional.ofNullable(b);
    }
}

class B {
    private C c;

    public Optional<C> getC() {
        return Optional.ofNullable(c);
    }
}

class C {
    private String d;

    public Optional<String> getD() {
        return Optional.ofNullable(d);
    }
}

Что лишь доказывает требуемый обьем лапшы в Java коде :)

Кто ж спорит.

Интересует мнение комрадов. Пробовали? Что думаете?

Для андройда самое то!

Интересный язык

fun sayHello(maybe : String?, neverNull : Int) {
   // use of elvis operator
   val name : String = maybe ?: "stranger"
   println("Hello $name")
}

Конкретно для твоего случая я посоветую написать getter-ы, возвращающие Optional-ы.

И чем это лучше null?

И чем это лучше null?

Читать проще, все действия выписываются линейно, а не в виде гигантского дерева if-ов, в котором опечататься — как раз плюнуть.

Ну и забыть проверить на наличие значения становится сложней.

все действия выписываются линейно, а не в виде гигантского дерева if-ов, в котором опечататься — как раз плюнуть

Мне кажется, эта длинная макаронина с flatMap не лучше кучи выражений в if.

Что я делаю не так? И как это написать по-человечески?

Смени поставщика данных, очевидно.

Почитал я сравнение Kotlin и Scala (ссылка) и понял что плюсов по сравнению с последней у котлина нет.

Основные плюсы: код на Kotlin проще вызывать из код на Java; язык содержит меньше фич (спорный плюс); поддержка IDE лучше (Scala пользовал давно, могу ошибаться); не тянет огромную стандартную библиотеку (для Android говорят критично).

Переходить со Scala на Kotlin, наверное, смысла большого нет. А вот если переходить с Java, тут я бы выбрал Kotlin, а не Scala.

А там есть properties?

Kotlin — современный статически типизированный объектно-ориентированный язык программирования, компилируемый для платформ Java >>> и JavaScript <<<

Да.

Пока поддержка JavaScript там скорее экспериментальная, насколько я знаю. До релиза основной фокус был на JVM.

Скалисты вроде тоже обещали интеграцию с джавой. Собственно по беглому просмотру языка, он кажется даже удобнее хаскела (ну я имею ввиду open algebraic data type, ради которых вообще свой язык хотел писать). Но реально задача андроид аппа - тесное общение с АПИ, так что скала будет только путаться под ногами. Кложа, груви и прочее прочее для андроида не годятся только потому, что они юзают рефлекшен, из-за чего дико тупят. Я вообще не понимаю откуда на андроиде рефлекшен, если там не совсем джава да и вообще с 5 версии оно при установке вроде в натив компилит все.

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

Не вижу смысла вызывать код на Scala из кода на Java, только если наоборот.
Насчет поддержки IDE для Scala могу сказать только что в IDEA отличная поддержка Scala и SBT.
Насчет огромной библиотеки, судя по сорцам, Kotlin Standard Library меньше Scala Standard Library, что вполне очевидно, т.к. Scala все таки полноценный язык, а не надстройка. Но Scala stdlib все равно не такая уж большая поэтому я не вижу здесь особой проблемы, даже для андроида.

Когда я переходил с Java я выбрал Scala, а не Kotlin, потому что Scala предоставляет все, чего мне не хватало в Java, Kotlin нет. Кроме того, Scala развивается сообществом, а не корпорацией, что несомненный плюс с моей точки зрения.

this-коллбэки (такого я вообще ни в одном языке не видел, шикарное изобретение)

Можно ссылочку на описание? Дабы самому в доках не искать.

Любопытно, а если бенчмарк запустить на JVM и в браузере, во сколько раз/процентов медленнее будет?

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

Пример:

    fun buildString(builderAction: StringBuilder.() -> Unit): String = 
            StringBuilder().apply(builderAction).toString()

    val str = buildString {
        append("abc")
        append(123)
        append("def")
    }

аналог на Java:

    String buildString(Consumer<StringBuilder> builderAction) {
        StringBuilder stringBuilder = new StringBuilder();
        builderAction.accept(stringBuilder);
        return stringBuilder.toString();
    }

        String str = buildString(sb -> {
            sb.append("abc");
            sb.append(123);
            sb.append("def");
        });

Любопытно, а если бенчмарк запустить на JVM и в браузере, во сколько раз/процентов медленнее будет?

Скорее всего разные тесты будут показывать разные результаты. В среднем ставлю на JVM.

Не вижу смысла вызывать код на Scala из кода на Java, только если наоборот.

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

Насчет огромной библиотеки, судя по сорцам, Kotlin Standard Library меньше Scala Standard Library, что вполне очевидно, т.к. Scala все таки полноценный язык, а не надстройка.

Дело не в полноценности, а в том, что Scala переизобретает многое, что уже есть в стандартной библиотеке Java, а Kotlin просто использует. Это, кстати, ещё один момент в интероперабельности — либо мы пишем неидиоматичный Scala-код, либо конвертируем между типами коллекций на границе вызовов.

Но Scala stdlib все равно не такая уж большая поэтому я не вижу здесь особой проблемы, даже для андроида.

Я не специалист по андроиду, но читал, что это реальная проблема из-за каких-то особенностей андроида (вроде не более 65535 методов может быть в приложении) и Scala этот лимит сильно уменьшает.

Когда я переходил с Java я выбрал Scala, а не Kotlin, потому что Scala предоставляет все, чего мне не хватало в Java, Kotlin нет.

Ну могу сказать, что я рад за тебя (без иронии). Мне вот Kotlin предоставляет почти всё, что мне не хватает в Java, а Scala считаю непрактичной для 90% проектов из-за её чрезмерной сложности. Судя по популярности Kotlin-а я не один так считаю. В любом случае разнообразие всегда хорошо.

Кроме того, Scala развивается сообществом, а не корпорацией, что несомненный плюс с моей точки зрения.

Что имеется в виду? Насколько я знаю, Scala развивается Мартином Одерски, который является основателем коммерческой компании Typesafe. Я не вижу отличий.

Напоминает приемы метапрограммирования из Ruby (это про пример с html-билдером из документации).

проще сменить язык.