Comments 176
Спасибо за открытие темы.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
Скорее всего, вы столкнулись с проблемой, специфичной для вашего проекта — у нас довольно много больших проектов, содержащих .kt файлы, и мы такого поведения не наблюдаем. Чтобы понять, что в точности у вас происходит, вы можете прислать нам CPU snapshot: https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems
Молодцы! Успехов Вам!
1) Как в плане быстродействия по сравнению с Java и с каким-то нативным языком? Например Go
2) Планируется ли нативная компиляция в будущем для работы без VM?
2) Планируется ли нативная компиляция в будущем для работы без VM?
1) Новедь! Это такой же компилируемый в jvm-байткод язык, как и Java...
1) Если писать код, эквивалентный аналогичному коду на Java, то производительность почти ровно такая же. На данный момент нам неизвестно никаких существенных проблем с перформансом. Единственное заметное отличие от байткода Java — для выражений и параметров non-null типов у нас генерируется приличное количество проверок на null, но, по нашему опыту, они не особо что-то замедляют (кроме того, они отключаемы).
Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.
С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.
2) Планируется.
Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.
С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.
2) Планируется.
Вот нативная компиляция была бы очень интересна!
А вас не посещала идея сделать транспилер в Go вместо нативного таргета?
У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.
У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.
Мысль, кстати, очень интересная, надо подумать. Мы думали в основном про варианты LLVM либо генерации кода на C, но и в том, и в другом случае ребром встает вопрос garbage collection, который в Go как раз решен.
Это было бы очень круто, хотя я не очень уверен, что это будет сильно проще LLVM+свой GC.
С LLVM главная проблема в том, что его не очень понятно как из Java использовать. Ну и свой GC, годный для использования в production — ни разу не маленькая задача.
VMKit: but the project is not more maintained, печально, но может заберете себе, к Котлину?
1) Go не более нативный язык, чем Java (и соответсвенно Kotlin). Просто у Java рантайм несколько побольше. Встроенные издержки на производительность у этих языков примерно одинаковые (рантайм проверки на null, index, GC, вызовы от интерфейсов). Поэтому при прочих равных у этих языков производительность должна быть примерно одинаковая. Хотя отстутсвие в Go наследования, и как следствие обычных вирутальных методов, делает его немного менее производительным (издержки на интерфейсный вызов несколько больше, чем на виртуальный), для тех случаев когда задачу можно решить через класcическое наследование. Ну и компиляторы для Java развиваются с конца 90-х, а Go относительно молодой язык. Поэтому я думаю, что на данный момент производительность Java (средне-статистическая), больше чем у Go. Хотя подтвердить это утверждение не могу: сравнение по производительности разных сред исполнения — довольно серьезная и большая задача, если подходить к ней серьезно, а не дилетантски.
2) Java компилируется нативно на лету (aka JIT), c 1998 года. Примерно с этого же времени существуют и статические компиляторы в нативный код (aka AOT). Более того, Oracle делает тоже сейчас AOT.
Что касается без VM, я сильно сомневаюсь, что Kotlin когда нибудь откажется от GC, а как только в рантаме языка есть GC — такой язык уже нельзя называть языком без VM. VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. Как только в вашем языке есть GC и рантайм проверки, ваш язык становится управляемым так или иначе. Будет ли Kotlin делать свою VM — тоже врядли. Могут мигрировать на какую-нибудь другую (в приниципе они уже сейчас поддерживают две VM — JavaScript и Java) — это возможно. Но один и тот же язык в двух совершенно разных средах исполнения — это по сути два разных языка, потому что одна и таже программа на Kotlin не может всегда работать одинаково в двух разных средах исполнения (или приходиться пользоваться очень ограниченным подмножестом возможностей языка). В этом смысле Kotlin для JVM и Kotlin для JavaScript — это два разных языка, несмоторя на то, что некоторые куски кода могут работать одинаково и там, и там.
2) Java компилируется нативно на лету (aka JIT), c 1998 года. Примерно с этого же времени существуют и статические компиляторы в нативный код (aka AOT). Более того, Oracle делает тоже сейчас AOT.
Что касается без VM, я сильно сомневаюсь, что Kotlin когда нибудь откажется от GC, а как только в рантаме языка есть GC — такой язык уже нельзя называть языком без VM. VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. Как только в вашем языке есть GC и рантайм проверки, ваш язык становится управляемым так или иначе. Будет ли Kotlin делать свою VM — тоже врядли. Могут мигрировать на какую-нибудь другую (в приниципе они уже сейчас поддерживают две VM — JavaScript и Java) — это возможно. Но один и тот же язык в двух совершенно разных средах исполнения — это по сути два разных языка, потому что одна и таже программа на Kotlin не может всегда работать одинаково в двух разных средах исполнения (или приходиться пользоваться очень ограниченным подмножестом возможностей языка). В этом смысле Kotlin для JVM и Kotlin для JavaScript — это два разных языка, несмоторя на то, что некоторые куски кода могут работать одинаково и там, и там.
Да забыл, написать. Из выше написанного следует, что Kotlin компилируется нативно уже сейчас, ничего планировать в этом смысле не надо.
Ну ты же понимаешь, что это на самом деле не совсем так. То, как Kotlin компилируется сейчас, например, не позволяет писать на котлине полностью нативные iOS-приложения. Компилировать его так, чтобы это было можно — это вполне интересная цель, которую вполне имеет смысл планировать.
Ну подождите немного — сделаем мы вам Kotlin для iOS, в котором можно писать совсем нативные приложения без ущерба для возможностей
Ну и вы уже сейчас, как я понимаю, интегрируетесь с RoboVM, что вас там не устраивает?
Как минимум может не устраивать то, что проект RoboVM закрыли.
Теперь, да. Но исходники ядра остались, то что умерло в недрах M$ легко дописывается силами и компетенцией JetBrains. Правда ядро RoboVM — это тоже еще тот piece of software: «я тебя слепила из того, что было». На доработку его до внятного состояния у самого RoboVM ушел бы не один год. Я поэтому и спросил, что не устраивало, но ответа не получил
Go не более нативный язык, чем Java (и соответсвенно Kotlin).
Гм. Ну, то есть посыл про то, что "VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. " ясен. Н о утверждение, что Go и Java в этом плане мало чем отличаются имеет мало общего с реальностью.
Взять хотя бы необходимость установки рантайма в систему. Это даже не говоря о скорости запуска этого рантайма.
Никто не застваляет вас ставить рантайм. Можно его таскать с собой (соврешенно легально). К тому же с компактными профилями для Java 8 размер этого рантайма становится совсем небольшим, начиная с 11MB на диске.
Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным (сравнимым с запуском нативных приложений).
Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным (сравнимым с запуском нативных приложений).
Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным
Хм, звучит интересно, вроде бы.
Но из представленных там графиков можно сделать вывод, что конкретное приложение на Java может стартавать 5 секунд (что, вообще то, не очень быстро), вместо 20 секунд (что вообще за гранью).
И что оптимизированное приложение стартует сравнимо с каким то другим нативным приложением. Это, конечно показатель.
Не просто с каким-то другим, а с реальным приложением с точно такой же функциональностью (читалка и показывалка RSS) написанная на С++.
5 секунд (что, вообще то, не очень быстро)
Возможно бенчи прводились на HDD и значительная доля времени ушла чтение кода с диска, а на SSD разница будет меньше.
Но в любом случае в обмен на это богатый рантайм позволяет вам писать приложение на смеси языков с динамической и статической типизацией и во время разработки использовать JRebel и Plumbr и ещё пачку различных тулов, которые базируются на том, что рантайм может многое рассказать о состоянии программы.
Так же я хз как это с АОТ компиляцией согласуется, но опять же благодаря богатому рантайму можно делать такие вещи: Quasar.
5 секунд — это немного для богатого ГУЕвого приложения даже с SSD. Сколько у вас Office стартует или какая-нибудь Visual Studio? Я только что проверил — у меня офис с моего Macbook Air стартовал с SSD за 10 секунд.
Такие вещи как Quasar согласуются c AOT точно также, как и большинство других Java API — то есть легко.
Такие вещи как Quasar согласуются c AOT точно также, как и большинство других Java API — то есть легко.
Планируете ли Вы помимо языка создание и поддержку инициативы вроде Typesafe по формированию стека технологий для наиболее актуальных задач на базе языка Kotlin?
Нет, потому что это не нужно — Kotlin прекрасно использует любой существующий Java-стек. Мы экспериментируем с созданием отдельных фреймворков, которые оптимальным образом используют фичи языка, но пока что у нас нет ощущения, что есть потребность в создании полного альтернативного стека.
moving forward the compiler will be backwards compatible and future versions of Kotlin must not break existing code.
вопрос:
гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд. многие могут сами добавить из наболевшего. Так ли это будет критично если раз в 10-15 лет эта самая обратная совместимость будет не соблюдаться для изменения языка в лучшую сторону? У нас уже есть Java с вечной обратной совместимостью, так ли нужно это теперь еще в Котлине?
Голосование тут показывает что большинству достаточно было бы обратной совместимости в пределах мажорного релиза.
Мы не предполагаем, что обратная совместимость Kotlin неизбежно будет вечной. Вполне возможен вариант, что в какой-то момент выйдет Kotlin 2.0, который не будет полностью обратно совместимым с 1.x, так же, как Python 3 не полностью обратно совместим с Python 2.
и не всегда удобной реализации лямбд
А что с ними не так?
никогда не сталкивались? все как надо и удобно?
вот хотя бы
https://dzone.com/articles/whats-wrong-java-8-currying-vs
https://dzone.com/articles/dark-side-java-8
вот хотя бы
https://dzone.com/articles/whats-wrong-java-8-currying-vs
https://dzone.com/articles/dark-side-java-8
- Есть ли что-то такое, что хотелось реализовать в языке, но по тем или иным причинам от этого пришлось отказаться?
- [trololo_mode]Kotlin — всего-лишь Java с более компактным синтаксисом. Переубедите?[/trololo_mode]
1) Вот, что смог вспомнить, но это далеко не всё:
- self type, отказались, т.к. вредит Java-интеропу;
- reified generics, не придумали хорошего решения, и тоже Java-интероп;
- хотели сделать, чтобы '==' был по конвенции, а не доступен на чём угодно (если есть в скоупе функция equals, возможно экстеншн, то '==' вызывает её), а также интерфейс Hashable с функцией hashCode, но это было давно и сейчас уже звучит несколько забавно;
- была идея сделать все модификаторы аннотациями, не получилось;
- хотели сделать полную защиту от NPE и считать всё, что из Java, nullable. Это была долгая и поучительная история
UFO just landed and posted this here
А будут ли подробности "поучительной истории?" Как я понял, проблемы там были с несколькими вещами:
Наследование fun (foo: String?) vs fun (foo: String)
Шаблоны Array vs Array<String?> при получении/передаче в Java
Цепочка Java — Kotlin — Java
И при таких сценариях приходилось делать много костылей, чтобы заработало. (Поправьте пожалуйста, если что не так сказал). И поэтому решили от идеи все Nullable отказаться. Но вроде как один из основных сценариев — свой код пишем на Kotlin, библиотели берем Java (как видится мне, простому крестьянину-кодеру ). И при таком раскладе, лучше безопасность в большей части кода и явные костыли в небольшой части кода, чем "красиво и удобно" + внезапные грабли в рантайме (или яма с кольями, как повезет).
Наследование fun (foo: String?) vs fun (foo: String)
Шаблоны Array vs Array<String?> при получении/передаче в Java
Цепочка Java — Kotlin — Java
И при таких сценариях приходилось делать много костылей, чтобы заработало. (Поправьте пожалуйста, если что не так сказал). И поэтому решили от идеи все Nullable отказаться. Но вроде как один из основных сценариев — свой код пишем на Kotlin, библиотели берем Java (как видится мне, простому крестьянину-кодеру ). И при таком раскладе, лучше безопасность в большей части кода и явные костыли в небольшой части кода, чем "красиво и удобно" + внезапные грабли в рантайме (или яма с кольями, как повезет).
Одна из основных причин была в том, что писать на таком языке было неудобно, а читать его — неприятно. Повсюду вопросительные и восклицательные знаки, которые не очень-то помогают из-за того, что расставляются в основном, чтобы удовлетворить компилятор, а не чтобы корректно обработать случаи, когда выражение вычисляется в null. Особенно больно в случае дженериков: например,
Map<String?, String?>?.Если отвечать на второй вопрос, то, конечно же, Kotlin отличается от Java не только синтаксисом. Например, поддержка nullability — это различие на уровне системы типов, а не синтаксиса. Фичи типа reified type parameters и delegated properties — отличия на уровне семантики. И это не говоря уже о поддержке трансляции Kotlin в JavaScript.
Мы планируем вскоре зарелизить поддержку JavaScript— немного не понял данный пункт… Можно поподробнее?
Есть компилятор Kotlin в JS, который еще не зарелижен, планируем зарелизить :)
Спасибо за ответ. Думаю, будет нужная штука :)
а как это будет выглядеть примерно? т.е. пишем UI логику страницы на котлине используя встроенные в js-kotlin runtime DOM объекты (document, window и тд.) потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?
Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот котлин код на существующей html странице отработает?
Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот котлин код на существующей html странице отработает?
потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?
Да, все так, за исключением того что мы минификацией не занимаемся, оставляя это на откуп другим тулам.
Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот код на существующей html странице отработает?
Будет инкриментальная компиляция, которая перекомпилирует только нужные файлы.
При разработке JS target'а нода учитывается?
Да, но это в основном влияет на библиотечную часть, а JS что на ноде что в браузере один и тот же.
а ES6/ES7?
Сейчас таргет только один — ES5, но мы, конечно же, следим за развитием ECMAScript и других смежных технологий.
UFO just landed and posted this here
JSONNET скорее про сереиализацию/десериализацию и у нас пока нет планов по его специальной поддержке.
Ребята, которые разрабатывают Scala.js экспериментировали с компиляцией в ES6. На текущий момент эти эксперименты показали, что скомпилированный в ES5 код работает быстрее. Для Kotlin, скорее всего, ситуация будет аналогична. К тому же, если использовать JavaScript как compilation target, то особого смысла в ES6/ES7 нет, там большинство нововведений — синтаксический сахар.
Мапы, сеты, генераторы, лямбды, промисы, символы, let, string templates по вашему это все сахар?
Я не говорил, что все нововведения в новых версиях JS — это сахар. Я сказал, что большинство — это синтаксический сахар. То есть это конструкции, которые можно выразить и в ES5, и в ES6. Яркий пример сахара — лямбды. Но, к примеру, символы — это не сахар, потому что в ES5 их не выразишь имеющимися средствами языка.
Обычное использование JS, и использование JS как compilation target — это совершенно разные вещи. Какая разница для компилятора, скомпилировать колбэк в обычную функцию, или в лямбду? Если бы лямбды работали быстрее, смысл был бы. Но на текущий момент ES6 работает медленнее, и у него худшая поддержка браузерами. Именно эту мысль я хотел донести.
Обычное использование JS, и использование JS как compilation target — это совершенно разные вещи. Какая разница для компилятора, скомпилировать колбэк в обычную функцию, или в лямбду? Если бы лямбды работали быстрее, смысл был бы. Но на текущий момент ES6 работает медленнее, и у него худшая поддержка браузерами. Именно эту мысль я хотел донести.
Не смотря на то что таргет ES5 мы стараемся воспользоваться фичами которые есть в рантайме, если это дает какой-то выигрыш. Это например Map, Set, Symbol, методы которые появились только в после ES5.
Будет ли что-то похоже на async/await из C#? Видел Kovenant, но это всего лишь промизы с потенциальной лапшой из колбэков.
Планируется ли написание более обширной документации покрывающей все аспекты языка? То, что есть сейчас на сайте хорошо для старта, но есть вещи, которые там найти нельзя совсем или они раскрыты очень слабо. И если это планируется, то когда ждать?
Да, будет спецификация языка.
Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
Собственных планов по переработке документации на сайте у нас на данный момент нет. Если вы не можете найти там какую-то конкретную информацию, то это, конечно же, баг, о котором нам нужно рассказать, и мы добавим туда информацию. Мы также следим за вопросами от пользователей и дополняем документацию на сайте, если видим, что ответа на вопрос на сайте не найти, а нужно.
Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.
Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.
В прошлом году Jake Wharton назвал невозможность компилятора Kotlin запускать annotation processors (и использовать их с Java 'as is') большим сдерживающим фактором в использовании Kotlin для разработки под андроид.
Что-то изменилось в этом плане с того времени?
Что-то изменилось в этом плане с того времени?
Я не знаю точно, что он имел ввиду, но сейчас annotation processors работают — я играюсь с проектом на Kotlin и Moxy, где все строится на аннотациях, полет нормальный.
если вы про внутренний документ Джейка про Котлин, то с момента его написания (начало 2015 г.) прошло довольно много времени, за которое успел появиться kapt — сейчас ничего не мешает использовать, например Dagger 2 с Kotlin. Если есть вопросы, могу помочь
Справедливости ради, kapt все еще толком не переваривает DataBindings: https://youtrack.jetbrains.com/issue/KT-8007
У меня 2 вопроса.
- Для андроида существует экспериментальный тулчейн. http://tools.android.com/tech-docs/jackandjill
Что Вы про него думаете? Задумывались ли Вы о возможности какой-либо интеграции с ним?
- Время компиляции при работе с андроид проектами всегда была большой проблемой.
Планируются ли какие-нибудь оптимизации в этом направлении?
1) Jack и Jill решают задачу генерации Dalvik-байткода напрямую из Java, минуя Java-байткод. Насколько я понимаю, нам никто не мешает самим генерировать Dalvik-байткод, и интегрироваться с Jack и Jill для этого не нужно и не факт, что полезно.
2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
У меня вопрос по поводу использования kapt и Android Annotations.
Сколько не пытался, так и не удалось их подружить, будет ли поддержка AA в дальнейшем?
Сколько не пытался, так и не удалось их подружить, будет ли поддержка AA в дальнейшем?
Android Annotations должны штатно работать с использованием kapt. Если что-то не в порядке, создайте, пожалуйста, баг в нашем трекере https://youtrack.jetbrains.com/issues/KT
Есть такой вопрос: планируете что-нибудь для метапрограммирования, более мощное, чем annotation processing javac'а? Например, что-нибудь из разряда Groovy AST.
Замечательный язык, очень интересна история появления — чем вдохновлялись, почему реишили создать. Если встает необходимость покодить что-то под жвм — сразу расчехляю котлин.
Решили создать по простой причине: заметили, что у нас есть IDE для такого количества прекрасных языков, а сами мы почему-то пишем все время на Java и не видим убедительной альтернативы. Ну и из предыдущего опыта было известно, что если нам самим не хватает какого-то инструмента, то с большой вероятностью он также окажется востребованным на рынке.
Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
У меня вопросы не по технической части:
- Google как-нибудь реагировал во время разработки языка и на его релиз?
- Планируется ли от них какая-нибудь официальная поддержка? У JetBrains, вроде как, имеется опыт работы с ними.
Сложно до конца честно ответить на этот вопрос. Предлагаю вернуться к нему где-то через год.
Про одну реакцию Google можно рассказать вполне честно: кусок компилятора data bindings в Android SDK написан на котлине.
Вот еще одна реакция: developer evangelist из гугла пишет про котлин с дисклеймером, что это не отражает мнение его работодателя. https://medium.com/@CodingDoug/kotlin-android-a-brass-tacks-experiment-part-1-3e5028491bcc#.dx2f41ebm
А вообще, прежде чем можно будет всерьез говорить об официальной поддержке, нужно проделать еще очень много работы с нашей стороны. Мы стараемся. :)
Вот еще одна реакция: developer evangelist из гугла пишет про котлин с дисклеймером, что это не отражает мнение его работодателя. https://medium.com/@CodingDoug/kotlin-android-a-brass-tacks-experiment-part-1-3e5028491bcc#.dx2f41ebm
А вообще, прежде чем можно будет всерьез говорить об официальной поддержке, нужно проделать еще очень много работы с нашей стороны. Мы стараемся. :)
Ну, бывает пишут о нем в своем твиттере.
И даже увидели, что Google во внутрях кое-где использует.
Kotlin & Android: A Brass Tacks Experiment, Part 1: https://t.co/1pl3UhMXKP pic.twitter.com/RaMDqG8wRx
— Android Developers (@AndroidDev) 1 февраля 2016
И даже увидели, что Google во внутрях кое-где использует.
So @project_kotlin is being used in the data binding compiler… interesting… #AndroidDev pic.twitter.com/4pJmYJqXc9
— Ross Hambrick (@rosshambrick) 24 июля 2015
Не сильно всматривался в Kotlin. Вопрос простой: почему стоит выбрать Kotlin, а не Scala?
Будет ли в Kotlin компилятор встроенная фича как в Scala dotty по выпиливанию ненужного кода?
Будет ли в Kotlin компилятор встроенная фича как в Scala dotty по выпиливанию ненужного кода?
На сайте Kotlin есть сравнение, где сказано, что если вы счастливы со Scala, то Kotlin вам не нужен. Основное различие состоит в том, что Kotlin позиционирует себя как better Java, а у Scala все же своя парадигма и идеология.
В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
1) idea-плагин может брать версию и рантайм котлина из описания maven-плагина в pom файле? Сейчас котлин конфигурируется в двух местах — в pom и в библиотеках модуля в проекте?
2) почему final val в object не транслируется в public static final field у ява-класса? приходится использовать «class.INSTANCE.val()» конструкцию.
3) lombok @Slf4j не работает… должен ли? или жаловаться разработчику?
4) dynamic — насколько он реально был востребован?
2) почему final val в object не транслируется в public static final field у ява-класса? приходится использовать «class.INSTANCE.val()» конструкцию.
3) lombok @Slf4j не работает… должен ли? или жаловаться разработчику?
4) dynamic — насколько он реально был востребован?
1) Если у вас Maven-проект, то отдельно настраивать версию библиотеки Kotlin в проекте не нужно, при импорте из Maven все само настроится. Но при этом очень желательно, чтобы версия Kotlin, на которую вы ссылаетесь в pom.xml, совпадала с версией плагина, который установлен в IDE — а эта версия не может быть разной для разных проектов.
2) Транслируется, если пометить его аннотацией @JvmField.
3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.
4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.
2) Транслируется, если пометить его аннотацией @JvmField.
3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.
4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.
«Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.»
3) а как развернуть @Slf4j в kotlin-way? у меня получается только через companion object c @JvmField полем, примерно так (по памяти):
companion object {
JvmField
final val logger = LoggerFactory.getLogger(Klass::class.java)
}
и приходится следить, чтоб имя класса соответствовало. да и лишние 4 строчки. Несравнимо с @Slf4j из ломбока. Приходилось есть кактус.
5) И ещё момент со спрингом. Если у поля есть Inject, то поле проинициализируется до начала работы бина. То есть оно точно будет не null. Но приходится делать его nullable и каждый раз писать "!." при обращении к методам. Можно ли как-то сделать красиво — чтоб поле было не nullable, но и инициализации его при объявлении не было? Вариант с Inject в конструкторе не всегда удобно. То же самое с Mock полями в тестах. Понятно, что это не по-котлиновски. Но вдруг есть workaround от авторов.
3) а как развернуть @Slf4j в kotlin-way? у меня получается только через companion object c @JvmField полем, примерно так (по памяти):
companion object {
JvmField
final val logger = LoggerFactory.getLogger(Klass::class.java)
}
и приходится следить, чтоб имя класса соответствовало. да и лишние 4 строчки. Несравнимо с @Slf4j из ломбока. Приходилось есть кактус.
5) И ещё момент со спрингом. Если у поля есть Inject, то поле проинициализируется до начала работы бина. То есть оно точно будет не null. Но приходится делать его nullable и каждый раз писать "!." при обращении к методам. Можно ли как-то сделать красиво — чтоб поле было не nullable, но и инициализации его при объявлении не было? Вариант с Inject в конструкторе не всегда удобно. То же самое с Mock полями в тестах. Понятно, что это не по-котлиновски. Но вдруг есть workaround от авторов.
3) Я бы просто завел private val logger = LoggerFactory.getLogger(Klass::class.java) на уровне файла. Если сделать хелперную функцию, можно сократить это до private val logger = getLogger()
5) Для решения этой проблемы у нас придуман модификатор lateinit.
5) Для решения этой проблемы у нас придуман модификатор lateinit.
Поправка форматирования: private val logger = getLogger<Klass>()
внутренний голос убеждает, что такому полю следует быть final static transient. этого и добивался.
жаль, что никак. ну ок
жаль, что никак. ну ок
Почему никак? final static оно будет само. Если вам вдруг зачем-то надо сериализовать фасадный класс (класс, в который помещаются декларации, находящиеся на уровне файла), вы можете повесить на него аннотацию Transient.
UFO just landed and posted this here
1) и 2) оставлю коллегам, которые занимаются JS и стандартной библиотекой. Со своей стороны скажу, что все будет хорошо. :)
3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.
4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.
5) Есть, и мы обязательно его опубликуем, как только закончим обсуждение внутри команды.
3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.
4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.
5) Есть, и мы обязательно его опубликуем, как только закончим обсуждение внутри команды.
1) стандратная библиотека разрабатывается с учетом имеющихся сейчас таргетов и там еть API доступное для обоих платформах, и есть платформо-специфичное API. В свою очередь платорфмо-независемое API могут иметь разные реализации.
2) Политика сейчас такая, что практически все фичи языка должны работать на обоих платформах и иметь одинаковую семантику, по модулю некоторых особенностей платформы, например работа с примитивами или реализация регулярных выражений.
2) Политика сейчас такая, что практически все фичи языка должны работать на обоих платформах и иметь одинаковую семантику, по модулю некоторых особенностей платформы, например работа с примитивами или реализация регулярных выражений.
Будет ли поддержка подсветки синтаксиса языа в текстовом редакторе Atom?
Сделать такую подсветку — это несколько часов работы максимум, так что кто-нибудь когда-нибудь наверняка сделает. Мы сами этим заниматься не планируем.
Кто-то уже постарался — https://atom.io/packages/language-kotlin
когда допишется книга Дмитрия и Светланы?
когда допишется книга Дмитрия и Светланы?
в ява-файле в контекстном меню была опция похожая на «suppress unused warning for class annotated with @тутимяаннотации », например для аннотации Controller. возможно в котлин-плагин такую фичу запилить для классов и методов?
Сделаем, да. Голосуйте за https://youtrack.jetbrains.com/issue/KT-9276
Пока что можно на unused классе нажать Alt+Enter -> Edit inspection profile setting -> Configure annotations и добавить туда нужную аннотацию, класс должен перестать быть unused
Почему значение функции не определяется ее последним выражением как в Scala, а требуется специальный оператор return, как в старых языках?
По-моему вы троллите.
Haskell появился где-то в середине восьмидесятых — начале девяностых прошлого века, а вы в две тысячи шестнадцатом говорите об отсутствии «return» как о признаке «новизны». Не говоря уже о том, что корни такой нотации растут из записи математических формул.
IMHO неиспользование return можно оправдать только нестерпимым желанием прострелить себе ногу.
Haskell появился где-то в середине восьмидесятых — начале девяностых прошлого века, а вы в две тысячи шестнадцатом говорите об отсутствии «return» как о признаке «новизны». Не говоря уже о том, что корни такой нотации растут из записи математических формул.
IMHO неиспользование return можно оправдать только нестерпимым желанием прострелить себе ногу.
Haskell, *ML, Lisp все-таки редкие языки. Языки, не требующие специального оператора, стали получать распространение сравнительно недавно.
Неиспользование return способствует использованию коротких понятных функций и улудшает читабельность и провторное использование кода.
Как отказ от return помогает "прострелить себе ногу"? По моему наоборот, привычка его использовать может вести к неожиданным эффектам.
Неиспользование return способствует использованию коротких понятных функций и улудшает читабельность и провторное использование кода.
Как отказ от return помогает "прострелить себе ногу"? По моему наоборот, привычка его использовать может вести к неожиданным эффектам.
В котлине есть нотация для "коротких понятных функций" без использования return:
Присоединюсь к Maccimo во мнении что для всего что длиннее одной строки return нужен.
fun summ(a: Int, b: Int) = a + bПрисоединюсь к Maccimo во мнении что для всего что длиннее одной строки return нужен.
Можете пример дать? У меня, честно говоря, фантазии не хватает придумать такой кейс, когда бы return понадобился во имя безопасности. По личному опыту с изучением и дальнейшей работой со scala адаптация прошла почти мгновенно и проблем не было за все время (скорее только вздох облегчения).
много точек выхода в разных местах усложняют анализ и поддержку кода:
http://stackoverflow.com/a/733858/365675
отказ от return вынуждает иметь одну точку выхода в конце.
http://stackoverflow.com/a/733858/365675
отказ от return вынуждает иметь одну точку выхода в конце.
Два разных синтаксиса для функций, IMHO, излишество.
А в чем польза от return? Лично мне он только мешает. Сталкивался со многими его адептами, но полезности мне так ни кто и не объяснил. Доходило до того, что допускали его только последним оператором функции, но само слово все равно считали необходимым. Мне интересно узнать почему, особенно от дизайнеров языка.
А в чем польза от return? Лично мне он только мешает. Сталкивался со многими его адептами, но полезности мне так ни кто и не объяснил. Доходило до того, что допускали его только последним оператором функции, но само слово все равно считали необходимым. Мне интересно узнать почему, особенно от дизайнеров языка.
1) Очень не хватает алиасов для типов. Хотя бы как в плюсах. И в скале алиасы есть ^__^
Для простых алиасов пока можно выкрутиться подобием правой руки –
Вроде видел в комментах к ранним версиям, что такая фича планируется после релиза. Какие причины/сложности были не делать сразу?
2) Можно как-то сделать крэши kotlin-plugin менее назойливыми? Я даже соглашусь с автоматической отправкой крэш-репорта :D
Спасибо вам, язык хорош!
Для простых алиасов пока можно выкрутиться подобием правой руки –
import kotlin.String as EntityKey, но это некий костыль костыля и не серьёзно ни разу.Вроде видел в комментах к ранним версиям, что такая фича планируется после релиза. Какие причины/сложности были не делать сразу?
2) Можно как-то сделать крэши kotlin-plugin менее назойливыми? Я даже соглашусь с автоматической отправкой крэш-репорта :D
Спасибо вам, язык хорош!
1) Алиасы для типов будут обязательно. Насколько я понимаю, сложностей там никаких не было — просто фича не казалась особенно приоритетной, а когда мы поняли, что казалась неправильно, нужно было уже стабилизироваться к релизу, а не добавлять новые фичи.
2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
-
относительно методов коллекций filter и подобным ему (нетерминальным): сейчас все сгружается в ArrayList и возвращается как результат функции.
подобные вещи в Java8 делаются через стрим без промежуточных хранилищ.
про производительность спрашивать не стану, это дело конкретных кейсов. интересует были ли полемики на альтернативные подходы типа «возовращаем Iterable<> и пусть делают toList()»? если да, то какие были варианты и почему остановились на этом.
подобные вещи в Java8 делаются через стрим без промежуточных хранилищ.
про производительность спрашивать не стану, это дело конкретных кейсов. интересует были ли полемики на альтернативные подходы типа «возовращаем Iterable<> и пусть делают toList()»? если да, то какие были варианты и почему остановились на этом.
Google предоставил крутую возможность работы с NDK прямо из студии. Такие проекты требуют определенного формата Gradle файла и еще ряда других приседаний. Будет ли возможность писать такие проекты на Kotlin? Сейчас при попытке подключить Kotlin-плагин к такому проекту показывается ошибка о невозможности найти "android {}" в Gradle файле.
Мы пока на это не смотрели, но, если есть юзкейсы, можем поддержать. Напишите нам реквест в https://youtrack.jetbrains.com/issues/KT
По началу исходники на Kotlin мне показались очень страшными непривычными, что пугало. Но повыполнял задания в песочнице и влюбился в этот язык. Это Java, только лучше! Как раз то, чего так сильно нехватало.
Кронштадт вперёд!))
Кронштадт вперёд!))
(del)
А можно выделить какие-нибудь приемущества котлина перед груви?
Знаю что в груви есть практически все фичи, которые имеются в котлине: есть лямбды, null safe, extention function и другие прелести.
Есть возможность сделать статическую компиляцию с помощью аннотации @CompileStatic.
А с версии 2.4 груви можно без проблем использовать на андроиде.
Знаю что в груви есть практически все фичи, которые имеются в котлине: есть лямбды, null safe, extention function и другие прелести.
Есть возможность сделать статическую компиляцию с помощью аннотации @CompileStatic.
А с версии 2.4 груви можно без проблем использовать на андроиде.
А че минусуем то? Я не ненавистник котлина, а наоборот. Написал пару приложений под андроид на нем и в восторге.
Дело в том, что я хочу выяснить сабж выше и только. А у кого еще, как не у разработчиков языка это спросить?
Дело в том, что я хочу выяснить сабж выше и только. А у кого еще, как не у разработчиков языка это спросить?
Мы, честно говоря, особенно не занимались сравнением с Groovy, потому что это язык преимущественно динамический. Ниже я укажу пару очевидных отличий, а остальное оставлю тем, кто готов сделать более подробный обзор.
Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.
Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.
Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
Похоже, вы таки занимались сравнением, потому что этот FUD это ровно то, что повторяет весь JetBrains (например, yole в #razborpoletov). Например, концепция того, что либо динамический и поэтому всё плохо, либо включить статическую компиляцию, и тогда сплошная джава — это полнейший FUD, потому что главное преимущество, конечно, в том, что когда нужно, Груви динамический, а когда нужно, быстрый как Джава.
Ну и про "не пробовал, но осуждаю" на Андроиде тоже всё ясно.
Ну и про "не пробовал, но осуждаю" на Андроиде тоже всё ясно.
Не хотелось бы скатываться в эмоциональные выпады. Я раскрою немного вопрос про динамику и статику, раз он вызвал такой живой отклик.
Когда мы делали Kotlin, у нас были вполне конкретные требования:
В данном случае нас интересуют первый и второй пункты. Верно ли, что языки должны быть статически типизированными — это бессмысленный вопрос. Некоторые люди предпочитают статически типизированные, а некоторые другие люди — динамически типизированные. Мы относимся к первой группе. Это значит, что мы хотим, чтобы наш код был статически типизированным. Кроме отлова ошибок на стадии компиляции, это, в том числе, дает возможность тулингу много чего про код точно понять, что невозможно в динамическом языке. Естественно, не все люди на свете хотят такой тулинг или ловить баги на стадии компиляции, но мы хотим, и думаем, что есть много людей, которые тоже хотят.
Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.
Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
Когда мы делали Kotlin, у нас были вполне конкретные требования:
- статическая типизация для поддержки больших объемов кода,
- очень хороший тулинг (для этого тоже нужна статическая типизация),
- совместимость для миграции и переиспользования инфраструктуры,
- "демократичность" языка (не нужно делить фичи на "для всех" и "не для всех").
В данном случае нас интересуют первый и второй пункты. Верно ли, что языки должны быть статически типизированными — это бессмысленный вопрос. Некоторые люди предпочитают статически типизированные, а некоторые другие люди — динамически типизированные. Мы относимся к первой группе. Это значит, что мы хотим, чтобы наш код был статически типизированным. Кроме отлова ошибок на стадии компиляции, это, в том числе, дает возможность тулингу много чего про код точно понять, что невозможно в динамическом языке. Естественно, не все люди на свете хотят такой тулинг или ловить баги на стадии компиляции, но мы хотим, и думаем, что есть много людей, которые тоже хотят.
Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.
Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
Видишь, есть такое объективно наблюдаемое явление: на Groovy под Android никто не программирует. Я не вижу ни заметного количества вопросов на StackOverflow от людей, которые сталкиваются с какими-то проблемами в этой связке, ни баг-репортов про то, что у кого-то что-то не работает в идее, ни блог-постов от людей, которые рассказывают, как у них круто получилось запрограммировать такое приложение и как всем тоже нужно бежать этим пользоваться. (Если я неправ, покажи, пожалуйста, ссылки.)
Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.
Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.
Ну раз пошла пьянка, можно вкинуть про Scala?
Чем Kotlin, лучше Scala в android разработке?
Чем Kotlin, лучше Scala в android разработке?
Наброс засчитан :) Отвечаю в художественной форме, потому что ну не могу уже :)
Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)
Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?
В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
Чем Kotlin, лучше Scala в android разработке?
Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)
Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?
В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
Просто тут нет универсального ответа, потому что для кого-то стандартная библиотека в 820KB — это преимущество, например, а кому-то все равно. Кому-то без макросов никуда, а кому-то отлично… Но судя по всему, есть много людей, которых Scala на Андроиде не устраивает (по каким-то из вышеописанных параметров, надо полагать), а Kotlin устраивает.
ИМХО, скала отлично подходит для разработки серверов, так как язык достаточно мощный. Но для андроида он слишком медленно будет бегать на большинстве девайсов.
Сейчас Koans. В целом после C# весьма комфортно, интересно было бы посмотреть еще туториалы о том, как на Kotlin создать базовое приложение со Spring.Mvc+Spring.Rest в той же Идее. А так молодцы) Наверное Kotlin самая интересная альтернатива C#.
Решаю* :)
Мне кажется вы можете начать писать в стиле чистой java используя примеры для нее.
Просто потом, когда более-менее привыкнете к котлину, отрефакторите.
Просто потом, когда более-менее привыкнете к котлину, отрефакторите.
Проблема в том, что я не джавист :) Просто когда разбирался со Спрингом — был не самый приятный опыт. Особенно когда вышел Boot и часть туториалов просто не работала. Надо же еще и IDE подшаманить как я понимаю. что бы это все взлетело. Поэтому и интересуюсь каким-нибудь quick-start. Думаю будем полезно многим, кто не сильно знаком с JVM — based миром.
Почему вы решили оставить инкремент как выражение? Вроде столько копий поломано, миллион и одно собеседование с данным вопросом. Оставили бы его как statement, если нравится.
Какие языки оказали сильное влияние на Kotin? Например, функциональщина вроде any, all похожа на питоновскую в противовес exists, forall из Scala.
Интересный язык. Приятные плюшки других языков и всё это со статической типизацией. abreslav Вопрос про исключения. Есть ли возможность включить какие-то варнинги насчет необработаных исключений или хотя бы подсветку какую-нибудь? А то я узнаю о них из стектрейсов или нужно кажый используемый метов в программе просматривать на наличие бросаемых исключений.
Рас уж речь зашла о подсветке… Глупый вопрос, но почему по дефолту цвет аннотаций и ключевых слов совпадает? Вы таки будете смеяться, но какой-то унылый код без желтых аннотаций. А при их большом числе (spring, etc.) так вообще сливается в монотонное месиво.
А есть ли возможность добавить подсветку в студии для типов с <!>, которые получаются при взаимодействии с java? Сейчас очень велика вероятность пропустить такой тип (под пропустить имеется ввиду забыть его проверить на null) из-за прозрачной конвертации в not null типы в kotlin.
А почему делегировать можно только в интерфейсы? Нет ли тут обрезки функционала? Например хочется сделать так:
Но нельзя, т.к. ByteBuffer — не интерфейс, и не имеет интерфейса. И наследоваться от него нельзя, потому что final. Неудобно.
class Foo(val buf:ByteBuffer): ByteBuffer by buf {
//...
}Но нельзя, т.к. ByteBuffer — не интерфейс, и не имеет интерфейса. И наследоваться от него нельзя, потому что final. Неудобно.
Как сделать extension метод для enum, чтобы был доступ к Enum.values()? И где определены values() и valueOf()?
На StackOverflow есть решение с reflection, там вместо
values() используют enumConstants, но про valueOf() не написано.Почему в stdlib / kotlin.collections есть:
List — это Collection
Set — это — Collection
Map — не Collection??
Я в курсе, что так в Java, и было бы неудобно делать интероп с Java и т.д. С массивами как-то выкрутились же.
Если посмотреть на интерфейс Collection:
то выясняется, что у Map не реализован только метод containsAll(), который очевидно реализуется из contains. Остальные либо уже есть, либо реализованы через extension.
List — это Collection
Set — это — Collection
Map — не Collection??
Я в курсе, что так в Java, и было бы неудобно делать интероп с Java и т.д. С массивами как-то выкрутились же.
Если посмотреть на интерфейс Collection:
package kotlin.collections
public interface Collection<out E> : kotlin.collections.Iterable<E> {
public abstract val size: kotlin.Int
public abstract operator fun contains(element: @kotlin.UnsafeVariance E): kotlin.Boolean
public abstract fun containsAll(elements: kotlin.collections.Collection<@kotlin.UnsafeVariance E>): kotlin.Boolean
public abstract fun isEmpty(): kotlin.Boolean
public abstract operator fun iterator(): kotlin.collections.Iterator<E>
}то выясняется, что у Map не реализован только метод containsAll(), который очевидно реализуется из contains. Остальные либо уже есть, либо реализованы через extension.
Как, по-вашему, мы выкрутились с массивами? :)
Я имел в виду IntArray, LongArray, CharArray и прочие
Не вижу связи с коллекциями
В своем первом комментарии я написал "С массивами как-то выкрутились же", пытаясь, может быть не совсем корректно, привести пример того, что в Kotline не все так, как в Java. В котлине нет int[] и прочих, и для interop с Java сделан специальный инструмент IntArray и т.д. Этим примером я неуспешно пытался заранее контр-аргументировать предсказуемый ответ "потому что в Java Map не является коллекцией" на мой вопрос "почему Map — не Collection в Kotlin?" Этим превентивным контр-аргументом я неуспешно пытался подтолкнуть отвечающего дать развернутое и подробное объяснение.
Прошу вас теперь все-таки ответить на мой основной вопрос в этой ветке:
Почему Map не является коллекцией в Kotlin?
Прошу вас теперь все-таки ответить на мой основной вопрос в этой ветке:
Почему Map не является коллекцией в Kotlin?
Потому что в Java Map не реализует интерфейс Collection, и у нас нет никакой возможности его заставить это делать (и нигде более в языка мы ничего подобного не делаем, а когда пытались, получались ошибки во время выполнения). Придумать более подробный ответ я не смог, задайте уточняющий вопрос, если есть какое-то надопонимание.
Кстати, int[] и IntArray — это одно и то же решение, то есть специальный тип для массива примитивов, только синтаксис разный.
Кстати, int[] и IntArray — это одно и то же решение, то есть специальный тип для массива примитивов, только синтаксис разный.
Спасибо за ответ.
Скажите, а java.lang.String и kotlin.String — это тоже различия на уровне синтаксиса или разные классы? Если второе, то наверно похожий трюк можно провернуть и с Map, нет?
Скажите, а java.lang.String и kotlin.String — это тоже различия на уровне синтаксиса или разные классы? Если второе, то наверно похожий трюк можно провернуть и с Map, нет?
Это различия на уровне синтаксиса, иначе не было бы никакого интеропа. (Отмечу, что заменить один класс на другой и добавить существующему классу новый суперкласс — это не одно и то же :))
И подозреваю, что сделать kotlin.Map + добавить его поддержку в синтаксисе не получится/не планируется? Как насчет того, чтобы в stdlib напихать extension методов? Изначально вопрос возник из-за того, что внезапно у Map нет first(), хотя есть iterator(). Конечно, все можно делать через entries, но я, наверно, сладкоежка и слишком избалован скалой :)
Таких планов на данный момент нет. Но Вы можете сделать нужные экстеншены сами, если они действительно облегчают жизнь.
Для справки: kotlin.Map и так существует, и мы с Вами говорим именно о нем. Поддержка его в синтаксисе, возможно, будет, но как это связано с темой разговора, я пока не очень понимаю.
Для справки: kotlin.Map и так существует, и мы с Вами говорим именно о нем. Поддержка его в синтаксисе, возможно, будет, но как это связано с темой разговора, я пока не очень понимаю.
Google переведёт ОС Android на язык программирования Apple Swift
Можете прокомментировать?
Представители Google планировали использовать язык Kotlin, однако данное ПО не может удовлетворить запросы разработчиков и отличается низкой производительностью.
Можете прокомментировать?
Источник этого слуха (тут) не заслуживает доверия.
А вы никак не лоббируете на этом уровне Kotlin? Если есть реальные претезии- можно же попробовать с ними поработать…
не может удовлетворить запросы разработчиков и отличается низкой производительностью
в целом неясно откуда могли появиться слухи о низкой производительности, если котлин изначально затачивался легковесным и весит всего 200кб
Судя по Источник, Google еще официально ничего не объявило, а лишь рассматривает Swift в качестве альтернативного языка для разработки под Android, впрочем как и Kotlin.
Swift — открытый мультипарадигменный объектно-ориентированный язык программирования общего назначения. Создан компанией Apple в первую очередь для разработчиков iOS и OS X. Swift работает с фреймворками Cocoa и Cocoa Touch и совместим с основной кодовой базой Apple, написанной на Objective-C.
интересно, а apple их потом исками не закидает за какой нибудь «копипаст пары строчек» в реализации, как Oracle пытался )
Добрый день, belovrv
Есть ли способ создать .kt файлы c помощью javax.annotation.processing.Processor?
Есть ли способ создать .kt файлы c помощью javax.annotation.processing.Processor?
Этот пост — уже часть истории. Вопросы можно задать у нас в Слэке (http://slack.kotlinlang.org/) или в форуме (https://discuss.kotlinlang.org/)
Sign up to leave a comment.
Kotlin 1.0. Задай вопрос команде