Вполне возможно что появится мульти-платформенная реализация для длинной арифметики. На JVM это будет компилироваться в BigInteger, на других платформах скорее всего потребуются кастомные реализации.
Заводите тикет в баг-трекере, формулируйте спецификацию, пишите прототип. Котлин очень близко работает с сообществом, и многие фичи появиличь именно таким способом.
PS Скорее всего длинная арифметика будет не в стандартной библиотеке, а в соопутствующей библиотеке kotlinx, так что имеет смысл писать сразу туда. Или вообще делать свою биюлиотеку.
Роман Елизаров в одном из последних выступлений говорил что Kotlin coroutines некорректно называть безстековыми. Стек есть, но только при вызовах suspend функций из suspend функций, которые могут быть произвольной вложенности.
Звучит так как будто при неосторожном смешивании библиотек производительность начинает резко просидать. Так себе ситуация, IMHO. Подход Kotlin с черной магией в компиляторе в этом смысле сильно лучше.
Я понимаю что в этой статье вы не ставили себе задачу сравнить все за и против, но вообще это был бы один из минусов Ceylon.
API где нужно всюду передавать $TypeDescriptor$ не назовешь идиоматичным Java кодом.
Я хотел еще раз подчеркнуть что в Kotlin трактовке "совместимость в обе стороны" подразумевает идиоматичный вид Java из Kotlin и Kotlin из Java. Мне кажется этот очень важный факт принижается в статье с отмашкой "где мы такое не видели".
Как работают стандартные коллекции в Ceylon? Они "свои" или используются классы из JDK? Если я использую совместимость с Java, придется ли мне копировать (даже если и неявно) из коллекции в коллекцию?
В Kotlin выкинули овеществленные дженерики чтобы со стороны Java код выглядел нормально. Без этой жертвы странно говорит про 100% или даже 99% совместимость с Java.
Удивлен что не было упомянуто решение "в Kotlin стиле" — завернуть все эту логику с ссылками в одну функцию:
api.getCommentsWeakRef { list, exception ->
if (list != null)
updateUI(list) // the methods are called on a weak reference
else
displayError(exception!!)
}
Это было сделано из соображений удобства и производительности. Удобство в том что не нужно дополнительно звать коллектор в конце. Производительность проявляется в том что на маленьких коллекциях (до 10`000), которых большинство, локальность операций по памяти важнее чем выделение-освобождение списков.
И как уже упомяналось, в любой момент можно перейти к ленивой семантике с asSequence() или даже к Java8-streams с asStream()
Когда вы запилите LINQ и уже можно будет мигрировать .Net -> Kotlin не расставаясь с привычными фичами?
Разрешите поинтересоваться, а для чего вы используете LINQ в C# и с каким именно его фичами вы не хотели бы расставаться?
Работа с коллекциями в Kotlin на полную катушку через уже традиционные map/filter, по-моему даже удобнее чем любой SQL. Для доступа к базам данных и статическому формированию SQL-запросов есть пара активных библиотек, например Exposed одна из более экспериментальных.
Конкретно этот пример работает для версии компилятора 1.0.6 (можно выбрать внизу вместо 1.1). Вероятная причина в том что Kotlin APIs для JavaScript слегка поменялись между 1.0 и 1.1. Примеры с переносимым кодом запускаются как на JVM, так и на JS под любой версией.
А если еще и обратная совместимость <...> будет постоянно ломаться
Надеюсь тема про совместимость взялась не из довольно тухлого срача в VK несколько-дневной давности, потому что Kotlin еще ни разу (тьфу-тьфу) не нарушил совместимость, которую команда обещала.
Программисты программистами, а некоторые синтаксические конструкции провоцируют писать плохой код.
В этом смысле if-else имеет преимущество. Во первых, выражение if-else чаще разносят на отдельные строки, почему то так принято. Во вторых, if-else легче подсветить ярким синим цветом который визуально выделяется в остальном коде, в то время как подсветка ? : такого эффекта не дает.
Но это все довольно субъективно, и как уже отмечалось, в Kotlin рассматривают возможность добавления тернарного оператора.
for-loop в Kotlin это не совсем foreach. Вы уже наверное посмотрели byte-code и знаете, что в ряде случаев итератор в for-loop заменяется на стандартный цикл с индексами. Это ставит производительность for-loop на совсем другой уровень по сравнению в forEach.
Вообще я насчитал 5 случая применения С-подобного for-а, и считаю что Kotlin ни в чем не проигрывает:
1) Перебор значений:
for(x in 101..200) {...}
2) Перебор индексов в коллекции:
for(i in list.indices) {...}
3) Перебор элементов коллекции:
for(value in values) {...}
4) Повторение операции N раз:
repeat(N) {...} // все оптимизируется в for(int i = 0; i < N; i++) {...}
5) Повторение операции пока верно условие
while(condition) {...}
// да, для такого и в C лучше использовать while если хотите чтобы в коде было легко разобраться
Нет, чистый Kotlin null-safe, проверки будут только на стыке Java и Kotlin.
Не совсем, Kotlin вынужден ставить проверки во всех публичных метода на случай если их позовут из Java.
Другое дело что на JVM null-проверки не только ничего не стоят, а более того, в ряде случаев и ускоряют код, так как позволяют JIT лучше оптимизировать.
Тернарный оператор вносит нечитабельный код. В больших проектах на C или Java с завидной переодичностью встречаются ... ? .... : .... выражения на 3 строки, а то и больше. И сделать с этим ничего нельзя — в отличие от if-else, ?-: даже с подсветкой синтаксиса плохо читается.
У поддержки null типов в Котлин в том виде в котором она там есть два очень весомых "смысла":
1) Устраняется "распространение" null-ов. Основная боль в Java в том что null может быть незаметно передан из функцию в функцию, из поля в поле, и NPE вылетит совсем не там где null возник. Для этого рекомендуется всюду ставить null-проверки, но не все это делают. Kotlin имеет null-assert-ы во всех публичных методах, и распространение null-ов предотвращается на самом раннем этапе.
2) Null-типы позволяют декларировать nullability явно и удобно (в отличие от аннотаций). Это сильно упрощает использование кода на Kotlin.
Это очень мешает визуально и и не позволяет корректно включать оба блока кода. Но такую ситуацию можно разрешить имея AST. Ведется ли работа в этом направлении?
Ещё в объяснении поправите пожалуйста
Почему-то я думал что это история про использование Kotlin/Native для реализации доменной логике на двух платформах
Вполне возможно что появится мульти-платформенная реализация для длинной арифметики. На JVM это будет компилироваться в BigInteger, на других платформах скорее всего потребуются кастомные реализации.
Заводите тикет в баг-трекере, формулируйте спецификацию, пишите прототип. Котлин очень близко работает с сообществом, и многие фичи появиличь именно таким способом.
PS Скорее всего длинная арифметика будет не в стандартной библиотеке, а в соопутствующей библиотеке kotlinx, так что имеет смысл писать сразу туда. Или вообще делать свою биюлиотеку.
Роман Елизаров в одном из последних выступлений говорил что Kotlin coroutines некорректно называть безстековыми. Стек есть, но только при вызовах suspend функций из suspend функций, которые могут быть произвольной вложенности.
Звучит так как будто при неосторожном смешивании библиотек производительность начинает резко просидать. Так себе ситуация, IMHO. Подход Kotlin с черной магией в компиляторе в этом смысле сильно лучше.
Я понимаю что в этой статье вы не ставили себе задачу сравнить все за и против, но вообще это был бы один из минусов Ceylon.
API где нужно всюду передавать
$TypeDescriptor$не назовешь идиоматичным Java кодом.Я хотел еще раз подчеркнуть что в Kotlin трактовке "совместимость в обе стороны" подразумевает идиоматичный вид Java из Kotlin и Kotlin из Java. Мне кажется этот очень важный факт принижается в статье с отмашкой "где мы такое не видели".
Как работают стандартные коллекции в Ceylon? Они "свои" или используются классы из JDK? Если я использую совместимость с Java, придется ли мне копировать (даже если и неявно) из коллекции в коллекцию?
В Kotlin выкинули овеществленные дженерики чтобы со стороны Java код выглядел нормально. Без этой жертвы странно говорит про 100% или даже 99% совместимость с Java.
Удивлен что не было упомянуто решение "в Kotlin стиле" — завернуть все эту логику с ссылками в одну функцию:
Это было сделано из соображений удобства и производительности. Удобство в том что не нужно дополнительно звать коллектор в конце. Производительность проявляется в том что на маленьких коллекциях (до 10`000), которых большинство, локальность операций по памяти важнее чем выделение-освобождение списков.
И как уже упомяналось, в любой момент можно перейти к ленивой семантике с
asSequence()или даже к Java8-streams сasStream()Разрешите поинтересоваться, а для чего вы используете LINQ в C# и с каким именно его фичами вы не хотели бы расставаться?
Работа с коллекциями в Kotlin на полную катушку через уже традиционные map/filter, по-моему даже удобнее чем любой SQL. Для доступа к базам данных и статическому формированию SQL-запросов есть пара активных библиотек, например Exposed одна из более экспериментальных.
Конкретно этот пример работает для версии компилятора 1.0.6 (можно выбрать внизу вместо 1.1). Вероятная причина в том что Kotlin APIs для JavaScript слегка поменялись между 1.0 и 1.1. Примеры с переносимым кодом запускаются как на JVM, так и на JS под любой версией.
Надеюсь тема про совместимость взялась не из довольно тухлого срача в VK несколько-дневной давности, потому что Kotlin еще ни разу (тьфу-тьфу) не нарушил совместимость, которую команда обещала.
Процитирую более развернутый комментарий @gilgor: https://habrahabr.ru/post/322256/#comment_10081594
Программисты программистами, а некоторые синтаксические конструкции провоцируют писать плохой код.
В этом смысле
if-elseимеет преимущество. Во первых, выражение if-else чаще разносят на отдельные строки, почему то так принято. Во вторых,if-elseлегче подсветить ярким синим цветом который визуально выделяется в остальном коде, в то время как подсветка? :такого эффекта не дает.Но это все довольно субъективно, и как уже отмечалось, в Kotlin рассматривают возможность добавления тернарного оператора.
for-loopв Kotlin это не совсем foreach. Вы уже наверное посмотрели byte-code и знаете, что в ряде случаев итератор в for-loop заменяется на стандартный цикл с индексами. Это ставит производительность for-loop на совсем другой уровень по сравнению в forEach.Вообще я насчитал 5 случая применения С-подобного for-а, и считаю что Kotlin ни в чем не проигрывает:
1) Перебор значений:
2) Перебор индексов в коллекции:
3) Перебор элементов коллекции:
4) Повторение операции N раз:
5) Повторение операции пока верно условие
Не совсем, Kotlin вынужден ставить проверки во всех публичных метода на случай если их позовут из Java.
Другое дело что на JVM null-проверки не только ничего не стоят, а более того, в ряде случаев и ускоряют код, так как позволяют JIT лучше оптимизировать.
Тернарный оператор вносит нечитабельный код. В больших проектах на C или Java с завидной переодичностью встречаются
... ? .... : ....выражения на 3 строки, а то и больше. И сделать с этим ничего нельзя — в отличие от if-else, ?-: даже с подсветкой синтаксиса плохо читается.У поддержки null типов в Котлин в том виде в котором она там есть два очень весомых "смысла":
1) Устраняется "распространение" null-ов. Основная боль в Java в том что null может быть незаметно передан из функцию в функцию, из поля в поле, и NPE вылетит совсем не там где null возник. Для этого рекомендуется всюду ставить null-проверки, но не все это делают. Kotlin имеет null-assert-ы во всех публичных методах, и распространение null-ов предотвращается на самом раннем этапе.
2) Null-типы позволяют декларировать nullability явно и удобно (в отличие от аннотаций). Это сильно упрощает использование кода на Kotlin.
Правильно ли я понял что наличие на ваш взгляд бесполезного for-цикла усложняет вам жизнь? Или все это сарказм с начала и до конца?
Планируется ли дальше улучшать алгоритм для git diff и git merge?
Например часто встречается проблема при мердже двух блоков кода когда последняя скобка не входит в дифф:
Это очень мешает визуально и и не позволяет корректно включать оба блока кода. Но такую ситуацию можно разрешить имея AST. Ведется ли работа в этом направлении?