Comments 101
Спасибо Ребята и удачи Вам в будущем!
Очень хочется что бы у Вас с Kotlin всё получилось как нельзя лучше.
Очень хочется что бы у Вас с Kotlin всё получилось как нельзя лучше.
Под .net не будет Котлина?
Ну вот теперь, пожалуй, можно писать под Android.
Гикам, энтузиастам и просто скучающим программерам вопрос может показаться странным, но… зачем? Зачем новый стрёмный язык, когда есть обкатанная Java c миллионом библиотек и готовых решений под неё? Вряд ли у Java есть такие фатальные недостатки, которые лечит новый язык (учитывая, что Java тоже не стоит на месте).
может ответ содержится в вашем вопросе?
kotlin запускается на jvm и может использовать «c миллионом библиотек и готовых решений под неё», но добавляет немного синтаксического сахара. Можете из kotlin дергать java код или из java дергать kotlin код, все в ваших руках.
Возможность решать какую-то задачу и решать удобно эту же задачу это совершенно разные уровни решения =)
kotlin запускается на jvm и может использовать «c миллионом библиотек и готовых решений под неё», но добавляет немного синтаксического сахара. Можете из kotlin дергать java код или из java дергать kotlin код, все в ваших руках.
Возможность решать какую-то задачу и решать удобно эту же задачу это совершенно разные уровни решения =)
В мире бэкенда Java может и развивается, но в мире Android застряла на java 6 (с добавлением сахара из 7 и 8)
Вы можете найти ответ на ваш вопрос во втором абзаце записи, под которой вы оставили этот комментарий.
Ну это интересный вопрос. Я, как один из разработчиков языка, должен бы по идее защищать язык. Однако, скажу честно: я не знаю. Я так понимаю, просто есть разные люди с разным мировосприятием, кто-то хочет стабильности и надёжности (и поддерживаемости кода конченными индусами), кто-то хочет чего-то с приятными синтаксисом. Так что пусть на вопрос "зачем" отвечают разработчики для самих себя. Как мы видим, достаточно большая часть разработчиков нашла ответ на этот вопрос, и Google даже пришлось пойти им навстречу.
Для себя я придумал такое объяснение, зачем мы делаем Kotlin — чтобы дать людям выбор. Ну и ещё одно — чтобы у людей была возможность писать fullstack-приложения. В мире JS есть node.js, почему в мире Java нет fullstack-решения? Есть GWT, но он в последнее время тихо загибается, плюс это сторонний инструмент от стороннего разработчика, а не официальная технология от разработчиков Java. Мы же в Kotlin координируем усилия между командами, разрабатывающими JVM, JS и Native бэкэнды. А некоторые внутренние продукты JetBrains уже пишутся на fullstack Kotlin.
когда есть обкатанная Java c миллионом библиотек и готовых решений под неё
Ваша ошибка в том, что эти библиотеки "для Java". Это не так, Kotlin прекрасно работает с библиотеками, созданными специально "для Java"
Резонно, спасибо за ответ. Не уловил, что Kotlin настолько хорошо совместим с Java, теперь буду знать.
Из статьи: «а это значит, что для Kotlin будет разрабатываться больше библиотек». Да, в идеальном мире все библиотеки будут работать и в джаве, и в котлине, и в скале, и везде. Но в реальном мире это приведёт к какой-никакой но фрагментации. Появятся библиотеки, которые будут заточены специально под котлин, использовать какие-то фичи котлиновские. И значит что если ты пишешь на джаве в какой-то момент тебе возможно придётся перейти на котлин, чтобы использовать какие-нибудь такие библиотеки. И это распыляет усилия сообщества. Вместо того, чтобы иметь 1 классную библиотеку, будет пару «ну ничего» библиотек.
Так же теперь надо будет всю документацию с примерами дублировать на нескольких языках и подобные вещи по поддержке.
Да, выбор — это хорошо, но все же у него тоже есть своя цена. Эту цену сложно «пощупать», но она есть.
Так же теперь надо будет всю документацию с примерами дублировать на нескольких языках и подобные вещи по поддержке.
Да, выбор — это хорошо, но все же у него тоже есть своя цена. Эту цену сложно «пощупать», но она есть.
В целом вы правы, конечно. В случае котлина эта цена меньше, чем во многих других случаях — например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы, и то, что библиотека использует котлиновские фичи, не приведет к тому, что ее пользователям надо будет непременно переходить на котлин. Но да, про документацию и примеры всё так.
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)
Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)
например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы
Ну даже "из коробки" тот API, который Kotlin отдаёт Java, выглядит достаточно удобным и естественным, за исключением классов, оканчивающихся на Kt, и необходимости явного обращения к companion object. Обе претензии больше эстетические, чем концептуальные, да и возникают подобные ситуации не очень часто.
Кстати оба этих момента можно решить силами котлина:
оканчивающихся на Kt
Можно анотировать файл @file:JvmName и указать желаемое имя
необходимости явного обращения к companion object.
Анотировать члены companion object с помощью @JvmStatic
Затем, что Гугл судится с Oracle по поводу Java API.
Когда появился swift от Apple решил что подожду что из этого выйдет, в итоге главный разработчик уволился из apple будущее языка туманно, apple сама не пишет свои продукты на нем, в итоге сижу на obj-c и радуюсь. Так же с android, буду сидеть на java. А там посмотрим… перейти никогда не поздно)
А что там с Kotlin/Native под Windows? На крайнем JPoint-е Андрей, вскользь, сказал, что есть пока проблемы, но конкретики не дал.
Все хорошо :) На днях коллега на стэндапе рассказывал, что тетрис завелся.
Это хорошо.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
Котлин это всетаки язык, или обвертка (как на картинке) для джавы?
http://cs5.pikabu.ru/post_img/2014/07/03/1/1404337531_1801068260.jpg
http://cs5.pikabu.ru/post_img/2014/07/03/1/1404337531_1801068260.jpg
Язык. Со своим компилятором под три разных платформы, своей системой типов и много чем ещё.
Виртуальные машины тоже свои?
Пожалуйста, прочитайте пост, который вы комментируете. Там вполне явно написано, под какие платформы компилируется котлин.
Я прочитал, если бы не прочитал вообще бы не писал сюда. «Kotlin/JVM» и что дальше? Это виртуальная машина котлина или джавы?
Причем здесь вообще компиляция? Я про исполнение кода, а не про компиляцию кода. Пожалуйста, прочитайте комментарий, который вы комментируете.
PS: И не надо агриться. Я вас серьезно спрашиваю.
Причем здесь вообще компиляция? Я про исполнение кода, а не про компиляцию кода. Пожалуйста, прочитайте комментарий, который вы комментируете.
PS: И не надо агриться. Я вас серьезно спрашиваю.
Буковки «JVM» в названии «Kotlin/JVM» как бы намекают, что целевой платформой для компиляции и исполнения является JVM, то есть Java Virtual Machine, то есть виртуальная машина Java.
А буковки «Kotlin» на что намекают? Чтобы не было непонимания так бы и писали «JVM». Если котлин использует обычный стандартный JVM, значит он только обвертка для обычной стандартной Джавы. А вы тут лапшу развешиваете.
Уже всей своей шарагой минусов наставили или еще нет? Позовите еще хипстеров или для кого там ваша обвертка сделана, пускай они поминусуют.
Уже всей своей шарагой минусов наставили или еще нет? Позовите еще хипстеров или для кого там ваша обвертка сделана, пускай они поминусуют.
Я не знаю, что вы имеете в виду под словом «обвертка». Kotlin может транслироваться в байткод JVM (который может выполняться также на совместимых с ней виртуальных машинах, таких как Android), а также в исходный код на JavaScript и в нативный код, выполняемый вообще без виртуальной машины. У Kotin своя система типов и свои языковые фичи, несколько более сложные, чем "#define блять ;".
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.
Kotlin запускается на JVM, значит, это обертка для джавы. Видимо, Groovy и Scala вы тоже не уважаете. F# запускается на дотнетовской CLR, значит, это обертка для C#? C++ запускается вообще без виртуальной машины, значит, это обертка… эмм, для ассемблера? Забавная у вас логика.
шикарная картинка, Думаю с этого надо начинать обучение C++, это круто, как скины, только для языка программирования :) Я раньше обходил C++ стороной а теперь заинтересовался.
Спасибо вам за работу, язык после джавы как спасение. Одни только property чего стоят. Желаю и дальше расти и подстегивать Java вводить удобство в язык
И почему же не Go...
Вторая ссылка в тексте битая, нужно убрать лишние символы
Не холивара ради, искренний вопрос — зачем? Не лучше ли было поддержать и развивать Scala, ведь там уже есть все то на что вы тратите время разаботчиков (взаимодействие с Java, поддежка компиляции в Javascript и ScalaNative). Уже сформированное сообщество и экосистема.
Пытаюсь найти для себя ответ — не нахожу пока. Хотелось бы увидеть честное сравнение с примерами реального кода, временем сборки, удобством отладки, тестирования и т.п.
С уважением отношусь к JetBrains и пользуюсь вашими продуктами.
Пытаюсь найти для себя ответ — не нахожу пока. Хотелось бы увидеть честное сравнение с примерами реального кода, временем сборки, удобством отладки, тестирования и т.п.
С уважением отношусь к JetBrains и пользуюсь вашими продуктами.
Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.
Интервью с Максимом Шафировым
В Scala, помимо всего того, о чем вы говорите, есть также дизайн языка. Вкладывая силы в поддержку и развитие Scala, мы могли бы решить проблемы со временем сборки, удобством отладки, тестирования и т.д., но принципиально изменить дизайн языка мы не смогли бы. А мы считаем, что в этом мире должен существовать не только язык с таким дизайном, как у Scala, но и язык с таким дизайном, как у нас.
Спасибо за комментарий! А не могли бы ткнуть ссылкой или пояснить, что в первую очередь не так с дизайном языка? Я рассуждаю с точки зрения пользователя — интересно узнать мнение разработчика языка...
Ну почему «не так»? Он просто ориентирован на другую целевую аудиторию, другой способ мышления.
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.
Очевидно, что у Скалы есть фатальный недостаток: ее писали не в JetBrains.
http://www.programming-idioms.org/idiom/12/check-if-list-contains-a-value
Вот пример того какими средствами достигается решение типовой задачи поиска в списке в разных языках, котлина там нет но я посмотрел, в нем как в Питоне.
Сразу оговорюсь я на языки смотрю прагматично, на чем надо на том и работаю. Но, есть некоторые, вполне объективные критерии.
Скала не сильно удобочитаемый язык. И Ява хоть и привычный, распространенный но тоже не удобочитаемый язык.
Язык может быть мощным но он должен быть и удобочитаемым. Ведь, как известно, мы больше читаем чем пишем код. Следовательно, чем легче его воспринимать, тем лучше.
Все эти академические каверзы не нужны простым смертным, недопрограммистам, типа меня (прим авт. — для меня программист это тот кто может и свой компилятор зафигачить и микроконтроллер для умного дома запрограммировать). Им нужна простота в освоении и использовании.
Быстро добиться результата. Переводить мысли в код как можно более непосредственно. Не лазить в гугл как перевести мою мысль на язык программирования ХYZ.
Это прекрасно, кодгда «как думается так и пишется» (по аналогии с немецким языком, где «как пишется так и читается») И большие корпорации давно поняли что уже не девяностые, ай-ти это не секта куда принимают только избранных, идет борьба за человеческий ресурс. А ресурс он разный, планку надо понижать, именно понижать. И ничего в этом страшного нету. Доступность это не «опопсение» как некоторым кажется, а взросление.
Вот пример того какими средствами достигается решение типовой задачи поиска в списке в разных языках, котлина там нет но я посмотрел, в нем как в Питоне.
Сразу оговорюсь я на языки смотрю прагматично, на чем надо на том и работаю. Но, есть некоторые, вполне объективные критерии.
Скала не сильно удобочитаемый язык. И Ява хоть и привычный, распространенный но тоже не удобочитаемый язык.
Язык может быть мощным но он должен быть и удобочитаемым. Ведь, как известно, мы больше читаем чем пишем код. Следовательно, чем легче его воспринимать, тем лучше.
Все эти академические каверзы не нужны простым смертным, недопрограммистам, типа меня (прим авт. — для меня программист это тот кто может и свой компилятор зафигачить и микроконтроллер для умного дома запрограммировать). Им нужна простота в освоении и использовании.
Быстро добиться результата. Переводить мысли в код как можно более непосредственно. Не лазить в гугл как перевести мою мысль на язык программирования ХYZ.
Это прекрасно, кодгда «как думается так и пишется» (по аналогии с немецким языком, где «как пишется так и читается») И большие корпорации давно поняли что уже не девяностые, ай-ти это не секта куда принимают только избранных, идет борьба за человеческий ресурс. А ресурс он разный, планку надо понижать, именно понижать. И ничего в этом страшного нету. Доступность это не «опопсение» как некоторым кажется, а взросление.
Синтаксический сахар не всегда равнозначен понижению планки и порога вхождения.
Взять ту же Джаву. Java — в каком-то смысле уникальный язык, потому что код на ней интуитивно понятен любому программисту, даже если он вообще не знаком с особенностями языка. Ибо то, что в современных языках делается одной строчкой синтаксического сахарка, в Джаве делается убогим методом из 5 строк, но каждая из этих строк не нуждается в объяснении, если человек хоть что-то понимает в алгоритмах.
С модными функциональными языками такое не прокатит: ты можешь сколько угодно глядеть на "=>", но без прочтения мануала так и не поймешь что оно означает.
Мне приходилось по работе сталкиваться с отлично написанным и задокументированным кодом на Java и ужасным кодом на Scala. Что характерно, за поддержку ужасного кода на Scala платили больше, так как того кто его писал не иначе как били током за каждую лишнюю строчку кода. Работа на функциональных проектах зачастую сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба однострочных решений. Что, конечно, увлекательно, но понижению порога вхождения никак не способствует. А рыночку, как вы верно заметили, хочется низкого порога вхождения, а не тешить ЧСВ функциональщиков. Поэтому Джаву уже столько лет хоронят, а она всё еще в каждом первом проекте.
Взять ту же Джаву. Java — в каком-то смысле уникальный язык, потому что код на ней интуитивно понятен любому программисту, даже если он вообще не знаком с особенностями языка. Ибо то, что в современных языках делается одной строчкой синтаксического сахарка, в Джаве делается убогим методом из 5 строк, но каждая из этих строк не нуждается в объяснении, если человек хоть что-то понимает в алгоритмах.
С модными функциональными языками такое не прокатит: ты можешь сколько угодно глядеть на "=>", но без прочтения мануала так и не поймешь что оно означает.
Мне приходилось по работе сталкиваться с отлично написанным и задокументированным кодом на Java и ужасным кодом на Scala. Что характерно, за поддержку ужасного кода на Scala платили больше, так как того кто его писал не иначе как били током за каждую лишнюю строчку кода. Работа на функциональных проектах зачастую сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба однострочных решений. Что, конечно, увлекательно, но понижению порога вхождения никак не способствует. А рыночку, как вы верно заметили, хочется низкого порога вхождения, а не тешить ЧСВ функциональщиков. Поэтому Джаву уже столько лет хоронят, а она всё еще в каждом первом проекте.
> Мне приходилось по работе сталкиваться с отлично написанным и задокументированным кодом на Java
Вы абсолютно правильно расставили акценты. Именно «приходилось сталкиваться». Потому что большинство кода на Java представляет из себя жуткую мешанину классов, заоверинжениренную «по самое нимагу». И смотря на такой код, я вовсе не уверен, что эту мешанину легче понять, чем "=>", без документации. Учитывая, что эти классы обычно размазаны по проекту…
> Работа на функциональных проектах зачастую сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба однострочных решений
А работа на ООП проектах сродни разгадыванию головоломолок, которые для тебя оставили очередные представители элитного клуба ООП решений в 100500 классов с 20 уровнями наследования.
Другими словами, говнокод есть во всех языках. Просто он по разному выглядит.
Вы абсолютно правильно расставили акценты. Именно «приходилось сталкиваться». Потому что большинство кода на 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.
Вы попробуйте как-нибудь прийти в команду с проектом на 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.
— Высокий порог вхождения
— Гибкость языка приводит к тому, что одну задачу можно решить кучей способов, при этом результат зачастую выглядеть так, как будто под каждую задачу изобретается новый синтаксис языка (особенно если используются «богатые» фичи библиотек вроде 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'ом, а может и нет и система типов вам в этом ни как не поможет.
https://www.lightbend.com/blog/questions-answered-on-the-change-to-lightbend-and-lagom-for-java
Также можно поискать по слову «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» в анонсе переименования компании
Привожу цитату вашего комментария снова
теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala
Заходим на гитхаб, репозиторий lagom.
Проценты кода на Скале: ~70, на Джаве: ~30.
Большинство core пакетов на Скале. Неплохая такая обертка в 70%.
В анонсе ни чего про обертки не нашел, сказано только про API. Само ядро фреймворка написано на Скале.
фреймворки для Java, а не на Java.
Это просто признак того, что рынок Scala растет недостаточными темпами для финансовой успешности Lightbend, и приходится менять фокус. Собственно, большинство комментариев к статьям по ссылкам о переименовании в Lightbend говорят о том же.
Я не настаиваю на верности своего утверждения, в целом мой комментарий был не об этом. Я ничего не имею против успешности Scala, просто мне (и многим другим) этот язык не подходит. Хорошо, что есть выбор.
Я выбираю Kotlin, если хочется «better Java» без излишнего упора на функциональщину. Из новых языков также понравилось писать (а ещё больше — читать) код на Go, несмотря на изначальный скепсис из-за отсутствия дженериков, null safety и immutability. Kotlin и Go — оба прагматичные языки, с opinionated ограничениями заложенными авторами языка, и своей философией.
Java 8 тоже не так уж плоха, и тут я соглашусь с одной из основных (но не единственной) причин успеха Kotlin на Android.
Это просто признак того, что рынок 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 и запускается на jvm. У Котлина же нет своей JVM. Котлин мне вообще как язык не зашел. Хотя есть большой опыи на java и .net. Из всех java подобных языков мне больше всего нравится dart у которого своя виртуальная машина, и очень хороший синтаксический сахар и статический анализатор из коробки.
Котлин — это не синтаксический сахар, а полноценный язык со своей системой типов и своей семантикой. Ключевое отличие системы типов Kotlin от Java — это поддержка nullable и non-null types, то есть, возможность определять в момент компиляции, какие выражения могут приводить к NPE, и запрещать компиляцию таких выражений. Свою JVM для этого иметь не надо, достаточно иметь свой компилятор.
Спасибо за ответ.
Другими словами, ключевое отличие системы типов Kotlin от Java — это замена аннотации NotNull на синтаксический сахар в виде символа "?"… я правильно понял?
Аннотация NotNull не является частью системы типов Java, и компилятор Java никак не ограничивает использование nullable-значений в выражениях, которые могут привести к NPE.
Подскажите, какие преимущества Kotlin для начинающего Android-разработчика?
Пишу исключительно для себя и своих нужд, но поскольку с Java не слишком в ладах, постоянно смотрю в сторону других решений, особенно JS (т.к. сам веб-разработчик), но всегда есть куча ограничений и неудобств. Здесь кроме нового синтаксиса ничего для себя не обнаружил, а синтаксис для меня в Java «новый», по сути. Может что-то упустил?
Пишу исключительно для себя и своих нужд, но поскольку с Java не слишком в ладах, постоянно смотрю в сторону других решений, особенно JS (т.к. сам веб-разработчик), но всегда есть куча ограничений и неудобств. Здесь кроме нового синтаксиса ничего для себя не обнаружил, а синтаксис для меня в Java «новый», по сути. Может что-то упустил?
Освоиться с синтаксисом Java в любом случае крайне полезно, потому что основная масса документации и примеров, которые на данный момент доступны, использует именно Java. Каких-то задач, которые можно было бы решить только на Kotlin и нельзя было бы решить на Java, не существует. Так что в конечном итоге смотрите сами — если вам приятнее писать на Kotlin, то используйте его.
А какой фреймворк для web приложений рекоммендует сейчас использовать JetBrains с Kotlin?
Какой вам больше нравится. Можно Spring, можно vert.x, можно ktor (http://github.com/kotlin/ktor).
Чей-то как-то так себе. Выбор между Spring и проектами с непонятной перспективой куда комитят пару человек для серьезного проекта и не выбор вовсе. Помнится давно были разговоры о Play. Теперь, я так понимаю, эта тема заглохла окончательно. Может тогда все же пора заняться серьезно вопросом фреймворка, а не упавать на авсь мол что-то такое само взрастет? Уже сколько лет ведь…
Выбор между Spring и проектами с непонятной перспективой
Выбор тот же самый, что и для Java: Spring Boot, Dropwizard или любой другой.
В том и прелесть Kotlin, что в отличие от Scala не требуется изобретать велосипеды заново, а можно использовать стандартный стек технологий Java.
Я конвертировал проект на Dropwizard + Guice с Java в Kotlin, за пару часов исправил все проблемы компиляции, и можно продолжать развивать проект не отвлекаясь на поиск новых сырых альтернатив.
Отличная новость! Расскажите пожалуйста, как использовать Play с Kotlin?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Думаю, что Play с Kotlin использовать ровно также как Play с Java. Могут быть какие-то особенности из-за того что Play написан на Scala, но способы их решения идентичны Java.
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
Самый простой способ — это создать простой проект на Java, и автоматически конвертировать его в Kotlin средствами IntelliJ IDEA.
… и код покрывается красным. Причем, по причинам, далеко не всегда очевидным тем, кто начинает разбираеться с языком.
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Откуда менторский тон? Я вам что-то должен? Вы же сами задали вопрос. Я сказал, что без проблем завел проект на Dropwizard, а Play не пробовал, но должно быть близко к тому, как создавать проект на Play с Java (и предупредил, что возможны подводные камни, т.к. Play сделан на Scala).
Я не утверждал, что «Play нефик делать подружить с Kotlin». Я сказал, что проще всего начать с Java проекта, и попробовать перевести его на Kotlin.
Я не использую Play, если вам интересно попробуйте сами и поделитесь с сообществом.
Если у вас есть практическое доказательство, что Play с Kotlin не заводится — приведите «пример неработающего проектика», будет полезно знать.
Spring Boot и Dropwizard работают на практике, а не в теории.
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 нефик делать подружить с 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 и 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. Для примера можно посмотреть список здесь.
— 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. Для примера можно посмотреть список здесь.
Я пользуюсь http://sparkjava.com/ и никаких проблем с котлином там нет
Только сегодня узнал что мною обожаемая JetBrains компания русских разработчиков и испытал чувство, которое, как мне кажется, сравнимо с чувством возникающем при упоминании первых в космосе. Ваще круто :) И я просто уже мечтаю когда Вы сделаете компиляцию под все web + android + ios чтобы наконец начать получать удовольствие от разработки.
Фейспалм…
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…
Команда разработчиков Kotlin (да и вообще большая часть разработчиков JetBrains) находится в Санкт-Петербурге, а язык назван в честь острова Котлин, на котором находится город Кронштадт, в 30 км от Санкт-Петербурга.
Такие дела.
Такие дела.
Как круто… т.е. по вашей логике, если бы например, программу аполлон сделала команда из России, на деньги американцев, для американской компании, будучи просто наемными работниками… и назвала бы его именем острова где-то рядом с Россией, то это была бы победа России, аналогичная запуску первого космонавта?
Вы серьезно?
Вы серьезно?
то это была бы победа России
Какая победа, что за бред вы несёте? Что это за специальная олимпиада, в которой вы болеете и за какую сборную?
Я всего лишь изложил факты. JetBrains основана выходцами из России, и основной офис разработки находится в Санкт-Петербурге. Насколько помню, второй по размеру офис разработки находится в Мюнхене, но и там работают преимущественно выходцы из России. То, что компания зарегистрирована в Чехии, не меняет этого факта.
При этом ни вам, ни мне тут нечем гордиться или стыдиться, никакой нашей заслуги в их успешности нет.
Но Андрею Бреславу, всей команде разработчиков Kotlin и компании JetBrains большой респект.
JetBrains признанная компания во всем мире, и национальная принадлежность ее основателей и разработчиков тут абсолютно не важна.
Все, что делает компания JetBrains (за исключением минимального стартового капитала, на который трое основателей жили первый год), она делает на самостоятельно заработанные деньги. Владельцы компании, практически весь ее менеджмент, вся команда Kotlin — все русские. Так что непонятно, кто тут кому «просто наемный работник».
Да ладно, что там непонятного?
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
Нет. JetBrains не планирует продаваться никакой другой компании.
Хм… а что бы я на месте JetBrains говорил бы, если бы хотел продаться гуглу как можно дороже… Может быть, что не планирую продаваться?
эхх, была надежда, что гуголь видя в Котлине конкурента, допишет наконецто джаву с 1.6 до 1.8 в андроид…
Так дописал же. На последних версиях android gradle plugin можно использовать sourceTarget 1.8 без всяких jack'ов, напрямую. Недостающих классов это не добавит, но возможности языка доступны.
Каким боком Kotlin конкурент Google?
Начиная с API level 26 в Android и так 1.8, не говоря уже о том, что недавно зарелизели поддержку некоторых фишек Java 8
Скажите а можно написать программу для ARM микроконтроллеров например STM32F7, смогу ли я это сделать на Kotlin. Т.е. получается у меня два пути первый это использовать Kotlin поверх Java или например через native как то попробовать скомпилировать. Добавить GUI под микроконтроллер? Теоретически это возможно? Вообще нужно ли это даже как интересный опыт? И как например в десктопном приложении на Kotlin сделать GUI, тоже использовать Java? Возможно ли используя Kotlin совершать обмен по ComPort (Serial, последовательный порт) на Windows. Например в C# есть класс SerialPort. Есть ли что-то такое встроенное в язык или тоже нужно например использовать библиотеки Java?
Sign up to leave a comment.
Kotlin для Android: Теперь официально