Pull to refresh

Comments 25

Был на jeeconf в мае этого года, там Андрей Бреслав (возглавляет разработку языка) делал доклад по нему — рассказывает довольно интересно, но насколько я понимаю до хотя бы релиза ещё далековато. Кому интересно есть видео доклада jeeconf.com/materials/kotlin/
Скажите, а чем он лучше groovy 2.0 или той же scala?
Groovy — динамическая типизация, Kotlin — статическая. Отсюда все вытекающие недостатки и преимущества (скорость работы приложений, обнаружение ошибок в compile-time и т.п.)

Развернутое сравнение со Scala читайте здесь. В основе отличий лежат два принципа:

1. Компиляция как минимум не медленнее, чем у Java
2. Сделать язык по возможности более простым.

Во избежание холивара, цитирую: «Если вас Scala полностью устраивает, возможно Kotlin вам и не нужен».
Groovy 2.0 хоть и поддерживает статическую типизацию всё же больше скриптовый язык, поэтому сравнивать я бы их не стал. Ситуацию со scala я попытался описать в разделе «о проекте». Если коротко, то скала сложный язык не только для программиста, но и для создание ide.
Начинал изучать Scala для общего развития, но в какой-то момент застопорился из-за того, что разработка даже «одноразовых скриптов» явно подразумевает знание сановских оракловских библиотек для Java, а в книгах по Scala они не описываются. С Kotlin такая же проблема?
С Котлином такой проблемы нет. Но надо признать, что и со scala я их не имел.
С Котлином такой проблемы нет, если вы имеете ввиду оракловые библиотеки. Знания же стандартной библиотеки java для программирования на котлине необходимы.
Под сановскими/оракловскими библиотеками я имел в виду именно стандартные Java, почему-то синонимичны для меня эти понятия.
Если язык сделан для Java платформы, то какой бы язык не был, стандартную библиотеку придётся таки изучить
Смотря что считать «одноразовыми скриптами».
Например в scala есть удобное чтение из файла (scala.io.Source), но вот для записи в файл приходится использовать уже java.io.
Согласитесь, действие весьма базовое.

Есть, конечно, подвижки и в этом направлении, но они далеки от завершения.

Та же работа с сокетами требует погружения в мир java.

Если Вы скажете, что это не проблема, то я соглашусь. Но факт остается фактом: для работы со скалой требуются java-библиотеки.
Комментарием выше уточнил. Конечно, для программирования на Котлин необходимо знание стандартной библиотеки java, потому что полноценной своей у него нет. Но лично я не вижу в этом проблемы — стандартная библиоткеа у java неплохая, главное проверенная временем и тысячами проектов.
Дело не в том, что плохая или нет, а в том, что слабо представляю её изучение без изучения Java. Грубая аналогия: если бы для изучения Си нужно было бы знать Ассемблер — не помешает, а в некоторых случаях необходимо, но в общем — будет оверхидом.
Насколько я понимаю, котлин позиционируется именно как язык на замену java. Как язык, который можно было бы использовать вместе с java, постепенно заменять код java на код котлина.
Не уверен по поводу Kotlin — все таки преподносится как простой язык, а вот scala — это язык скорее не для тех, кто не хочет изучать java, а для тех, кому она уже неудобна.

Можно считать стандартную библиотеку java частью стандартных библиотек котлина и скалы. В таком контексте изучение котлина или скалы предполагает изучение стандартной билиотеки java.
Что можно, а скорее нужно считать, я прекрасно понимаю. Просто как-то привык, что изучая новый язык я изучаю и его стандартную библиотеку по тем же источникам. То есть претензии, если можно так выразиться, не к самим языкам, а к учебным материалам. Просто нет описания стандартной библиотеки, в лучшем случае описание особенностей и отличий её применения по сравнению с Java. Видимо действительно языки не предназначены для использования в качестве «первого языка» (JVM-based).
Ответ очевиден: с Kotlin эта проблема гораздо хуже.
Вокруг scala выросло довольно много как собственных инструментов (весь Typesafe stack, заумная, но удобная библиотека scalaz, входящий в стандартную библиотеку парсер), так и множество оберток над java-библиотеками.
Вокруг Kotlin ни чего подобного пока нет — молод еще.

С другой стороны есть и пара плюсов.
Реальный: синтаксический сахар с nullable работает уже с java-библиотеками. Плюс небольшой (в scala очень просто обернуть результат в Option, а котлин пользуется редко используемым атрибутом).
Обещаный: предполагается разработка внутри IDEA на Kotlin с выкладыванием разработанных для своих нужд библиотек в паблик. но чем они круче того же Typesafe я не знаю.
Поправка с учетом высказывания fogone:
«Если предположить. что в scala есть эта проблема, то» и дальше уже остальная часть моего комментария.
init:Node<T>.()->Unit – что в Scala, что здесь — криптографический синтаксис.
Да нет, у Kotlin-а, в отличие от Scala, достаточно простой синтаксис. Другое дело, что он кое в чём отличается от java-вского — ну так иногда неплохо вылезать из уютного мирка java и смотреть, что творится вокруг.
В заголовке написано для Java разработчиков, но на самом деле котлин пригоден и для web-разработки. В JetBrains уже сейчас на нем пишутся расширения для Firefox/Chrome в плагинах JS Debugger/LiveEdit. Иными словами — можно забыть о кошмаре JS и писать на котлине.
Java тоже пригодна для web-разработки. Согласен, котлин мог бы сильно упростить жизнь разработчикам клиентского кода. Во введении написал, что вопрос компиляции в javascript намеренно опущен, так как требует отдельной статьи.
Когда будет плагин к Eclipse плюс допилят компиляцию в JS, пересяду на Kotlin. Сейчас юзаю GWT+XTend.
Сделать новый язык совместимый с другим, для чего? Где логика? Если бы они вообще новый язык сделали, то понятно. Под ява столько библиотек! Совмещать котлин и яву? И вот теперь начинают воду мутить. Лучше бы они сделали шуструю IDE, чем изобретали велосипед! А то IDE просто тормоз (в сравнении MSVS).
Надо было этот коммент написать в 2022 на юбилей поста.
Sign up to leave a comment.

Articles