Повышение продуктивности с Kotlin

    Я недавно написал статью о нововведениях в Kotlin 1.4.20. И первый комментарий оказался немного несправедливым по отношению к Kotlin.

    Он утверждал, что зачем мол Kotlin в мобильной разработке, ведь есть Java, потому что это один из лучших языков программирования.

    И ко всем этому очень много кода Android Framework написаны на Java, а точнее больше 50%!

    Перед тем, как я поделюсь своим мнением и изложу сей рассказ, попрошу пожалуйста не бить меня стульями.

    Ну что ж, начнем со статистики!

    Что говорят профессиональные разработчики?

    Google провела небольшой опрос для тех разработчиков, которые используют Kotlin.

    Результат такой:

    67 % опрошенных профессиональных Android разработчиков, которые используют Kotlin, сказали, что он повышает их производительность!

    Данные опроса выложила Florina Muntenescu (Android Developer Advocate)

    Конечно в этот опрос входят не все, кто использует Kotlin, и вообще он не 100% точный.

    Но такие моменты имеют немалый вес и их стоит учитывать, если вы начинаете свою карьеру в мобильной разработке.

    Что говорят партнеры Google и другие компании, которые принимали участие в статистике?

    Профессиональные Android разработчики указали на некоторые весьма важные характеристики Kotlin:

    1. Краткость - меньше кода, меньше тестов и меньше времени на отладку. Такой код легче читать и поддерживать

    2. Простота - несомненно Kotlin проще Java

    Мнение одной из команд Flipkart:

    Во время внутреннего опроса 50% разработчиков отметили, что они сделали бы за меньшие сроки функционал приложения, если бы модуль был написан на Kotlin.

    Немного статистики от компании Cash App:

    Когда команда Cash App начала использовать Kotlin, они избавились от Builder паттерн и сократили кол-во кода, который им нужно было написать (в некоторых случаях они сэкономили 25% на размере кода).

    Также о краткости и лаконичности Kotlin говорят ребята из компании Zomato в этом видео

    От компании Duolingo

    Duolingo - это одна из самых популярных платформ для изучения иностранных языков и одно из наиболее загружаемых приложений в Google Play (более 100 млн. загрузок).

    В прошлом их кодовая база увеличивалась каждый код на 46% (добавление новых функций, различные обновления библиотек и т.д.). Поэтому они приняли решение переписать приложение на Kotlin.

    На это ушло порядка двух лет. Их усилия не прошли даром: несмотря на введение новых функций, они сократили свою кодовую базу до тех размеров, которые были 2 года назад!

    Внутренние опросы показали, что удовлетворенность разработчиков возрасла, что неудивительно!

    Они заметили один интересный факт: при конвертировании Java файла в Kotlin количество строк кода в среднем сокращается на 30%, а в некоторых случаях более чем на 90%!

    Kotlin функциональность и продуктивность

    В Android разработке на Java, чтобы указать необязательные параметры у конструктура вы должны сделать одно из двух:

    1) Добавить множество конструкторов

    2) Добавить Build паттерн

    В Kotlin существуют значения по умолчанию, которые делают нашу жизнь проще.

    Вот так выглядит страшный класс с использованием Builder паттерна на Java:

    public class Task {
         private final String name;
         private final Date deadline;
         private final TaskPriority priority;
         private final boolean completed;
    
         private Task(String name, Date deadline, TaskPriority priority, boolean completed) {
             this.name = name;
             this.deadline = deadline;
             this.priority = priority;
             this.completed = completed;
         }
    
         public static class Builder {
             private final String name;
             private Date deadline;
             private TaskPriority priority;
             private boolean completed;
    
             public Builder(String name) {
                 this.name = name;
             }
    
             public Builder setDeadline(Date deadline) {
                 this.deadline = deadline;
             return this;
             }
    
             public Builder setPriority(TaskPriority priority) {
                 this.priority = priority;
                 return this;
             }
    
             public Builder setCompleted(boolean completed) {
                 this.completed = completed;
                 return this;
             }
    
             public Task build() {
                 return new Task(name, deadline, priority, completed);
             }
         }
    }

    Тот же самый класс на Kotlin (с дополнительной реализацией hashCode(), equals() и некоторыми другими плюшками):

    data class Task(
         val name: String,
         val deadline: Date = DEFAULT_DEADLINE,
         val priority: TaskPriority = TaskPriority.LOW,
         val completed: Boolean = false
    )

    Это впечатляет!

    А вот ещё пример с применением паттерна Singleton на Java:

    public class Singleton{
        private static volatile Singleton INSTANCE;
        private Singleton(){}
        public static Singleton getInstance(){
            if (INSTANCE == null) {                // Single Checked
                synchronized (Singleton.class) {
                    if (INSTANCE == null) {        // Double checked
                        INSTANCE = new Singleton();
                    }
                }
            }
            return INSTANCE;
        }
        private int count = 0;
        public int count(){ return count++; }
     }

    На Kotlin:

    object Singleton {
         private var count = 0
         fun count(): Int {
             return count++
         }
     }

    Подобные вещи сильно упрощают разработку и помогают избавиться от шаблонного кода.

    Kotlin предоставляет довольно мощные средства, которые обеспечивают высокую выразительность кода, вот взгляните:

    fun borrow(){
        library -= book // используется operator overloading
        val (title, author) = book // деструктуризация data класса
        println("Borrowed $title") // шаблон строки
    }

    Помимо лаконичности и простоты, Kotlin вводит дополнительный синтаксис при работе с null ссылками:

    var str: String? = null // Разработчик, знает, 
    												// что str может ссылаться на null
            
    println(str?.length) // Обращение происходит через Safe (?) оператор
        
    val len = str?.length ?: 0 // значение 0, если str ссылается на null
    
    var listOf: List<String>? = null // может ссылаться на null
    
    listOf?.filter { it.length > 3 } // можно использовать цепочки
        	?.map { it.length }
          ?.forEach { println("Length more 3 -> $it") }

    А также в Android предусмотрены дополнительные расширения для Kotlin, которые позволяют сделать код меньше и проще, например:

    @Inject
    lateinit var viewModelFactory: MyViewModelFactory
    
    private val viewModel by viewModels<MyViewModel> { viewModelFactory }
    

    Большинство современных библиотек поддерживают Kotlin расширения, например:

    dependencies {
      	implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'
      	implementation "androidx.room:room-ktx:$room_version"
    	implementation "androidx.paging:paging-runtime-ktx:$paging_version"
    }

    Заключение

    Java довольно мощный и высокоразвитый язык, но по моему мнению, Kotlin в будущем будет использоваться более чем 95% мобильными разработчиками, а Java останется на заднем плане.

    Но это не весомый аргумент тому, что о Java можно забыть в мобильной разработке, хотя по большей части можно :)

    Даже если Kotlin заполонит весь рынок мобильной разработки, большинство компонентов Android Framework все равно написаны на Java и поэтому в редких случаях придется будет использовать Java.

    Полезные ссылки:

    1. Статья на Medium от Florina Muntenescu (Android Developer Advocate)

    2. Twitter аккаунт Florina Muntenescu

    3. Twitter аккаунт Android Developers

    4. Duolingo перешла на Kotlin

    5. Android Developers Store: Zomato использует Kotlin чтобы сделать код более безопасным и лаконичным

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 52

      +8
      Это же продуктивность, а не производительность.
      +3
      Краткость — меньше кода, меньше тестов и меньше времени на отладку. Такой код легче читать и поддерживать

      Очень полемичное утверждение. Во-первых, тесты тестируют не строчки кода, а функционал, который в обоих случаях один и тот же. Ну а насчет краткости — достаточно вспомнить Perl и его однострочники… "Пухлый" джавовский код в явном виде содержит больше промежуточных операций, которые легче читать и дебажить, нежели котлиновский лаконичный однострочник.


      Кроме того в Java для решения многих задач есть уже устаканившиеся дубовые шаблоны, которые пишутся и воспринимаются на автомате вне зависимости от того, сколько в них букв. Котлин же для решения тех же задач предоставляет сразу несколько пусть и более изящные средств, что поднимает проблему унификации и единообразия кода и затрудняет дальнейшую поддержку.


      Простота — несомненно Kotlin проще Java

      С чего это вдруг? Котлин семантически сложнее Java, и оперирует бОльшим числом концептов, это никто не будет отрицать.

        +1
        Категорически поддерживаю! Котлин сложнее и порог входа в него в разы выше. Мне вообще не нравится та «жадность» с которой в язык впихивают невпихуемое. Нельзя просто взять и добавить что-то и не повысить сложность. У меня сейчас в разработке/поддержке проекты и на Джаве и на Котлине и по временным затратам выгоднее оказывается именно Джава.
          +2

          Не соглашусь, что монструозные конструкции в джаве читаются проще. Скорее наоборот, за деревьями леса не видно. Но это только мой опыт, конечно.

            +1
            Я ожидал столь негативные ответы.

            В последнее время я заметил, что большое количество разработчиков от Google рекомендуют использовать Kotlin.

            На сайте Android Developers очень много лестных выражений по поводу Kotlin, а также рекомендации по его использованию.

            Что поделаешь, если сами Android Developers рекомендуют нам Kotlin! С ними не поспоришь!

            Даже Youtube канал Android Developers сейчас выпускает больше видео, связанных с Kotlin и его фишками.

            А на данный момент уже появилась alpha версия Jetpack Compose, которая основана на Kotlin
              +1
              «Пухлый» джавовский код в явном виде содержит больше промежуточных операций, которые легче читать и дебажить, нежели котлиновский лаконичный однострочник.


              пухлый жава код содержит массу тривиального boilerplate code, который, в общем случае, читать и вовсе не нужно, но приходится.

              С чего это вдруг? Котлин семантически сложнее Java, и оперирует бОльшим числом концептов, это никто не будет отрицать.


              Это так, но число этих концептов в момент времени все-таки ограничено, и после некоторого периода обучения они выучиваются и становятся понятной рутиной. А т.к. к-во текста меньше, читать это все быстрее и удобнее.
              0

              Я не мобильный разработчик а бэкенд, но многие агитируют за котлин.
              Из моих наблюдений


              • ИДЕА работает медленнее, чем когда код на Джаве
              • часто разработчики увлекаются ?., ?: в результате код читать очень тяжело
              • В Джаве есть Lombok и плюшки типа вот какой билдер в котлине отпадают.
              • язык не показывает свою целостность как пример:

              Решил я взять ktor чтобы слать РЕСТ запросы, но имплементацию спрятать в своем класе
              и вот такой пример кода


              suspend fun <T: Any> execute(request: MyRequest<T>): T {
                      return client.get<T>("http://google.com") {
                          header("Hello", "World")
                      }
                  }

              но получаю suspend inline fun <reified T> HttpClient.get(
              те из-за фичи что давайте мы не будет передавать явно класс, а узнаем его на этапе компиляции все ломается поскольку если я заинлайню свою функцию то получаю Public-API inline function cannot access non-public-API 'private open val client: HttpClient и чтобы ее решить мне надо делать публичным client который приватный и скрытый.


              Другая проблема — работаю я с Result<String> — здравствуй Either и все отлично получается пока не начинаешь писать юнит тесты и тебе надо замокать поведение с ошибкой внутри. И это просто невозможно сделать.

                0
                В Джаве есть Lombok и плюшки типа вот какой билдер в котлине отпадают.

                Data classes + copy(someField = newValue) ?

                  0

                  Что то можно похожее сделать с @With


                  Но как уже неоднократно замечалось, я могу придумать задание где в котлине придется написать кучу строк кода, а в джаве всего пару ломбок аннотацией.

                  0
                  Другая проблема — работаю я с Result<String> — здравствуй Either и все отлично получается пока не начинаешь писать юнит тесты и тебе надо замокать поведение с ошибкой внутри. И это просто невозможно сделать.

                  А в чем именно проблема?

                    0

                    там инлайнинг инлайнигом погоняет и вылазят то типы нее те


                    Caused by: java.lang.ClassCastException: class kotlin.Result cannot be cast to class java.lang.String (kotlin.Result is in unnamed module of loader 'app'; java.lang.String is in module java.base of loader 'bootstrap')

                    , то


                    `when`(myService.do()).thenReturn(Result.failure(RuntimeException("Boom")))
                    val result = myService.do()

                    говорит что result.isFailure = false

                      0
                      там инлайнинг инлайнигом погоняет и вылазят то типы нее те

                      Это странно. Инлайнинг как раз от такого защищает. Можете пример кода привести?


                      говорит что result.isFailure = false

                      Опять же странно. Можно полный код? myService – это ваш код? Как у вас вообще получилось в функции напрямую возвращать Result<String>? Там же будет 'kotlin.Result' cannot be used as a return type.

                        0
                        Это странно. Инлайнинг как раз от такого защищает. Можете пример кода привести?

                        там набор был из вызовов методов с Result и работой getOrThrow и подобные методы.


                        Опять же странно. Можно полный код? myService – это ваш код?

                        interface SomeService {
                                fun ok() : Result<String>
                            }
                        
                            @Test
                            fun `test result`() {
                                val m = mock(SomeService::class.java)
                                `when`(m.ok()).thenReturn(Result.failure(RuntimeException("Boom")))
                                val result = m.ok()
                                assertTrue(result.isFailure)
                            }

                        Как у вас вообще получилось в функции напрямую возвращать Result

                        добавил ключ компиляции -Xallow-result-return-type

                          0

                          Интересно. Но, строго говоря, это "недокументированная" возможность, и kotlin.Result для такого пока не предназначен, так что всё может быть. Я для таких штук использую arrow.

                            +1
                            Но, строго говоря, это "недокументированная" возможность, и kotlin.Result для такого пока не предназначен

                            я про это и говорил что язык не выглядит целостным. у нас есть runCatching конструкция и Result, но по умолчанию они кастрированы тк нельзя вернуть Result и рушится парадигма — получается тут у нас ФП внутри, а как вернуть данные то старый добрый java way с прокидыванием ексепшена. Или же можно магическим образов включить нормально Result, но вылазят опять нюансы.


                            Я для таких штук использую arrow.

                            мне понравилось что есть из коробки в Котлине Either и мне этого хватало:


                            runCatching {
                                 ... 
                                 val result = ...
                                 Result.success(result)
                            }
                              0
                              язык не выглядит целостным

                              Язык развивается. Result пока что в разработке, и, естественно, его возможности пока ограничены. Использовать его как return type пока нельзя – это явно указали и добавили compile error – но если очень хочется, то можно попробовать, но тогда нет смысла жаловаться, что что-то работает не так.


                              В одном проекте, где не было смысла тащить всю arrow, мы просто написали Result сами на sealed классах. Там меньше 100 строк кода, вместе с расширениями для Rx*.

                                +1
                                Result пока что в разработке

                                больше 2х лет как вышел. причем ладно бы он весь был помечен как нестабильный. А так вот вам все кроме возвращаемого значения — что как по мне как раз самое важное.


                                что что-то работает не так.

                                я так же пример пример для ktor который нормально нельзя использовать

                                  –2
                                  причем ладно бы он весь был помечен как нестабильный

                                  Он стабильный, просто use case очень ограничен. На данном этапе, как по мне, проще считать, что его вообще нет – его функциональность легко реализуется стандартными средствами.


                                  я так же пример пример для ktor который нормально нельзя использовать

                                  Ну это же не проблема языка, это особенность фреймворка. Вы же не станете ругать Java за то, что в Spring что-то неудобно для вас сделано?


                                  Инлайновые функции – это очень хорошая возможность для языка, в котором type erasure иначе не обойти. Создатели ktor этим воспользовались. Если вам это не нравится – язык тут как бы ни при чем.

                                    +2
                                    Ну это же не проблема языка, это особенность фреймворка.

                                    не согласен, тк инлайнинг и reified это фича языка. которая опять же выстреливает в ногу в неожиданных местах.

                                      0

                                      У меня не выстреливало, ЧЯДНТ?


                                      Это:


                                      Public-API inline function cannot access non-public-API 'private open val client: HttpClient

                                      выстрелом в ногу сложно назвать, здесь всё предельно логично.


                                      там набор был из вызовов методов с Result и работой getOrThrow и подобные методы

                                      Тут надо код смотреть, не факт, что инлайнинг виноват.

                                        +1
                                        выстрелом в ногу сложно назвать, здесь всё предельно логично.

                                        я считаю что не смочь позвать публичную функцию обьекта А, когда инстанс его приватный не есть логично.


                                        Тут надо код смотреть, не факт, что инлайнинг виноват.

                                        что значит код смотреть? он работает но просто нельзя его замокать.

                                          –1
                                          я считаю что не смочь позвать публичную функцию обьекта А, когда инстанс его приватный не есть логично.

                                          Это не просто публичная функция, это публичная inline функция. Если подумать, что означает inline, то становится очевидно, почему так сделать нельзя.


                                          что значит код смотреть? он работает но просто нельзя его замокать.

                                          С неочевидностью поведения Result (или багом?) я не спорю, мы это выше обсудили – это все скрыто за флагом компиляции и никак не гарантируется. Я здесь про то, что инлайнинг тут скорее всего не виноват.

                    +1
                    Я согласен с тем, что возможно Kotlin не идеальное решение для серверной части, но все же он преуспел во многих направлениях.

                    По моему мнению, самым подходящим направлением для Kotlin навсегда останется мобильная разработка.
                      0

                      Не согласен с тем, что мобильная разработка останется самым подходящим направлением.
                      Язык в первую очередь создавался под бэкенд разработку и лишь потом набрал большую популярность в мобильном направлении.
                      Но это не означает, что в бэкенде его мало кто использует. Есть очень много как крупных компаний, так и не очень больших у которых бэкенд либо полностью на Kotlin либо новые вещи пишутся на нем.
                      п.с. даже Яндекс сдался и снял запрет на Kotlin в бэкенд =)

                        –1

                        Для того, чтобы использовать его на бэке, надо прекратить эксперименты, постоянно ломающие обратную совместимость. Плюс разрешить все существующие проблемы интеграции, коих десятки.

                      0
                      часто разработчики увлекаются ?., ?: в результате код читать очень тяжело

                      Ну да, в java же есть магический способ не использовать?.. и получить более простой код. Да и тернарный оператор никто не использует =)
                        0

                        Про пример с inline фукнкцией… обычно в таких случаях у inline функции существует рядом обычная функция с явным параметром Class. У ktor http клиента такой, видимо, нет. Но ее можно сделать самому.
                        И тогда ваш код можно привести к виду:

                        class SomeService {
                            private val client: HttpClient = TODO()
                        
                            suspend inline fun <reified T> innerFun(): T {
                                return innerFun(T::class.java)
                            }
                        
                            suspend fun <T> innerFun(clazz: Class<T>): T {
                                return client.get(clazz)
                            }
                        }
                        
                        suspend fun <T> HttpClient.get(clazz: Class<T>): T = TODO()
                        
                        suspend inline fun <reified T> HttpClient.get(): T = get(T::class.java)

                        А класс Result на самом деле немного особенный, т.к. завязан на inline классы. С ним могут некоторые вещи не работать. Но для моков я бы попробовал будет ли работать mockk с ним.

                          +1

                          Спасибо за пример, но ведь это не отменяет, что язык просто пытается нахватать фич, а потом собрать в целостную непротиворечивую картину не получается :(

                            +1
                            но ведь это не отменяет, что язык просто пытается нахватать фич, а потом собрать в целостную непротиворечивую картину не получается

                            Не соглашусь с этим утверждением. Многие фичи языка добавлены в него для удобства разработки, например тот же inline. Но несмотря на удобство фичи есть и ограничения, да. Как, например, то, что нельзя в публичном inline методе использовать приватные функции и приватные field. Это ограничение связано с тем как реализован inline, а именно тем что содержимое функции вставляется в место вызова. И если в этом месте нельзя использовать приватные вещи из функции, то соответсвенно так делать запрещено.

                              0
                              Многие фичи языка добавлены в него для удобства разработки, например тот же inline.

                              в чем удобство разработки? Я наоборот вижу, что в результате вам пришлось написать простыню кода для использование такой функции. И везде пишется, что это для уменьшение оверхеда. Хотя по идее джавовский джит должен инлайнить и так в процессе работы.

                                0

                                Удобство в inline методе, который позволяет в местах вызова не передавать явно Class. В моем примере кода много из-за демонстрации идеи, так по сути нужен +1 метод (если опять же нужен) с явным пробросом class параметра.

                                  0

                                  ага — а потом оказывается что этот метод мы то и вызывать не можем нигде иначе течет абстракция :)

                          0

                          В 16 яве ещё будут рекорды (записи) вместо стороннего ломбока.

                          +1

                          Билдер в Java делается единственной аннотацией lombok "@Builder".


                          Singleton делается при помощи enum без этого кошмара с синхронизацией и двойной проверкой. И вообще это всем известный антипаттерн в таком виде, со статическим методом getInstance() (не то что спринговый синглтон — это другое дело).


                          Вообще, я бы различал Java до появления проекта Lombok и после. Забудьте вы уже про этот боилерплейт. К тому же, с каждым релизом Java становится всё лаконичнее и выразительнее.


                          Мой комментарий не про сравнение Kotlin с Java, а просто аргументы и примеры кода, приведенные автором, уж очень странно выглядят. Так никто уже не пишет на Java.

                            0
                            Спасибо за ваш ответ. Учту)
                              0
                              Как можно сравнивать open source 3rd party lib с языком, который официально поддерживается гуглом?
                                +1

                                А вы прочтите мой коммент до конца. Я ничего не сравниваю.

                                  0
                                  Я его внимательно прочел; выглядит как оппонирование. Я про lombok много слышал и читал, в том числе и рассуждения вида «зачем нам с ломбоком котлин»
                                  Но это ж вообще разные весовые категории — библиотека и плагин вс язык
                                    +1

                                    Да нет же, я этого вовсе не имел в виду. Я лишь указал автору на притянутые за уши некачественные примеры. И кстати вы упомянули Гугл, они-то здесь при чём вообще? Какая разница что они там поддерживают, а что нет для своей проприетарной платформы и ОС? Они и Go свой поддерживают и продвигают, однако я не видел ни одного серьёзного проекта на нём. Есть хорошие инструменты, написанные на Go, я ими пользуюсь в проде, но это не тот масштаб. Только слышу жалобы Go-девелоперов что им того и этого не хватает, а архитекторы языка их просьбы игнорят. В моём мире JavaEE от Гугла нет никакого особенного вклада, разве что Kubernetes.


                                    Кстати, об архитекторах языков. В последний раз когда я слушал Романа Елизарова в Bootiful Podcast, в гостях у Josh Long, он подробно рассказывал что с реализацией новой модели многопоточности в Котлин (на корутинах) под разные платформы есть проблемы, и между прочим, сказал что если джава Project Loom в Оракле доведут до статуса production-ready, то Котлин будет использовать именно эту реализацию, потому что она обещает быть очень крутой. Но про этот проект мы слышим уже много лет, а воз и ныне там. С тех пор новостей о каких-то прорывах не было.


                                    Да, мой любимый Spring/Boot/Cloud уже поддерживает Котлин официально, но кроме некоторого синтаксического сахара никаких специальных ништяков он не привносит.
                                    Если я не прав, прошу дать ссылки. Было бы круто переписать кое-какие вещи на корутинах, и погонять под серьёзной нагрузкой для сравнения.


                                    Вы про lombok "слышали и читали", а я его 5 лет в проде использую, еще до того как его стали официально поддерживать все IDE и фреймворки, и я не представляю без него теперь джава разработки вообще. Весь этот хлам никому не нужный наконец-то ушёл в небытие, остался чистый код, чистая бизнес логика, в меру приправленая аннотациями.


                                    Котлин очень крутая технология, позволяющая писать код один раз и использовать его и для бэка и для фронта, и даже делать бинарники (если это уже допилили). Но пока энтерпрайз разработчики сидят на джаве, и я в том числе. Зачем нам Котлин — пока не очень понятно, если честно.

                                      0
                                      И кстати вы упомянули Гугл, они-то здесь при чём вообще? Какая разница что они там поддерживают, а что нет для своей проприетарной платформы и ОС

                                      Ну, проприетарная она только частями. Кроме того, насколько я понимаю, народ использует моб. платформы гораздо больше, чем десктоп/сервера, и значительная часть мобильной платформы — это андроид (и, соответственно, гугл). Эрго, это очень массовая платформа, в том числе и для девов.

                                      если джава Project Loom в Оракле доведут до статуса production-ready, то Котлин будет использовать именно эту реализацию

                                      очень сомнительно:) После проигранного иска Ораклу, после фактически прекращенной еще лет 5 тому поддержки java на андроиде вряд ли гугл позволит котлину использовать хоть что-то от Оракла.

                                      Да, мой любимый Spring/Boot/Cloud уже поддерживает Котлин официально, но кроме некоторого синтаксического сахара никаких специальных ништяков он не привносит.

                                      А чем плох синтаксический сахар? Так-то и ломбок ничего кроме него не привносит, ограничения жава-машины не обьедешь

                                      Было бы круто переписать кое-какие вещи на корутинах, и погонять под серьёзной нагрузкой для сравнения.

                                      Я чисто mobile dev, в моей области корутины просто крайне удобная и лаконичная форма запуска background thread with closures. Ну и к корутинам уже прикручена масса функционала с LiveData и проч. (это часть идеологии, типа все д.б. асинхронным), но я только про мобильную разработку могу говорить, а там своя специфика

                                      Но пока энтерпрайз разработчики сидят на джаве, и я в том числе. Зачем нам Котлин — пока не очень понятно, если честно.

                                      Наверное. Мой ентерпрайз весь был на дотнете, так что вряд ли я смогу чем-то помочь:)

                                      Резюмируя, мои филиппики были в основном про мобильную разработку, там (на андроиде) либо жава полу-8, либо котлин. Либо с++, для мазохистов!
                                        0
                                        очень сомнительно:) После проигранного иска Ораклу, после фактически прекращенной еще лет 5 тому поддержки java на андроиде вряд ли гугл позволит котлину использовать хоть что-то от Оракла.

                                        Ну нет, конечно же всё будет open source. Оракл давно всё передал сообществу.
                                        https://openjdk.java.net/projects/loom/


                                        Резюмируя, мои филиппики были в основном про мобильную разработку, там (на андроиде) либо жава полу-8, либо котлин. Либо с++, для мазохистов!

                                        Ого, я этого не знал, печально. В таком случае вариантов действительно немного. В новейших версиях джавы очень много удобств. Например, написал List.of(), Map.of() с перечислением ключей/значений — и готово. Или к примеру одним вызовом встроенного в JDK статического метода читаешь/пишешь файлы, без всякого мусора с буферами и файл-стримами. Да вообще можно всё в функциональном стиле писать, но сначала придётся мозги немного перепрошить. Люблю джаву всё больше с каждым годом :-)

                                          0
                                          Ну нет, конечно же всё будет open source. Оракл давно всё передал сообществу.
                                          openjdk.java.net/projects/loom

                                          Ну, будем надеяться. Но мне все-таки кажется, что гугл забоится

                                          Ого, я этого не знал, печально. В таком случае вариантов действительно немного. В новейших версиях джавы очень много удобств. Например, написал List.of(), Map.of() с перечислением ключей/значений — и готово. Или к примеру одним вызовом встроенного в JDK статического метода читаешь/пишешь файлы, без всякого мусора с буферами и файл-стримами. Да вообще можно всё в функциональном стиле писать, но сначала придётся мозги немного перепрошить. Люблю джаву всё больше с каждым годом :-)


                                          котлин лучше!!!
                                          :)
                                          Там все это есть сразу из коробки
                                            0

                                            Всё, вы меня убедили! Хотя я и не спорил с самого начала :-)

                              0

                              Если бы еще в Ломбок завезли Optional для гетеров, то ему бы цены не было :)

                                0

                                Что к сожалению не случится, создатели ломбока об этом явно сказали. Хотя запрос есть и немалый.

                                  0

                                  Ага, автор уперся рогом и рассказывает какой это неправильный класс. Я почитал переписку в гите и очень удивился его позиции.

                                    0
                                    Он же адски неуклюжий, Optional этот
                                    в сравнении с?..

                                    Мы как раз с вами и спорили:))
                                    Optional.ofNullable(im.getPaths()).orElse(List.of())) вс im.paths?:listOf()
                                      0

                                      Мне роднее, map, flatMap, filter

                                        0

                                        Вопрос не в том что роднее вам. В данном случае элвис объективно лучше по читаемости и производительности.

                                          0

                                          нет — это субъективно. у меня есть Optional, Stream, Reactive Streams и везде одинаковый подход. поэтому код сmap/flatMap читается и понимается быстрее и выглядит однообразным.

                                0

                                Мне роднее, map, flatMap, filter.

                                Only users with full accounts can post comments. Log in, please.