Аннотация NotNull не является частью системы типов Java, и компилятор Java никак не ограничивает использование nullable-значений в выражениях, которые могут привести к NPE.
Все, что делает компания JetBrains (за исключением минимального стартового капитала, на который трое основателей жили первый год), она делает на самостоятельно заработанные деньги. Владельцы компании, практически весь ее менеджмент, вся команда Kotlin — все русские. Так что непонятно, кто тут кому «просто наемный работник».
Ну почему «не так»? Он просто ориентирован на другую целевую аудиторию, другой способ мышления.
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
Освоиться с синтаксисом Java в любом случае крайне полезно, потому что основная масса документации и примеров, которые на данный момент доступны, использует именно Java. Каких-то задач, которые можно было бы решить только на Kotlin и нельзя было бы решить на Java, не существует. Так что в конечном итоге смотрите сами — если вам приятнее писать на Kotlin, то используйте его.
Я не знаю, что вы имеете в виду под словом «обвертка». Kotlin может транслироваться в байткод JVM (который может выполняться также на совместимых с ней виртуальных машинах, таких как Android), а также в исходный код на JavaScript и в нативный код, выполняемый вообще без виртуальной машины. У Kotin своя система типов и свои языковые фичи, несколько более сложные, чем "#define блять ;".
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Котлин — это не синтаксический сахар, а полноценный язык со своей системой типов и своей семантикой. Ключевое отличие системы типов Kotlin от Java — это поддержка nullable и non-null types, то есть, возможность определять в момент компиляции, какие выражения могут приводить к NPE, и запрещать компиляцию таких выражений. Свою JVM для этого иметь не надо, достаточно иметь свой компилятор.
Буковки «JVM» в названии «Kotlin/JVM» как бы намекают, что целевой платформой для компиляции и исполнения является JVM, то есть Java Virtual Machine, то есть виртуальная машина Java.
В Scala, помимо всего того, о чем вы говорите, есть также дизайн языка. Вкладывая силы в поддержку и развитие Scala, мы могли бы решить проблемы со временем сборки, удобством отладки, тестирования и т.д., но принципиально изменить дизайн языка мы не смогли бы. А мы считаем, что в этом мире должен существовать не только язык с таким дизайном, как у Scala, но и язык с таким дизайном, как у нас.
В целом вы правы, конечно. В случае котлина эта цена меньше, чем во многих других случаях — например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы, и то, что библиотека использует котлиновские фичи, не приведет к тому, что ее пользователям надо будет непременно переходить на котлин. Но да, про документацию и примеры всё так.
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)