Комментарии 21
Я заметил ,что одна из основных особенностей, которая сразу бросается в глаза, - это безопасность от нулевых ссылок. В Kotlin вы пишете менее подверженный ошибкам код благодаря строгой системе типов, которая обеспечивает безопасность от нулевых ссылок. Но это также означает, что в байткоде появляются дополнительные проверки null для обеспечения безопасности, что в некоторых случаях может сказаться на производительности.
Если рантайм проверки действительно сказываются на производительности какого-то конкретного кода, то можно сделать функцию приватной. Ее можно будет вызвать только из котлин кода, где компилятор просто не даст передать нулл там где не надо. Тогда рантайм проверки для параметров функции не нужны и не будут сгенерированы
Про дата-классы не согласен, в Java вполне себе есть рекорды. Про потоки тоже было странно, поскольку виртуальные появились как JEP в JDK 19, а сейчас они уже стали частью стандарта. Почему бы не сравнивать Kotlin 1.9.22-1.9.23 с Java 22?
Основная мысль текста как раз в том, что и там, и там появились одни и те же фичи. Просто в разное время. По итогу Kotlin сегодня уже в принципе отвязан от JVM, и сравнивать их напрямую особого смысла нет. Неправильно же сравнивать Python и Java только потому, что оба языка объектно-ориентированные.
Речь про то, что, появившись в нужный момент как улучшенная версия Java, Kotlin смог занять свое место под солнцем - и тогда его преимущество в функциях оказалось решающим.
Но с первого же слайда вы про фичу в Java умалчиваете и утверждаете что "в Java для тех же целей необходимо подключать внешнюю библиотеку или писать лишний код", которое ложно уже несколько лет как.
Kotlin всегда, даже в относительно старых версиях, имел эту фичу, а Java, хотя и имеет фичу в версиях начиная с 14, но в бОльшей части энтерпрайз проектов процент новых версий не близок к 100 - отчет за 2023 год дает примерно 89% проектов все еще ниже 14 версии
Тогда сравнение в пользу Джавы может получиться. Рекорды, паттернматчинг и виртуальные потоки закрывают большую часть того что продавало Котлин. Разнообразные нотнулл аннотации закрывают остаток. Вот бы еще все основные бибилиотеки ими разметили…
Да не то только null protection фишка котлина. Функциональное программирование в котлин в разы удобнее. Эти collection.stream()…..collect(…) в java просто ужас какой многословный по сравнению с collection.map{…} А если взять функции-расширения, перегрузка операторов, всякие делегаты с синглтонами, то и получается, что джаве еще далеко до удобства котлина. Сам пишу по работе на обоих языках примерно 50/50, не хейтю джаву, но такое вот субъективное мнение
У меня вопрос к опытным разработчикам: цель стать разработчиком на Kotlin, надо сначала хорошо изучить Java или можно сразу браться за KT ?
Думаю, если есть практика владения другим объектно-ориентированным языком, то можно начать сразу с Kotlin; если же такой практики нет, то, возможно, лучше начать погружаться с Java
Если цель - стать разработчиком на Котлин, то изучать Java совершенно необязательно. Если будете писать под jvm-таргет, лучше просто изучить отдельно именно особенности jvm.
Я бы выучил джаву. Взаимодействовать, скорее всего, придется. Ну там полазить в кишках библиотек и т.д. А идеоматически Котлин все дальше и дальше от Джавы в плане стиля кода. Я раньше иногда понять не мог на каком языке написан код - на джаве или котлине. Сейчас, если писать в стиле Котлин, как-то уже и совсем не Джава стиль получается.
Сравните пожалуйста с последней версией Java. С рекордами в частности. Какой бойлерплейт?
Второе - не понятен смысл маски в конструкции со значением по умолчанию. Код может быть простейший
private static class cl {
private final int DEFAULT_X = 42;
private void foo(int x) {
System.out.println(x);
}
private void foo() {
foo(DEFAULT_X);
}
}Вообще, по опыту работы с Delphi, ничего хорошего в указании значений параметров по умолчанию в объявлении методов нет. Это протаскивание деталей реализации в объявление. Это раз. Второе (я не в курсе) - как эти параметры по умолчанию стыкуются с интерфейсами? Объявление методов должно быть ТОЧНО соответствовать объявлениям интерфейсов - в этом смысл интерфейсов. А в разных классах в объявлениях одних и тех-же методов могут быть разные константы. Это нарушение идеологии интерфейсов. В третьих, это просто путаница, когда в одних случаях нужно использовать параметры по умолчанию и свои параметры, а в других случаях - другие параметры по умолчанию и свои параметры. Это невозможно разрулить, когда параметров штук пять-десять. Java с помощью библиотек предлагает изящное решение - билдеры (правда надо определять класс параметров).
С интерфейсами все там стыкуется, если речь о Делфи. Для интерфейса такой метод - это метод с набором всех параметров и не важно, что какие-то заданы по умолчанию.
Параметры по умолчанию достаточно редко используются, но это все равно удобно.
Кстати, в Делфи в конструкторе я часто использую вариант такой:
constructor TMyObject.Create(Proc<TMyObject>);
begin
inherited Create;
Proc(Self);
end;
// и при вызове
var Obj := TMyObject.Create(
procedure(MyObj: TMyObject)
begin
MyObj.Prop1 := 1;
end)Во-первых, В Java и Kotlin интерфейсы необязательны. В Kotlin даже классы необязательны (хотя в байткоде обернутся все же в классы функции и переменный объявленые вне классов). Поэтому метод с параметрами необязательно должен стыковаться с каким-то там интерфейсом. Даже если у класса, в котором объявлен метода с параметрами по умолчанию, есть интерфейс - ну и ладно. Я лично так делал и не страдал от нарушения идеологий. Да и не понимаю я, в чем нарушение? Интерфейс - это контракт на структуру и результат, а не на данные или способ подкапотного функционирования этой структуры. Данные как раз предполагаются быть разными в имплементациях, раз уж интерфейс объявлен.
Во-вторых, это плохо иметь 10 параметров в методе. И в Котлине для таких случаев тоже надо использовать билдеры, хоть самому писать, хоть с использованием тех же библиотек из Джавы
Не писать билдеры - это была одна из причин возникновения для дефолтных параметров.
Интерфейсы с дефолтными параметрами сочетаются замечательно - они разрешены для интерфейса, но не для имплементации.
Kotlin (не) против Java: особенности компиляции в байткод