Kotlin дает разработчикам Android-приложений возможность использовать мощный современный язык, код на котором получается более компактным и надежным, уменьшая вероятность падения приложений у пользователей. Kotlin прост в освоении и отлично сочетается с Java, что позволяет постепенно внедрять его в существующие проекты, не теряя накопленный опыт, навыки и технологии.
Плагин для поддержки Kotlin теперь входит в поставку Android Studio 3.0, так что разработчикам не нужно ставить дополнительные плагины или беспокоиться о совместимости. JetBrains и Google также берут на себя обязательство поддерживать разработку на Kotlin и в будущем, по мере развития Android-платформы.
При этом другие платформы, которые поддерживают Kotlin (Kotlin/JVM для разработки серверных и десктопных приложений, Kotlin/JS для браузера и Kotlin/Nativе для нативной разработки) остаются не менее важными для JetBrains. Наше видение заключается в том, чтобы создать единый инструмент, позволяющий разрабатывать все компоненты современного приложения на одном и том же языке, независимо от того, на какой платформе эти компоненты запускаются. Это включает в себя и full-stack веб-приложения, и мобильные клиенты под Android и iOS, и встраиваемые платформы IoT, и другое.
Как и с человеческими языками, для языка программирования очень полезно быть популярным. Официальная поддержка со стороны Android приведет к росту количества программистов на Kotlin, а это значит, что для Kotlin будет разрабатываться больше библиотек и инструментов, больше обучающих материалов, проще будет найти решения для возможных проблем или устроиться работать программистом на Kotlin. Мы очень рады новым перспективам, которые это открывает для экосистемы Kotlin!
Мы приняли решение о том, чтобы создать вокруг Kotlin некоммерческое партнерство совместно с Google. При этом разработка языка и в дальнейшем будет производиться силами JetBrains, и команда Kotlin (на данный момент более 40 человек) будет работать как и раньше. Ведущим дизайнером языка остается Андрей Бреслав, и принципы, которыми мы руководствуемся в разработке, никак не меняются. Наш дизайн по-прежнему будет открытым, потому что обратная связь со стороны сообщества необходима нам для того, чтобы развивать Kotlin в верном направлении.
19 мая 2017 года в 20:30 по московскому времени вы сможете посмотреть живую трансляцию доклада с Google I/O про Kotlin, который будут делать Андрей Бреслав и Хади Харири, ведущий евангелист JetBrains. А в ноябре у Kotlin состоится собственная конференция, которая пройдет в городе Сан-Франциско.
Огромное спасибо!
Когда Kotlin начинал свой путь 6 с лишним лет назад, мы поставили себе цель создать язык, ориентированный на те же принципы, что и другие наши инструменты — помогать разработчикам с рутинной частью работы, позволяя им сосредоточиться на том, что действительно важно. Программирование должно быть приятным и увлекательным занятием!
Мы крайне благодарны Google и Android-команде за то доверие, которое они нам оказали, но прежде всего мы благодарны вам — нашему сообществу, нашим пользователям. Без вас Kotlin не смог бы достичь того, чего он достиг сегодня. Спасибо вам, что вы были с нами на этом пути, и надеемся видеть вас с нами и дальше.
Частые вопросы
Мы подготовили ответы на некоторые вопросы, которые могут появиться у вас в связи с этим анонсом. Если вашего вопроса нет в списке, будем рады ответить на него в комментариях. Если вы не очень знакомы с Kotlin, вы можете найти ключевую информацию в FAQ на нашем сайте.
Будет ли Kotlin сфокусирован в первую очередь на Android?
Одна из основным целей Kotlin, и сейчас, и в будущем — это поддержка различных платформ. Мы продолжаем разрабатывать Kotlin/JVM (для серверных, десктопных и других приложений для Java-платформы) и Kotlin/JS. Для других платформ, таких, как macOS, iOS и встраиваемые/IoT системы, мы ведем работу над Kotlin/Native.
Как это повлияет на релизный цикл Kotlin?
Как и раньше, у Kotlin будет свой релизный цикл, не привязанный к релизам Android или Android Studio. Проекты остаются полностью независимыми. Конечно же, мы будем тесно сотрудничать с разработчиками из Google, чтобы Kotlin всегда оставался совместимым с Android Studio и другими инструментами Android-разработки.
Кто будет разрабатывать плагин для Android Studio?
Как и раньше, за разработку плагина для Android Studio будет отвечать JetBrains. Мы планируем плотно сотрудничать с командой Android Studio.
Повлияет ли это на поддержку Kotlin в IntelliJ IDEA, Eclipse или NetBeans?
Нет. Kotlin — это многоплатформенный язык, и мы будем вкладываться в поддержку различных IDE так же, как и раньше. Основные наши усилия сосредоточены на плагине для IntelliJ IDEA, и мы будем рады помощи сообщества в работе над плагинами под Eclipse и NetBeans.
Повлияет ли это на поддержку macOS и iOS?
Нет. Мы планируем поддержать обе эти платформы в Kotlin/Native, и этот план никак не меняется.
Собирается ли Google купить JetBrains?
Нет. JetBrains не планирует продаваться никакой другой компании. Мы были и остаемся независимым производителем инструментов для всех разработчиков, независимо от того, на каком языке и под какую платформу они программируют.
Комментарии (99)
VioletGiraffe
18.05.2017 23:13-6Гикам, энтузиастам и просто скучающим программерам вопрос может показаться странным, но… зачем? Зачем новый стрёмный язык, когда есть обкатанная Java c миллионом библиотек и готовых решений под неё? Вряд ли у Java есть такие фатальные недостатки, которые лечит новый язык (учитывая, что Java тоже не стоит на месте).
xhumanoid
18.05.2017 23:28+3может ответ содержится в вашем вопросе?
kotlin запускается на jvm и может использовать «c миллионом библиотек и готовых решений под неё», но добавляет немного синтаксического сахара. Можете из kotlin дергать java код или из java дергать kotlin код, все в ваших руках.
Возможность решать какую-то задачу и решать удобно эту же задачу это совершенно разные уровни решения =)
georgeci
18.05.2017 23:33+4В мире бэкенда Java может и развивается, но в мире Android застряла на java 6 (с добавлением сахара из 7 и 8)
yole
19.05.2017 00:10+5Вы можете найти ответ на ваш вопрос во втором абзаце записи, под которой вы оставили этот комментарий.
konsoletyper
19.05.2017 00:12+6Ну это интересный вопрос. Я, как один из разработчиков языка, должен бы по идее защищать язык. Однако, скажу честно: я не знаю. Я так понимаю, просто есть разные люди с разным мировосприятием, кто-то хочет стабильности и надёжности (и поддерживаемости кода конченными индусами), кто-то хочет чего-то с приятными синтаксисом. Так что пусть на вопрос "зачем" отвечают разработчики для самих себя. Как мы видим, достаточно большая часть разработчиков нашла ответ на этот вопрос, и Google даже пришлось пойти им навстречу.
Для себя я придумал такое объяснение, зачем мы делаем Kotlin — чтобы дать людям выбор. Ну и ещё одно — чтобы у людей была возможность писать fullstack-приложения. В мире JS есть node.js, почему в мире Java нет fullstack-решения? Есть GWT, но он в последнее время тихо загибается, плюс это сторонний инструмент от стороннего разработчика, а не официальная технология от разработчиков Java. Мы же в Kotlin координируем усилия между командами, разрабатывающими JVM, JS и Native бэкэнды. А некоторые внутренние продукты JetBrains уже пишутся на fullstack Kotlin.
когда есть обкатанная Java c миллионом библиотек и готовых решений под неё
Ваша ошибка в том, что эти библиотеки "для Java". Это не так, Kotlin прекрасно работает с библиотеками, созданными специально "для Java"
VioletGiraffe
19.05.2017 00:18+1Резонно, спасибо за ответ. Не уловил, что Kotlin настолько хорошо совместим с Java, теперь буду знать.
Nikelandjelo
19.05.2017 04:08Из статьи: «а это значит, что для Kotlin будет разрабатываться больше библиотек». Да, в идеальном мире все библиотеки будут работать и в джаве, и в котлине, и в скале, и везде. Но в реальном мире это приведёт к какой-никакой но фрагментации. Появятся библиотеки, которые будут заточены специально под котлин, использовать какие-то фичи котлиновские. И значит что если ты пишешь на джаве в какой-то момент тебе возможно придётся перейти на котлин, чтобы использовать какие-нибудь такие библиотеки. И это распыляет усилия сообщества. Вместо того, чтобы иметь 1 классную библиотеку, будет пару «ну ничего» библиотек.
Так же теперь надо будет всю документацию с примерами дублировать на нескольких языках и подобные вещи по поддержке.
Да, выбор — это хорошо, но все же у него тоже есть своя цена. Эту цену сложно «пощупать», но она есть.yole
19.05.2017 08:58+1В целом вы правы, конечно. В случае котлина эта цена меньше, чем во многих других случаях — например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы, и то, что библиотека использует котлиновские фичи, не приведет к тому, что ее пользователям надо будет непременно переходить на котлин. Но да, про документацию и примеры всё так.
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)konsoletyper
19.05.2017 12:49+1например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы
Ну даже "из коробки" тот API, который Kotlin отдаёт Java, выглядит достаточно удобным и естественным, за исключением классов, оканчивающихся на Kt, и необходимости явного обращения к companion object. Обе претензии больше эстетические, чем концептуальные, да и возникают подобные ситуации не очень часто.
gildor
23.05.2017 12:44Кстати оба этих момента можно решить силами котлина:
оканчивающихся на Kt
Можно анотировать файл
@file:JvmNameи указать желаемое имя
необходимости явного обращения к companion object.
Анотировать члены companion object с помощью
@JvmStatickonsoletyper
23.05.2017 13:30+1Я в курсе. Речь была о том, что даже если автор не позаботился о расстановке этих аннотаций для удобства использования из Java, то полученный негативный эффект будет не более, чем косметическим.
gildor
23.05.2017 13:48Тут вы правы, комментарий больше для тех, для тех кто может быть не в курсе, что такое поведение можно поменять
liverpool67
19.05.2017 05:28-1Когда появился swift от Apple решил что подожду что из этого выйдет, в итоге главный разработчик уволился из apple будущее языка туманно, apple сама не пишет свои продукты на нем, в итоге сижу на obj-c и радуюсь. Так же с android, буду сидеть на java. А там посмотрим… перейти никогда не поздно)
umren
19.05.2017 12:48+6Простите, а в чем туманность будущего Swift? скоро выходит 4 версия, 3 версия чуть более чем прекрасно, развитие идет семимильными шагами, половина работодателей уже пишет все новое на Swift. Для языка которому 3 года в паблике это огромные достижения.
zolt85
19.05.2017 08:05А что там с Kotlin/Native под Windows? На крайнем JPoint-е Андрей, вскользь, сказал, что есть пока проблемы, но конкретики не дал.
yole
19.05.2017 09:01+2Все хорошо :) На днях коллега на стэндапе рассказывал, что тетрис завелся.
zolt85
19.05.2017 13:49Это хорошо.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
WayMax
19.05.2017 08:09-8Котлин это всетаки язык, или обвертка (как на картинке) для джавы?
http://cs5.pikabu.ru/post_img/2014/07/03/1/1404337531_1801068260.jpgyole
19.05.2017 09:01+2Язык. Со своим компилятором под три разных платформы, своей системой типов и много чем ещё.
WayMax
19.05.2017 09:53-9Виртуальные машины тоже свои?
yole
19.05.2017 09:58+4Пожалуйста, прочитайте пост, который вы комментируете. Там вполне явно написано, под какие платформы компилируется котлин.
WayMax
19.05.2017 10:56-14Я прочитал, если бы не прочитал вообще бы не писал сюда. «Kotlin/JVM» и что дальше? Это виртуальная машина котлина или джавы?
Причем здесь вообще компиляция? Я про исполнение кода, а не про компиляцию кода. Пожалуйста, прочитайте комментарий, который вы комментируете.
PS: И не надо агриться. Я вас серьезно спрашиваю.yole
19.05.2017 12:50+4Буковки «JVM» в названии «Kotlin/JVM» как бы намекают, что целевой платформой для компиляции и исполнения является JVM, то есть Java Virtual Machine, то есть виртуальная машина Java.
WayMax
19.05.2017 13:56-18А буковки «Kotlin» на что намекают? Чтобы не было непонимания так бы и писали «JVM». Если котлин использует обычный стандартный JVM, значит он только обвертка для обычной стандартной Джавы. А вы тут лапшу развешиваете.
Уже всей своей шарагой минусов наставили или еще нет? Позовите еще хипстеров или для кого там ваша обвертка сделана, пускай они поминусуют.yole
19.05.2017 14:02+17Я не знаю, что вы имеете в виду под словом «обвертка». Kotlin может транслироваться в байткод JVM (который может выполняться также на совместимых с ней виртуальных машинах, таких как Android), а также в исходный код на JavaScript и в нативный код, выполняемый вообще без виртуальной машины. У Kotin своя система типов и свои языковые фичи, несколько более сложные, чем "#define блять ;".
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Bringoff
22.05.2017 08:50+1Kotlin запускается на JVM, значит, это обертка для джавы. Видимо, Groovy и Scala вы тоже не уважаете. F# запускается на дотнетовской CLR, значит, это обертка для C#? C++ запускается вообще без виртуальной машины, значит, это обертка… эмм, для ассемблера? Забавная у вас логика.
lxsmkv
20.05.2017 16:58-1шикарная картинка, Думаю с этого надо начинать обучение C++, это круто, как скины, только для языка программирования :) Я раньше обходил C++ стороной а теперь заинтересовался.
Mishkun
19.05.2017 08:58+2Спасибо вам за работу, язык после джавы как спасение. Одни только property чего стоят. Желаю и дальше расти и подстегивать Java вводить удобство в язык
zikolach
19.05.2017 10:01+5Не холивара ради, искренний вопрос — зачем? Не лучше ли было поддержать и развивать Scala, ведь там уже есть все то на что вы тратите время разаботчиков (взаимодействие с Java, поддежка компиляции в Javascript и ScalaNative). Уже сформированное сообщество и экосистема.
Пытаюсь найти для себя ответ — не нахожу пока. Хотелось бы увидеть честное сравнение с примерами реального кода, временем сборки, удобством отладки, тестирования и т.п.
С уважением отношусь к JetBrains и пользуюсь вашими продуктами.TihoFih
19.05.2017 10:15+6Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.
Интервью с Максимом Шафировым
yole
19.05.2017 10:42+5В Scala, помимо всего того, о чем вы говорите, есть также дизайн языка. Вкладывая силы в поддержку и развитие Scala, мы могли бы решить проблемы со временем сборки, удобством отладки, тестирования и т.д., но принципиально изменить дизайн языка мы не смогли бы. А мы считаем, что в этом мире должен существовать не только язык с таким дизайном, как у Scala, но и язык с таким дизайном, как у нас.
zikolach
19.05.2017 17:07+1Спасибо за комментарий! А не могли бы ткнуть ссылкой или пояснить, что в первую очередь не так с дизайном языка? Я рассуждаю с точки зрения пользователя — интересно узнать мнение разработчика языка...
yole
19.05.2017 17:23+3Ну почему «не так»? Он просто ориентирован на другую целевую аудиторию, другой способ мышления.
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
complete_unknown
19.05.2017 12:47+4Очевидно, что у Скалы есть фатальный недостаток: ее писали не в JetBrains.
lxsmkv
20.05.2017 00:01http://www.programming-idioms.org/idiom/12/check-if-list-contains-a-value
Вот пример того какими средствами достигается решение типовой задачи поиска в списке в разных языках, котлина там нет но я посмотрел, в нем как в Питоне.
Сразу оговорюсь я на языки смотрю прагматично, на чем надо на том и работаю. Но, есть некоторые, вполне объективные критерии.
Скала не сильно удобочитаемый язык. И Ява хоть и привычный, распространенный но тоже не удобочитаемый язык.
Язык может быть мощным но он должен быть и удобочитаемым. Ведь, как известно, мы больше читаем чем пишем код. Следовательно, чем легче его воспринимать, тем лучше.
Все эти академические каверзы не нужны простым смертным, недопрограммистам, типа меня (прим авт. — для меня программист это тот кто может и свой компилятор зафигачить и микроконтроллер для умного дома запрограммировать). Им нужна простота в освоении и использовании.
Быстро добиться результата. Переводить мысли в код как можно более непосредственно. Не лазить в гугл как перевести мою мысль на язык программирования ХYZ.
Это прекрасно, кодгда «как думается так и пишется» (по аналогии с немецким языком, где «как пишется так и читается») И большие корпорации давно поняли что уже не девяностые, ай-ти это не секта куда принимают только избранных, идет борьба за человеческий ресурс. А ресурс он разный, планку надо понижать, именно понижать. И ничего в этом страшного нету. Доступность это не «опопсение» как некоторым кажется, а взросление.
gkislin
22.05.2017 12:35-1Вот хорошая статья (можно начало по диагонали прочитать): https://habrahabr.ru/post/260149/
Про скала верно написано:
Цели создателей языков тоже на удивление разнообразны. Вот c какой целью Odersky создавал Scala? Может быть это были сугубо академические (исследовательские) цели, и ему, как исследователю, было интересно сделать что-то новое вокруг идеи связки функционального и объектно-ориентированного программирования… Понятно, что хороший язык, тем более писаный гениальными чуваками, типа Odersky, можно использовать по-разному, и он будет хорош. Но все же, максимальный эффект язык даст в том случае, когда он используется в соответствии с теми целями, ради которых язык создавался.
Для меня также основная задача языка (как и фреймворка) — упростить и ускорить разработку и поддержку
elizarov
19.05.2017 16:37+1Мне кажется что лучший ответ на этот вопрос дала компания Google в своем официальном блоге (см. секцию Why Kotlin): https://android-developers.googleblog.com/2017/05/android-announces-support-for-kotlin.html
Там раскрыты все основые причины. Попробуйте примерить туда Scala и вы поймете почему не Scala.
nile1
19.05.2017 16:37+2Вы попробуйте как-нибудь прийти в команду с проектом на Scala, который разрабатывается уже пару лет. Я бы ни за что не стал использовать Scala в качестве массового языка общего назначения. Проблемы навскидку:
— Высокий порог вхождения
— Гибкость языка приводит к тому, что одну задачу можно решить кучей способов, при этом результат зачастую выглядеть так, как будто под каждую задачу изобретается новый синтаксис языка (особенно если используются «богатые» фичи библиотек вроде scalaz)
— Плохая поддержка IDE. Из-за отсутствия жёсткого синтаксиса как такового (можно определять собственные операторы, использовать символы вроде <#= в именах методов), IntelliJ порой просто сходит с ума и светит весь код красным, пока не допишешь корректный код.
— Плохая совместимость с Java. Из Scala вызывать Java код ещё терпимо, но в обратную сторону практически невозможно.
— Проблемы обратной совместимости между версиями самой Scala: нужно иметь версии всех библиотек, скомпилированные одной версией компилятора Scala.
— Медленный компилятор
— Конкретно для Android также критичен размер рантайма, насколько помню у Scala он слишком большой для Android.
Список можно продолжать долго, но важно что все эти моменты учтены командой Kotlin, и получился действительно прагматичный элегантный язык, который двумя словами можно назвать «better Java». Пожалуй единственный другой язык на котором также было приятно писать, был C# (из которого кстати Kotlin взял много идей, но хватает и уникальных фич).
Собственно, Google не поддержал в своё время Scala, а Kotlin поддержал и довольно быстро. Это уже говорит о многом.
Кроме того, по ощущениям бурный рост Scala остановился около года назад (если тот рост, что был до этого можно назвать бурным), и я сталкивался с несколькими проектами, которые отказались от Scala и либо вернулись на Java, либо совсем ушли с JVM в сторону других языков (Go, например).
Более того, компания создателя Scala Мартина Одерски (Typesafe) сменила название на Lightbend, и теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala.zikolach
19.05.2017 17:05Был бы рад если бы кто-нибудь также навскидку перечислил преимущества Kotlin:
- низкий порог вхождения
- один способ решения всех проблем (понятный всем и каждому)
- отличная поддержка IDE (честно удивился бы обратному)
- отличная совместимость с Java (Kotlin код вызывать из Java одно удовольствие, расскажите есть ли проблемы?)
- обратная совместимость между версиями языка/компилятора на уровне байткода/исходников
- быстрый компилятор
- миниатюрный рантайм
- и многие другие...
И желательно аргументированно с примерами.
Хочется увидеть такой списочек и вдохновившись пойти изучать Kotlin. Но на практике большая часть примеров (киллер фич) переписывается на Scala короче и понятнее (не намного впрочем). Сложности с освоением Scala до уровня среднего разработчика приложений во многом надуманы как мне кажется.
Я согласен с аргументом из первого ответа — JetBrains интересно быть разработчиком собственного языка. Получается ли им убедить в том что их язык нужен сообществу — по-чесноку — не похоже. Лично мне кажется, если у JetBrains хватит денег/терпения развивать язык достаточно долго — он может быть и выстрелит, если нет — переименуются в крайнем случае :)
senia
20.05.2017 00:40+3Вы попробуйте как-нибудь прийти в команду с проектом на Scala, который разрабатывается уже пару лет.
Вот как раз недавно в такой проект пришел и даже принял его разработку (старая команда планово ушла через пару недель совместной работы). Полет нормальный.
— Высокий порог вхождения
Люди почти без опыта программирования (с базовыми теоретическими знаниями java) осваивают scala без труда.
— Гибкость языка
Изобретать DSL можно и на java. И иногда это даже оправдано. А scalaz вообще-то используют либо при разработке библиотек, либо знатные извращенцы, которые на любом языке нагородят, например подключив vavr.io в java.
— Плохая совместимость с Java.
Зависит от. Но extension методы котлина вам будет не менее весело вызывать из java, чем аналогичные extension методы скалы. С параметрами по умолчанию та же проблема в обоих языках. Методы с implicit параметрами вы вызвать сможете, только передать их вручную придется. Единственное, что реально не вызываемо это макросы, но довольно логично, что библиотеки метапрограммирования на scala не вызывать из java, как inline методы котлина не вызвать снаружи.
— Проблемы обратной совместимости
Да, это не приятно. Но эта проблема на плечах разработчиков библиотек. sbt берет нужную версию автоматически. И на данный момент актуальных версий 2: 2.11 и 2.12.
— Конкретно для Android также критичен размер рантайма, насколько помню у Scala он слишком большой для Android.
Сам рантайм — нет. С доп. библиотеками — да. Решается через proguard.
Кроме того, по ощущениям бурный рост Scala остановился около года назад
Что вы подразумеваете под ростом скалы? Основной инструментарий (akka, play, slick, etc) развивается стабильно. Сама scala сейчас идет к версии 3.0 (см dotty). Проекты на scala — тут у меня выборки нет.nile1
20.05.2017 14:35+1Люди почти без опыта программирования (с базовыми теоретическими знаниями java) осваивают scala без труда.
Либо речь об очень ограниченном использовании Scala (на которой можно «писать Java код» без использования продвинутых фич), либо вы сильно преувеличиваете, либо качество результата оставляет желать лучшего.
Достаточно взглянуть на курсы по Scala от Мартина Одерски на Coursera, чтобы понять что по-настоящему «освоить без труда» этот язык невозможно: https://ru.coursera.org/specializations/scala
Изобретать DSL можно и на java.
В том и дело, что невозможно. Можно делать API из методов под предметную область, но это совсем другая тема.
Kotlin позволяет делать DSL (взять хотя бы DSL для Gradle или Anko), но его возможности довольно сильно ограничены и для меня это скорее плюс.
Но extension методы котлина вам будет не менее весело вызывать из java
Extension функции в Kotlin это просто синтаксический сахар и реализуется через статические методы (как и в C#, откуда взята эта фича): http://stackoverflow.com/a/28364983
Есть отдельные проблемы со статическими полями и прочим, но это встречается не очень часто и решается аннотациями вроде @JvmStatic, есть официальный гайд: https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html
Но эта проблема на плечах разработчиков библиотек.
А если библиотека не развивается активно (но при этом достаточно стабильна и удовлетворяет потребности)?
Для любых недостатков есть обходные пути, но это же не значит что они несущественны.
Если есть проблемы на плечах разработчиков библиотек, значит косвенно эти проблемы и на плечах всех остальных разработчиков, которым нужно сначала дождаться пока все используемые библиотеки добавят поддержку новой версии, найти альтернативу или форкнуть и допилить самим.
Что вы подразумеваете под ростом скалы?
Имел ввиду популярность среди разработчиков. По ощущениям, популярность сохраняется только в области Big Data, во многом благодаря Spark.
В целом, мое субъективное имхо: если хочется продвинутый функциональный язык, то лучше брать что-то более «чистое» вроде Elixir и Haskell, или даже Clojure. Здесь более менее понятная ниша и ожидания.
Если хочется «простой» ООП, то остается выбор между Java, Kotlin, Go и многими другими языками в зависимости от потребностей.
Scala в этом смысле является «неведомой зверушкой», странной комбинацией ООП, ФП и собственных фич (вроде implicit приведения типов), которая вроде бы умеет все понемногу, но в итоге это только усложняет процесс разработки.
Это сугубо мое личное мнение на основе собственного опыта, статистикой и экспертными мнениями подкрепить не могу.
Вполне допускаю, что все описанные недостатки несущественны для отдельных людей и проектов, и хорошо, что у людей есть выбор. Kotlin взял немало идей из Scala, и учел многие недостатки (но и значительно ограничил возможности). Каждому свое.senia
20.05.2017 23:47+2Либо речь об очень ограниченном использовании Scala (на которой можно «писать Java код» без использования продвинутых фич), либо вы сильно преувеличиваете, либо качество результата оставляет желать лучшего.
Я курсы по scala веду. Народ за месяц осваивает slick, akka, akka-http, scalaTest, etc. Естественно не на глубоком уровне, но на глубоком уровне и java за месяц не освоить. Но они в состоянии использовать эти инструменты.
Курсы на coursera обучают скорее идеоматическому FP, чем именно скале. Например неплохо бы знать что такое параметрические тесты, но можно и без них обойтись.
Kotlin позволяет делать DSL (взять хотя бы DSL для Gradle или Anko), но его возможности довольно сильно ограничены и для меня это скорее плюс.
Пройдите по ссылке на vavr.io и посмотрите какие DSL таки можно делать на java. А на котлине… Вас не затруднит перечислить все варианты того, чем могут быть «f» и «v» в данном коде на Kotlin: m{f(v)}?
А если библиотека не развивается активно (но при этом достаточно стабильна и удовлетворяет потребности)?
Не видел такого, но однажды подключал не стабильную библиоткеку прямо как проект с github (это 1 строчка в sbt). В таком случае не надо вообще заморачиваться с версиями scala.
Extension функции в Kotlin это просто синтаксический сахар и реализуется через статические методы (как и в C#, откуда взята эта фича)
Я в курсе. А extension методы скалы — это просто синтаксический сахар над классами-обертками и вызываются соответствующим образом. Все аналогично. Хотите ссылку на аналогичный гайд для scala?
Про популярность — если брать объективные критерии: github и SO, то популярность растет. Но эти критерии не идеальны. Если брать мои субъективные ощущения, то популярность scala вокруг меня за год выросла раз в 10, что характеризует только крайне локальные изменения вокруг меня, а не картину в целом, как и любые другие субъективные критерии.
Troxid
20.05.2017 16:06+2теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala.
Приведите пример хотя бы одного такого фреймворка. Со всеми фреймворками lightbend'a, которые я знаю, ситуация абсолютно обратная.
Проблемы обратной совместимости между версиями самой Scala: нужно иметь версии всех библиотек, скомпилированные одной версией компилятора Scala.
Только бинарная обратная совместимость. Сам язык не менялся особо. Впрочем посмотрим какая совместимость будет у Котлина после 13 лет, сейчас ему пока что нечего ломать, он только релизнулся.
Из Scala вызывать Java код ещё терпимо, но в обратную сторону практически невозможно.
Настолько невозможно, что для большинства больших скаловских фреймворках есть поддержка джавы.
Зато у Котлина "нет" никаких проблем даже с использованием Java кода. Ну а про обратный вызов я вообще молчу, все эти костыли с@JvmStatic,KtClassextenstion methods и т.д. точно не говорят про 100% обратный интероп. Особенно мне интересно как можно использовать Котлиновскийsuspendметод из java кода. В последний раз когда я попытался использовать такой метод, IDE мне нагенерела такой треш, в котором было очень сложно разобраться.
Единственная причина, в моем понимании, почему Котлин начал набирать какой то успех в Android среде, это потому что у них до сих пор 6 Java. Те, кто может использовать 8ку, сидят на Java и не торопятся менять язык просто из-за "клевого" синтаксиса и null-safety которого нет, т.к. если вы собрались использовать Java библиотеки то для Котлина такие типы будут обозначены как Type! т.е. тип который может null'ом, а может и нет и система типов вам в этом ни как не поможет.
nile1
20.05.2017 16:21https://www.lightbend.com/blog/questions-answered-on-the-change-to-lightbend-and-lagom-for-java
Why is Lagom Java-first?
Many factors affected the decision to release Lagom first with a Java 8 API and then a Scala API to quickly follow.
Также можно поискать по слову «Java» в анонсе переименования компанииTroxid
20.05.2017 16:44+1Привожу цитату вашего комментария снова
теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala
Заходим на гитхаб, репозиторий lagom.
Проценты кода на Скале: ~70, на Джаве: ~30.
Большинствоcoreпакетов на Скале. Неплохая такая обертка в 70%.
В анонсе ни чего про обертки не нашел, сказано только про API. Само ядро фреймворка написано на Скале.nile1
20.05.2017 17:02+1фреймворки для Java, а не на Java.
Это просто признак того, что рынок Scala растет недостаточными темпами для финансовой успешности Lightbend, и приходится менять фокус. Собственно, большинство комментариев к статьям по ссылкам о переименовании в Lightbend говорят о том же.
Я не настаиваю на верности своего утверждения, в целом мой комментарий был не об этом. Я ничего не имею против успешности Scala, просто мне (и многим другим) этот язык не подходит. Хорошо, что есть выбор.
Я выбираю Kotlin, если хочется «better Java» без излишнего упора на функциональщину. Из новых языков также понравилось писать (а ещё больше — читать) код на Go, несмотря на изначальный скепсис из-за отсутствия дженериков, null safety и immutability. Kotlin и Go — оба прагматичные языки, с opinionated ограничениями заложенными авторами языка, и своей философией.
Java 8 тоже не так уж плоха, и тут я соглашусь с одной из основных (но не единственной) причин успеха Kotlin на Android.Troxid
20.05.2017 17:59+2Я так же ни чего не имею против Котлина и других языков, особенно Go, у которого свой рантайм, свой стек, свое коммьюнити и т.д.
Просто какая сейчас ситуация. Есть язык Java, со своим большим количеством библиотек. Сам по себе язык не особо фичастый, поэтому эти библиотеки можно использовать из любого JVM языка без особых сложностей (кроме чистых, таких как Frege). Потом появляется языкX1из которого другим JVM языкам код вызвать или нельзя или вызывается со сложностями. Но это не особо проблематично, когда такой язык позиционировался ни какbetter Java, а как другой язык, со своей парадигмой. Тогда комьюнити создает для самих себя такие обертки/библиотеки, более идиоматичные и использует их внутри своего языка.
По моему мнению, Скала занимает здесь промежуточный вариант, можно использовать чисто Java библиотеки и получать ~75-100% ООП или же использовать Скаловские, которые могут использовать сложные библ по типу shapeless, но зато являются более типобезопасными. Что из этого лучше, более простой код, но падающий в рантайме или более сложный но не проходящий компиляцию, вопрос отдельный и наверное сильно зависит от контекста применения.
Но вот проблема начинаются когда язык позиционируется со 100% интеропом, что в одну сторону, что в другую, но такого не имеет. Это может привести к расколу в экосистеме JVM. Будут появляется библ на Котлине, которые будут использовать фичи Котлина и они конечно будут недоступны на других язык, в том числе Java. Было бы правильно хотя бы на сайте Котлина перечислить что работает хуже или в вообще не работает в Java. Уже сейчас я начинаю замечать в Котлиновских библ очень частое использование extension methods, там где они даже не нужны или сильно запутывают код.
nehaev
19.05.2017 20:52Не лучше ли было поддержать и развивать Scala
Не совсем понятно, кому именно задан этот вопрос? Если гуглу, то с тем же успехом можно спросить, почему они не хотят поддерживать и развивать Java на Android. Примерно год назад ходили слухи, что они-таки перейдут на OpenJDK в Android 7, но этого, как я понимаю, не случилось. По идее, переход на актуальную версию Java позволил бы прикладным разработчикам самим выбирать, на каком JVM-языке писать (включая собственно язык Java, ставший гораздо более приятным по сравнению с шестеркой). Но похоже вместо этого разработчикам просто кинули кость в виде «официальной поддержки» одного только Котлина.
Со Скалой так сделать было нельзя, поскольку начиная с 2.12 она компилируется только под восьмерку — и это был осознанный выбор Scala-комьюнити, сделанный около 4-х лет назад. И я в свое время тоже голосовал за переход на восьмерку, потому что на Android джава-мир не заканчивается, и даже не начинается :)
nullc0de
19.05.2017 12:25+1«уменьшая вероятность падения приложений у пользователей.» Интересно каким образом это происходит? Ведь Котлин это не более чем синтаксический сахар, который транслируется в байткод java и запускается на jvm. У Котлина же нет своей JVM. Котлин мне вообще как язык не зашел. Хотя есть большой опыи на java и .net. Из всех java подобных языков мне больше всего нравится dart у которого своя виртуальная машина, и очень хороший синтаксический сахар и статический анализатор из коробки.
yole
19.05.2017 12:54+4Котлин — это не синтаксический сахар, а полноценный язык со своей системой типов и своей семантикой. Ключевое отличие системы типов Kotlin от Java — это поддержка nullable и non-null types, то есть, возможность определять в момент компиляции, какие выражения могут приводить к NPE, и запрещать компиляцию таких выражений. Свою JVM для этого иметь не надо, достаточно иметь свой компилятор.
solver
21.05.2017 15:06Другими словами, ключевое отличие системы типов Kotlin от Java — это замена аннотации NotNull на синтаксический сахар в виде символа "?"… я правильно понял?
yole
22.05.2017 08:24Аннотация NotNull не является частью системы типов Java, и компилятор Java никак не ограничивает использование nullable-значений в выражениях, которые могут привести к NPE.
solver
22.05.2017 12:58Да, я в курсе про то что эта аннотация, не является частью системы типов Java.
Просто судя по всему, эта аннтация перекрывает большинство кейсов применения.
Akuma
19.05.2017 14:05Подскажите, какие преимущества Kotlin для начинающего Android-разработчика?
Пишу исключительно для себя и своих нужд, но поскольку с Java не слишком в ладах, постоянно смотрю в сторону других решений, особенно JS (т.к. сам веб-разработчик), но всегда есть куча ограничений и неудобств. Здесь кроме нового синтаксиса ничего для себя не обнаружил, а синтаксис для меня в Java «новый», по сути. Может что-то упустил?yole
19.05.2017 14:13Освоиться с синтаксисом Java в любом случае крайне полезно, потому что основная масса документации и примеров, которые на данный момент доступны, использует именно Java. Каких-то задач, которые можно было бы решить только на Kotlin и нельзя было бы решить на Java, не существует. Так что в конечном итоге смотрите сами — если вам приятнее писать на Kotlin, то используйте его.
vlsinitsyn
19.05.2017 15:46+1А какой фреймворк для web приложений рекоммендует сейчас использовать JetBrains с Kotlin?
yole
19.05.2017 15:47+3Какой вам больше нравится. Можно Spring, можно vert.x, можно ktor (http://github.com/kotlin/ktor).
vlsinitsyn
19.05.2017 23:56-1Чей-то как-то так себе. Выбор между Spring и проектами с непонятной перспективой куда комитят пару человек для серьезного проекта и не выбор вовсе. Помнится давно были разговоры о Play. Теперь, я так понимаю, эта тема заглохла окончательно. Может тогда все же пора заняться серьезно вопросом фреймворка, а не упавать на авсь мол что-то такое само взрастет? Уже сколько лет ведь…
nile1
20.05.2017 14:03+2Выбор между Spring и проектами с непонятной перспективой
Выбор тот же самый, что и для Java: Spring Boot, Dropwizard или любой другой.
В том и прелесть Kotlin, что в отличие от Scala не требуется изобретать велосипеды заново, а можно использовать стандартный стек технологий Java.
Я конвертировал проект на Dropwizard + Guice с Java в Kotlin, за пару часов исправил все проблемы компиляции, и можно продолжать развивать проект не отвлекаясь на поиск новых сырых альтернатив.vlsinitsyn
20.05.2017 14:56-2Отличная новость! Расскажите пожалуйста, как использовать Play с Kotlin?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.nile1
20.05.2017 15:32+1Думаю, что Play с Kotlin использовать ровно также как Play с Java. Могут быть какие-то особенности из-за того что Play написан на Scala, но способы их решения идентичны Java.
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
nile1
20.05.2017 15:40Самый простой способ — это создать простой проект на Java, и автоматически конвертировать его в Kotlin средствами IntelliJ IDEA.
vlsinitsyn
20.05.2017 23:45-1… и код покрывается красным. Причем, по причинам, далеко не всегда очевидным тем, кто начинает разбираеться с языком.
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
nile1
21.05.2017 04:07+3Откуда менторский тон? Я вам что-то должен? Вы же сами задали вопрос. Я сказал, что без проблем завел проект на Dropwizard, а Play не пробовал, но должно быть близко к тому, как создавать проект на Play с Java (и предупредил, что возможны подводные камни, т.к. Play сделан на Scala).
мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Я не утверждал, что «Play нефик делать подружить с Kotlin». Я сказал, что проще всего начать с Java проекта, и попробовать перевести его на Kotlin.
Я не использую Play, если вам интересно попробуйте сами и поделитесь с сообществом.
Если у вас есть практическое доказательство, что Play с Kotlin не заводится — приведите «пример неработающего проектика», будет полезно знать.
Spring Boot и Dropwizard работают на практике, а не в теории.
с котлином не заработал mockito
Mockito 2 поддерживает Kotlin http://hadihariri.com/2016/10/04/Mocking-Kotlin-With-Mockito/
С интерфейсами в тестах и так не было проблем.
Есть также известная проблема с open-классами и Spring, но и для этого есть плагин для компилятора, который делает все классы open по умолчанию.
Я не спорю, что эти плагины являются костылями, но Mockito и Spring сами зачастую используют низкоуровневую магию с модификацией байткода (и например позволяют редактировать значения final и private полей), что я никак не могу назвать best practice. Если использовать интерфейсы для тестов, и autowiring через конструкторы для Spring, то никаких проблем не возникнет и в Kotlin.
nile1
21.05.2017 13:21+4Все-таки погуглил про Play и Kotlin, оказалось всё банально (kotlin#1, kotlin#2, reddit):
— Play гвоздями прибит к sbt, и не поддерживает gradle и maven (wat? и это при заявленной совместимости с Java?)
— нет официального? плагина для sbt с поддержкой компилятора Kotlin.
Прежде всего хочу заметить, что это скорее проблема Play, чем Kotlin. sbt (Scala build tool) это узкоспециализированная утилита для проектов на Scala, и отсутствие официального Kotlin плагина для нее ожидаемо. А вот жёсткое требование sbt для Play как минимум странно.
Но и эти проблемы похоже уже частично решены:
— неофициальный плагин Kotlin для sbt: kotlin-plugin
— поддержка Play в gradle все-таки появилась относительно недавно: блог LinkedIn, gradle Play plugin
Таким образом, никакой принципиальной несовместимости между Play и Kotlin нет. Вопрос только в одновременной поддержке Play и компилятора Kotlin одной из утилит сборки — gradle или sbt.
С другой стороны, я не уверен в целесообразности связки Play и Kotlin, раз там уже подразумевается Scala и основной разработчик Lightbend.
Повторюсь, что и без Play достаточно Java фреймворков для микросервисов, с которыми Kotlin работает без проблем: Spring Boot, Dropwizard, Netty, vert.x, SparkJava, Ratpack etc. Для примера можно посмотреть список здесь.
vasIvas
19.05.2017 20:51+1Только сегодня узнал что мною обожаемая JetBrains компания русских разработчиков и испытал чувство, которое, как мне кажется, сравнимо с чувством возникающем при упоминании первых в космосе. Ваще круто :) И я просто уже мечтаю когда Вы сделаете компиляцию под все web + android + ios чтобы наконец начать получать удовольствие от разработки.
solver
21.05.2017 15:22-3Фейспалм…
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…nile1
21.05.2017 15:53+6Команда разработчиков Kotlin (да и вообще большая часть разработчиков JetBrains) находится в Санкт-Петербурге, а язык назван в честь острова Котлин, на котором находится город Кронштадт, в 30 км от Санкт-Петербурга?.
Такие дела.solver
21.05.2017 16:36-5Как круто… т.е. по вашей логике, если бы например, программу аполлон сделала команда из России, на деньги американцев, для американской компании, будучи просто наемными работниками… и назвала бы его именем острова где-то рядом с Россией, то это была бы победа России, аналогичная запуску первого космонавта?
Вы серьезно?nile1
21.05.2017 17:23+4то это была бы победа России
Какая победа, что за бред вы несёте? Что это за специальная олимпиада, в которой вы болеете и за какую сборную?
Я всего лишь изложил факты. JetBrains основана выходцами из России, и основной офис разработки находится в Санкт-Петербурге. Насколько помню, второй по размеру офис разработки находится в Мюнхене, но и там работают преимущественно выходцы из России. То, что компания зарегистрирована в Чехии, не меняет этого факта.
При этом ни вам, ни мне тут нечем гордиться или стыдиться, никакой нашей заслуги в их успешности нет.
Но Андрею Бреславу, всей команде разработчиков Kotlin и компании JetBrains большой респект.
JetBrains признанная компания во всем мире, и национальная принадлежность ее основателей и разработчиков тут абсолютно не важна.solver
21.05.2017 17:25-4Читать то умеете?
Почитайте к чему я напиисал свой камент… а потом уже создавайте специальную олимпиаду и занимайте в ней призовое место…
yole
21.05.2017 18:58+1Все, что делает компания JetBrains (за исключением минимального стартового капитала, на который трое основателей жили первый год), она делает на самостоятельно заработанные деньги. Владельцы компании, практически весь ее менеджмент, вся команда Kotlin — все русские. Так что непонятно, кто тут кому «просто наемный работник».
solver
22.05.2017 13:11-3Да ладно, что там непонятного?
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
tangro
22.05.2017 11:31-3Нет. JetBrains не планирует продаваться никакой другой компании.
Хм… а что бы я на месте JetBrains говорил бы, если бы хотел продаться гуглу как можно дороже… Может быть, что не планирую продаваться?
vadimzz
23.05.2017 12:20Гугл слишком часто закрывал/перепродавал купленные компании. Писать сегодня «хочу продаться Гуглу», как минимум, опасно для имиджа :-)
maratische
23.05.2017 10:46эхх, была надежда, что гуголь видя в Котлине конкурента, допишет наконецто джаву с 1.6 до 1.8 в андроид…
samally
23.05.2017 13:32Так дописал же. На последних версиях android gradle plugin можно использовать sourceTarget 1.8 без всяких jack'ов, напрямую. Недостающих классов это не добавит, но возможности языка доступны.
gildor
23.05.2017 13:46+1Каким боком Kotlin конкурент Google?
Начиная с API level 26 в Android и так 1.8, не говоря уже о том, что недавно зарелизели поддержку некоторых фишек Java 8
yunushkin
23.05.2017 14:06Скажите а можно написать программу для ARM микроконтроллеров например STM32F7, смогу ли я это сделать на Kotlin. Т.е. получается у меня два пути первый это использовать Kotlin поверх Java или например через native как то попробовать скомпилировать. Добавить GUI под микроконтроллер? Теоретически это возможно? Вообще нужно ли это даже как интересный опыт? И как например в десктопном приложении на Kotlin сделать GUI, тоже использовать Java? Возможно ли используя Kotlin совершать обмен по ComPort (Serial, последовательный порт) на Windows. Например в C# есть класс SerialPort. Есть ли что-то такое встроенное в язык или тоже нужно например использовать библиотеки Java?
olonho
23.05.2017 16:47Да, это вскоре будет возможно с использованием Kotlin/Native. Поддержка встроенных целей типа контроллеров STM32 запланирована в предстоящих релизах, или её не очень сложно добавить самостоятельно. Весь исходный код открыт.
asmart
Спасибо Ребята и удачи Вам в будущем!
Очень хочется что бы у Вас с Kotlin всё получилось как нельзя лучше.