Комментарии 101
Очень хочется что бы у Вас с Kotlin всё получилось как нельзя лучше.
Ну вот теперь, пожалуй, можно писать под Android.
kotlin запускается на jvm и может использовать «c миллионом библиотек и готовых решений под неё», но добавляет немного синтаксического сахара. Можете из kotlin дергать java код или из java дергать kotlin код, все в ваших руках.
Возможность решать какую-то задачу и решать удобно эту же задачу это совершенно разные уровни решения =)
Ну это интересный вопрос. Я, как один из разработчиков языка, должен бы по идее защищать язык. Однако, скажу честно: я не знаю. Я так понимаю, просто есть разные люди с разным мировосприятием, кто-то хочет стабильности и надёжности (и поддерживаемости кода конченными индусами), кто-то хочет чего-то с приятными синтаксисом. Так что пусть на вопрос "зачем" отвечают разработчики для самих себя. Как мы видим, достаточно большая часть разработчиков нашла ответ на этот вопрос, и Google даже пришлось пойти им навстречу.
Для себя я придумал такое объяснение, зачем мы делаем Kotlin — чтобы дать людям выбор. Ну и ещё одно — чтобы у людей была возможность писать fullstack-приложения. В мире JS есть node.js, почему в мире Java нет fullstack-решения? Есть GWT, но он в последнее время тихо загибается, плюс это сторонний инструмент от стороннего разработчика, а не официальная технология от разработчиков Java. Мы же в Kotlin координируем усилия между командами, разрабатывающими JVM, JS и Native бэкэнды. А некоторые внутренние продукты JetBrains уже пишутся на fullstack Kotlin.
когда есть обкатанная Java c миллионом библиотек и готовых решений под неё
Ваша ошибка в том, что эти библиотеки "для Java". Это не так, Kotlin прекрасно работает с библиотеками, созданными специально "для Java"
Так же теперь надо будет всю документацию с примерами дублировать на нескольких языках и подобные вещи по поддержке.
Да, выбор — это хорошо, но все же у него тоже есть своя цена. Эту цену сложно «пощупать», но она есть.
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)
например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы
Ну даже "из коробки" тот API, который Kotlin отдаёт Java, выглядит достаточно удобным и естественным, за исключением классов, оканчивающихся на Kt, и необходимости явного обращения к companion object. Обе претензии больше эстетические, чем концептуальные, да и возникают подобные ситуации не очень часто.
Кстати оба этих момента можно решить силами котлина:
оканчивающихся на Kt
Можно анотировать файл @file:JvmName
и указать желаемое имя
необходимости явного обращения к companion object.
Анотировать члены companion object с помощью @JvmStatic
Я в курсе. Речь была о том, что даже если автор не позаботился о расстановке этих аннотаций для удобства использования из Java, то полученный негативный эффект будет не более, чем косметическим.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
http://cs5.pikabu.ru/post_img/2014/07/03/1/1404337531_1801068260.jpg
Причем здесь вообще компиляция? Я про исполнение кода, а не про компиляцию кода. Пожалуйста, прочитайте комментарий, который вы комментируете.
PS: И не надо агриться. Я вас серьезно спрашиваю.
Уже всей своей шарагой минусов наставили или еще нет? Позовите еще хипстеров или для кого там ваша обвертка сделана, пускай они поминусуют.
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Kotlin запускается на JVM, значит, это обертка для джавы. Видимо, Groovy и Scala вы тоже не уважаете. F# запускается на дотнетовской CLR, значит, это обертка для C#? C++ запускается вообще без виртуальной машины, значит, это обертка… эмм, для ассемблера? Забавная у вас логика.
Спасибо вам за работу, язык после джавы как спасение. Одни только property чего стоят. Желаю и дальше расти и подстегивать Java вводить удобство в язык
И почему же не Go...
Пытаюсь найти для себя ответ — не нахожу пока. Хотелось бы увидеть честное сравнение с примерами реального кода, временем сборки, удобством отладки, тестирования и т.п.
С уважением отношусь к JetBrains и пользуюсь вашими продуктами.
Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.
Интервью с Максимом Шафировым
Спасибо за комментарий! А не могли бы ткнуть ссылкой или пояснить, что в первую очередь не так с дизайном языка? Я рассуждаю с точки зрения пользователя — интересно узнать мнение разработчика языка...
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
Вот пример того какими средствами достигается решение типовой задачи поиска в списке в разных языках, котлина там нет но я посмотрел, в нем как в Питоне.
Сразу оговорюсь я на языки смотрю прагматично, на чем надо на том и работаю. Но, есть некоторые, вполне объективные критерии.
Скала не сильно удобочитаемый язык. И Ява хоть и привычный, распространенный но тоже не удобочитаемый язык.
Язык может быть мощным но он должен быть и удобочитаемым. Ведь, как известно, мы больше читаем чем пишем код. Следовательно, чем легче его воспринимать, тем лучше.
Все эти академические каверзы не нужны простым смертным, недопрограммистам, типа меня (прим авт. — для меня программист это тот кто может и свой компилятор зафигачить и микроконтроллер для умного дома запрограммировать). Им нужна простота в освоении и использовании.
Быстро добиться результата. Переводить мысли в код как можно более непосредственно. Не лазить в гугл как перевести мою мысль на язык программирования ХYZ.
Это прекрасно, кодгда «как думается так и пишется» (по аналогии с немецким языком, где «как пишется так и читается») И большие корпорации давно поняли что уже не девяностые, ай-ти это не секта куда принимают только избранных, идет борьба за человеческий ресурс. А ресурс он разный, планку надо понижать, именно понижать. И ничего в этом страшного нету. Доступность это не «опопсение» как некоторым кажется, а взросление.
Взять ту же Джаву. Java — в каком-то смысле уникальный язык, потому что код на ней интуитивно понятен любому программисту, даже если он вообще не знаком с особенностями языка. Ибо то, что в современных языках делается одной строчкой синтаксического сахарка, в Джаве делается убогим методом из 5 строк, но каждая из этих строк не нуждается в объяснении, если человек хоть что-то понимает в алгоритмах.
С модными функциональными языками такое не прокатит: ты можешь сколько угодно глядеть на "=>", но без прочтения мануала так и не поймешь что оно означает.
Мне приходилось по работе сталкиваться с отлично написанным и задокументированным кодом на Java и ужасным кодом на Scala. Что характерно, за поддержку ужасного кода на Scala платили больше, так как того кто его писал не иначе как били током за каждую лишнюю строчку кода. Работа на функциональных проектах зачастую сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба однострочных решений. Что, конечно, увлекательно, но понижению порога вхождения никак не способствует. А рыночку, как вы верно заметили, хочется низкого порога вхождения, а не тешить ЧСВ функциональщиков. Поэтому Джаву уже столько лет хоронят, а она всё еще в каждом первом проекте.
Вы абсолютно правильно расставили акценты. Именно «приходилось сталкиваться». Потому что большинство кода на Java представляет из себя жуткую мешанину классов, заоверинжениренную «по самое нимагу». И смотря на такой код, я вовсе не уверен, что эту мешанину легче понять, чем "=>", без документации. Учитывая, что эти классы обычно размазаны по проекту…
> Работа на функциональных проектах зачастую сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба однострочных решений
А работа на ООП проектах сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба ООП решений в 100500 классов с 20 уровнями наследования.
Другими словами, говнокод есть во всех языках. Просто он по разному выглядит.
Вот хорошая статья (можно начало по диагонали прочитать): https://habrahabr.ru/post/260149/
Про скала верно написано:
Цели создателей языков тоже на удивление разнообразны. Вот c какой целью Odersky создавал Scala? Может быть это были сугубо академические (исследовательские) цели, и ему, как исследователю, было интересно сделать что-то новое вокруг идеи связки функционального и объектно-ориентированного программирования… Понятно, что хороший язык, тем более писаный гениальными чуваками, типа Odersky, можно использовать по-разному, и он будет хорош. Но все же, максимальный эффект язык даст в том случае, когда он используется в соответствии с теми целями, ради которых язык создавался.
Для меня также основная задача языка (как и фреймворка) — упростить и ускорить разработку и поддержку
Мне кажется что лучший ответ на этот вопрос дала компания Google в своем официальном блоге (см. секцию Why Kotlin): https://android-developers.googleblog.com/2017/05/android-announces-support-for-kotlin.html
Там раскрыты все основые причины. Попробуйте примерить туда 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.
Был бы рад если бы кто-нибудь также навскидку перечислил преимущества Kotlin:
- низкий порог вхождения
- один способ решения всех проблем (понятный всем и каждому)
- отличная поддержка IDE (честно удивился бы обратному)
- отличная совместимость с Java (Kotlin код вызывать из Java одно удовольствие, расскажите есть ли проблемы?)
- обратная совместимость между версиями языка/компилятора на уровне байткода/исходников
- быстрый компилятор
- миниатюрный рантайм
- и многие другие...
И желательно аргументированно с примерами.
Хочется увидеть такой списочек и вдохновившись пойти изучать Kotlin. Но на практике большая часть примеров (киллер фич) переписывается на Scala короче и понятнее (не намного впрочем). Сложности с освоением Scala до уровня среднего разработчика приложений во многом надуманы как мне кажется.
Я согласен с аргументом из первого ответа — JetBrains интересно быть разработчиком собственного языка. Получается ли им убедить в том что их язык нужен сообществу — по-чесноку — не похоже. Лично мне кажется, если у JetBrains хватит денег/терпения развивать язык достаточно долго — он может быть и выстрелит, если нет — переименуются в крайнем случае :)
Вы попробуйте как-нибудь прийти в команду с проектом на 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 — тут у меня выборки нет.
Люди почти без опыта программирования (с базовыми теоретическими знаниями 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, и учел многие недостатки (но и значительно ограничил возможности). Каждому свое.
Либо речь об очень ограниченном использовании 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, что характеризует только крайне локальные изменения вокруг меня, а не картину в целом, как и любые другие субъективные критерии.
теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala.
Приведите пример хотя бы одного такого фреймворка. Со всеми фреймворками lightbend'a, которые я знаю, ситуация абсолютно обратная.
Проблемы обратной совместимости между версиями самой Scala: нужно иметь версии всех библиотек, скомпилированные одной версией компилятора Scala.
Только бинарная обратная совместимость. Сам язык не менялся особо. Впрочем посмотрим какая совместимость будет у Котлина после 13 лет, сейчас ему пока что нечего ломать, он только релизнулся.
Из Scala вызывать Java код ещё терпимо, но в обратную сторону практически невозможно.
Настолько невозможно, что для большинства больших скаловских фреймворках есть поддержка джавы.
Зато у Котлина "нет" никаких проблем даже с использованием Java кода. Ну а про обратный вызов я вообще молчу, все эти костыли с @JvmStatic
, KtClass
extenstion methods и т.д. точно не говорят про 100% обратный интероп. Особенно мне интересно как можно использовать Котлиновский suspend
метод из java кода. В последний раз когда я попытался использовать такой метод, IDE мне нагенерела такой треш, в котором было очень сложно разобраться.
Единственная причина, в моем понимании, почему Котлин начал набирать какой то успех в Android среде, это потому что у них до сих пор 6 Java. Те, кто может использовать 8ку, сидят на Java и не торопятся менять язык просто из-за "клевого" синтаксиса и null-safety которого нет, т.к. если вы собрались использовать Java библиотеки то для Котлина такие типы будут обозначены как Type! т.е. тип который может null'ом, а может и нет и система типов вам в этом ни как не поможет.
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» в анонсе переименования компании
Привожу цитату вашего комментария снова
теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala
Заходим на гитхаб, репозиторий lagom.
Проценты кода на Скале: ~70, на Джаве: ~30.
Большинство core
пакетов на Скале. Неплохая такая обертка в 70%.
В анонсе ни чего про обертки не нашел, сказано только про API. Само ядро фреймворка написано на Скале.
Это просто признак того, что рынок Scala растет недостаточными темпами для финансовой успешности Lightbend, и приходится менять фокус. Собственно, большинство комментариев к статьям по ссылкам о переименовании в Lightbend говорят о том же.
Я не настаиваю на верности своего утверждения, в целом мой комментарий был не об этом. Я ничего не имею против успешности Scala, просто мне (и многим другим) этот язык не подходит. Хорошо, что есть выбор.
Я выбираю Kotlin, если хочется «better Java» без излишнего упора на функциональщину. Из новых языков также понравилось писать (а ещё больше — читать) код на Go, несмотря на изначальный скепсис из-за отсутствия дженериков, null safety и immutability. Kotlin и Go — оба прагматичные языки, с opinionated ограничениями заложенными авторами языка, и своей философией.
Java 8 тоже не так уж плоха, и тут я соглашусь с одной из основных (но не единственной) причин успеха Kotlin на Android.
Я так же ни чего не имею против Котлина и других языков, особенно Go, у которого свой рантайм, свой стек, свое коммьюнити и т.д.
Просто какая сейчас ситуация. Есть язык Java, со своим большим количеством библиотек. Сам по себе язык не особо фичастый, поэтому эти библиотеки можно использовать из любого JVM языка без особых сложностей (кроме чистых, таких как Frege). Потом появляется язык X1
из которого другим JVM языкам код вызвать или нельзя или вызывается со сложностями. Но это не особо проблематично, когда такой язык позиционировался ни как better Java
, а как другой язык, со своей парадигмой. Тогда комьюнити создает для самих себя такие обертки/библиотеки, более идиоматичные и использует их внутри своего языка.
По моему мнению, Скала занимает здесь промежуточный вариант, можно использовать чисто Java библиотеки и получать ~75-100% ООП или же использовать Скаловские, которые могут использовать сложные библ по типу shapeless, но зато являются более типобезопасными. Что из этого лучше, более простой код, но падающий в рантайме или более сложный но не проходящий компиляцию, вопрос отдельный и наверное сильно зависит от контекста применения.
Но вот проблема начинаются когда язык позиционируется со 100% интеропом, что в одну сторону, что в другую, но такого не имеет. Это может привести к расколу в экосистеме JVM. Будут появляется библ на Котлине, которые будут использовать фичи Котлина и они конечно будут недоступны на других язык, в том числе Java. Было бы правильно хотя бы на сайте Котлина перечислить что работает хуже или в вообще не работает в Java. Уже сейчас я начинаю замечать в Котлиновских библ очень частое использование extension methods, там где они даже не нужны или сильно запутывают код.
Не лучше ли было поддержать и развивать Scala
Не совсем понятно, кому именно задан этот вопрос? Если гуглу, то с тем же успехом можно спросить, почему они не хотят поддерживать и развивать Java на Android. Примерно год назад ходили слухи, что они-таки перейдут на OpenJDK в Android 7, но этого, как я понимаю, не случилось. По идее, переход на актуальную версию Java позволил бы прикладным разработчикам самим выбирать, на каком JVM-языке писать (включая собственно язык Java, ставший гораздо более приятным по сравнению с шестеркой). Но похоже вместо этого разработчикам просто кинули кость в виде «официальной поддержки» одного только Котлина.
Со Скалой так сделать было нельзя, поскольку начиная с 2.12 она компилируется только под восьмерку — и это был осознанный выбор Scala-комьюнити, сделанный около 4-х лет назад. И я в свое время тоже голосовал за переход на восьмерку, потому что на Android джава-мир не заканчивается, и даже не начинается :)
Пишу исключительно для себя и своих нужд, но поскольку с Java не слишком в ладах, постоянно смотрю в сторону других решений, особенно JS (т.к. сам веб-разработчик), но всегда есть куча ограничений и неудобств. Здесь кроме нового синтаксиса ничего для себя не обнаружил, а синтаксис для меня в Java «новый», по сути. Может что-то упустил?
Выбор между Spring и проектами с непонятной перспективой
Выбор тот же самый, что и для Java: Spring Boot, Dropwizard или любой другой.
В том и прелесть Kotlin, что в отличие от Scala не требуется изобретать велосипеды заново, а можно использовать стандартный стек технологий Java.
Я конвертировал проект на Dropwizard + Guice с Java в Kotlin, за пару часов исправил все проблемы компиляции, и можно продолжать развивать проект не отвлекаясь на поиск новых сырых альтернатив.
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
мне весело читать теоретические рассуждения на тему того, что 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.
— 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. Для примера можно посмотреть список здесь.
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…
Такие дела.
Вы серьезно?
то это была бы победа России
Какая победа, что за бред вы несёте? Что это за специальная олимпиада, в которой вы болеете и за какую сборную?
Я всего лишь изложил факты. JetBrains основана выходцами из России, и основной офис разработки находится в Санкт-Петербурге. Насколько помню, второй по размеру офис разработки находится в Мюнхене, но и там работают преимущественно выходцы из России. То, что компания зарегистрирована в Чехии, не меняет этого факта.
При этом ни вам, ни мне тут нечем гордиться или стыдиться, никакой нашей заслуги в их успешности нет.
Но Андрею Бреславу, всей команде разработчиков Kotlin и компании JetBrains большой респект.
JetBrains признанная компания во всем мире, и национальная принадлежность ее основателей и разработчиков тут абсолютно не важна.
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
Нет. JetBrains не планирует продаваться никакой другой компании.
Хм… а что бы я на месте JetBrains говорил бы, если бы хотел продаться гуглу как можно дороже… Может быть, что не планирую продаваться?
Каким боком Kotlin конкурент Google?
Начиная с API level 26 в Android и так 1.8, не говоря уже о том, что недавно зарелизели поддержку некоторых фишек Java 8
Kotlin для Android: Теперь официально