Comments 38
Джависты атаковали мою карму. Понимаю, тяжело признавать горькую правду, однако прогресс неумолим и надо идти вперед, а не держаться за устаревшие технологии :)
Мне кажется, одна из причин атаки на карму, не наличие аргументов против, а то, что статья довольно мало приводит примеров элегантного синтаксиса Котлин. Плюс где-то позволены себе излишние эмоции, которые могут обидеть других людей.
Я бы привел примеры ? синтаксиса и let. Это по-настоящему крутые примеры работы с nullability, verbose Optional рядом не валялся.
По поводу синтаксиса is в Котлин против нового instanceof в Java, я честно говоря, не совсем пониманию какие кейсы для Java синтаксиса выигрышные. В чем смысл новой переменной, когда в Котлине существующая прекрасно справляется со своей задачей. По поводу records в Java. Котлин с 1.5 версии позволяет оптимизировать data классы с помощью аннотации JvmRecord
Плюс философия Котлина состоит как раз в том, что благодаря синтаксической базе, можно построить язык внутри язык Gradle KTS и coroutines яркие тому примеры.
Философия Явы - сделал раз, ранаем везде и всегда, к сожалению, не соответствует современным реалиям. Это ведёт к проблеме развития языка и является причиной, почему многие разработчики начинают просматривать в сторону других JVM языков.
Мои личные ощущения, что акцент развития Java сместился в сторону развития самой JVM, что напротив призывает к языковому многообразию в Java мире
Увидел вашу карму и, как раз, подумал - до статьи или после?)
Прямо сейчас хочу купить курс для андроид разработки. Подскажите пожалуйста, что лучше изучать Java или сразу Kotlin, до селе писал на 1С и Python.
Разработка преимущественно коммерческих enterprise- приложений.
вот насколько я люблю котлин (а я его очень люблю), по сути проблема синхронизации с "родительским" языком правда может наступить в любой момент. например когда в джаве допилят наконец новую модель асинхронности, в котлине на JVM их внезапно станет две. но при этом:
нельзя просто не взять из джавы новую асинхронность, так недолго и перестать быть better java, а котлину (пока) важна эта связь
нельзя взять джавовскую взамен своей - поломаешь весь старый котлин код
и в общем нельзя просто оставить сразу две - так получается два принципиально разных способа делать одно и то же (привет проблемы джавы), но при этом только на одной из платформ котлина, что ещё хуже.
понятно, что можно найти компромисс, и в каждом случае есть сдерживающие факторы которые не дадут всему взять и развалиться. но со временем различия и несоответствия будут накапливаться. это не говорит, что котлин это плохо, и давайте вернёмся на джаву - это просто проблемы которые придётся решать рано или поздно. например как раст, но возможно это и не лучший способ.
и котлин здесь не самый особенный, у тайпскрипта тут похожие проблемы хотя и менее выраженные.
Не в курсе, какая модель астнхронности сейчас в Java и Kotlin, но вроде это же частая проблема во всех языках, нет?
JS: колбэки -> промисы
C#: События, колбэки, BeginInvoke, Task
F#: всё что есть в C# + ещё свой Async
Rust: Футуры из tokio -> нативные футуры и async/await
И вроде каких-то больших проблем в этом нет - просто в определённый момент люди переходят на новый подход. А старый/альтернативный остаётся только для совместимости.
сейчас в котлине очень отдельная своя модель асинхронности через suspendable функции которая совместима со всеми promise-like фреймворками для java (включая java-8 futures). но сейчас в джаве хотят сделать какую-то свою асинхронность которая магически сделает уже написанный код асинхронным (думаю не совсем так, сам не слежу, но рекламировалось похоже).
подходы явно будут разные и нельзя так легко сказать какой круче.
возможно именно это место в итоге не создаст проблем, ну так потом что-то другое создаст.
В котлине же есть корутины — это просто языковая абстракция, позволяющая формально задекларировать асинхронные неблокирующего взаимодействия. Корутины сейчас работают как поверх собственных инструментов Котлина так и поверх CompletableFuture, Project Reactor и RxJava. С появлением Project Loom у Котлина просто появится пятый способ имплементации корутин. Более того, старый код на корутинах, если это будет выгодно, можно будет прозрачно переключить на имплементацию поверх Project Loom. Это как интерфейс и реализация интерфейса — не более того.
Rust: Футуры из tokio -> нативные футуры и async/await
Мне кажется, что в расте это как раз довольно гладко прошло из-за того, что история с асинками быстро развивалась и "смутный" период можно было просто проигнорировать. Но может это мне просто так повезло, что была возможность наблюдать период развития со стороны.
Из интервью с Елизаровым здесь же на хабре:
— Во-первых, надо понимать, что Project Loom — это библиотечная фича JVM-платформы, а не языковая. Поэтому с ней интеграция намного проще, не нужно вносить изменения в язык.
И второе, что надо понимать: хотя кажется, что Project Loom и корутины для одной бизнес-области, и оба про какое-то асинхронное программирование, цели этих проектов очень разные. И трейд-оффы в отношении производительности тоже в итоге разные.
Полностью можно прочитать по ссылке, но суть в том, что это действительно другая асинхронность, которая при этом и для других целей. https://habr.com/ru/company/jugru/blog/547138/
Kotlin не просто лучше, он страхует от старых ошибок на этапе компиляции, дает думать в другой парадигме, открыт для новых возможностей.
Очень точно. Я бы добавил что он позволяет быть разработчику быть более продуктивным. То что в джаве выглядит как проект на десяток классов и пару тысяч строк кода на котлине один файл с набором функций и классов в 100-200 строк. Прототипировать и играться с решениями куда проще. А когда есть рабочее решение можно и заняться созданием "архитектуры" из пакетов и файлов.
Вывод типов позволяет не заниматься "документированием" кода upfront, а решать проблему изменяя подходы на лету. Потом уже можно попросить IDEA вписать типы в сложных конструкциях.
Удобный Collection API и Coroutines делают сложные задачи на Java простыми.
Пишу на Kotlin с майлстоун релизов и продолжаю получать удовольствие от работы. А от работы с Java теперь одни негативные эмоции.
val x = something
val y = something.prop1
val z = something.fun2()
то для того чтобы понять типы переменных — надо возить мышкой. Так что частенько прописываешь тип даже если он не особо тут нужен — чтобы было за что глазу зацепиться.
А вот корутины это да, мне скоро Джетбрейнс стипендию назначит за то что я их нахваливаю, так что на Джаву теперь ни-ни, я за год ни одного листенера не написал и больше не собираюсь ;)
А зачем понимать типы переменных? В 99% случаев достаточно знать, что тип будет такой же, как у выражения справа от присваивания. Объем и сложность рефакторингов падает радикально. При этом на границах абстракции типы спокойно прописываются явно
На котлин легче писать, но его сложнее читать!
Это вечный трейд-офф между вербозными и лаконичными языками. Чем больше сахара тем сложнее читать незнакомому с языком человеку. Я бы скорее сформулировал по-другому: сахар котлина не приносит проблем, если ты его знаешь, а вербозность джавы не приносит проблем потому, что как сказано выше 90% времени мы думаем и только 10% времени пишем.
P.S. На хабре не принято просить карму.
P.P.S. Сколько кармы не проси пока не напишешь статью голосовать все-равно не сможешь.
Начинал с Java, сейчас перешел на Kotlin, на что ушло пару дней раскуривания и через недельку уже более-менее мог писать на котлине в обнимку с гуглом. Хотя первая неделя вызывала отторжение. А потом ничего так, привык и даже фишки понравились (работа с null-ами там все таки вещь хорошая, объявления фильдов в конструкторе и пр).
А если что, можно снова перейти на джаву.
Этот аргумент вызван плохим знанием Kotlin
Не думаю… https://www.infoq.com/articles/java-pattern-matching/
Андрей Бреслав говорил, что посмотрят на то, как сделает Java и какие проблемы встретят. И если эта фича хорошо зайдет то тоже добавят в Kotlin аналогичное решение.
полноценный паттерн матчинг
Я так понимаю, что далее по тексту, говоря «паттерн матчинг» вы имеете ввиду «полноценный паттерн матчинг» с деструктуризацией объектов и блекджеком.
Говорят, если вы не пишете компилятор — то и паттерн матчинг вам ни к чему.
Ну да, при помощи условных операторов или аналогичных конструкции в функциональном стиле можно решить большинство задач, написав кучу бойлерплейт кода.
он оказался очень мало кому нуженОчень слабый аргумент, в контексте нереализованных возможностей.
Вообще, мне все равно, добавят ли в Java и Kotlin «полноценный паттерн матчинг», просто указал на возможную ошибку в рассуждении.
Абсолютно нормальный аргумент. Если фича стоит дорого а нужна паре человек — то вполне нормально от нее отказаться.
фича стоит дорого
фича нужна паре человек
Здесь 2 аргумента, и не факт, что оба верны. По поводу первого спорить не буду, а вот второй аргумент слишком часто ошибочен или используется для манипуляции, а по сему нуждается в пруфах.
Почему Kotlin лучше Java?