Вы все еще кодите на Java? Пора измениться

    image

    Я очень долго не хотел смотреть в сторону Котлина. Но вот когда я листал список вакансий я стал все чаще замечать графу: Плюсом также будет знание Kotlin. И как-то вечерком увидел вот эту статью на хабре: 8 учебных проектов. Мне там приглянулся трекер криптовалют. Но как-то было слишком просто: обыкновенный Get-запрос, совсем не интересно. И здесь я решил попробовать написать все это на Kotlin. Трекер криптовалют стал тренировочным полигоном для изучения Котлина. После создания этой приложухи было вынесено несколько важных уроков.

    Всем кому интересно прошу под кат.

    Кратко обо мне


    Когда я начал это все делать то у меня была масса предубеждений насчет этого языка. Что он не удобный, что он не красивый, что он плохой, и тормознутый. Это все было из-за того что я не хотел выходить из своей зоны комфорта. Я знаю Джаву она хорошая, и вообще зачем что-то менять пускай все будет как есть, зачем напрягаться. Но интерес взял свое. И могу сказать что я был очень не прав.

    Что же такого особенного в Котлине чего нет в Java?

    1. Отсутсвие точек с запятыми


    Это бросилось в глаза с самого начала. Их отсутствие показалось просто приятным бонусом, хотя рука все равно дергалась :). Но наличие/отсутсвие такой мелочи вовсе не повод любить/ненавидеть язык (хотя когда у тебя тысячи строк кода уже вроде и не мелочь).

    2. Биндинг вьюшек


    Как только я закончил клепать макеты появился вопрос о том как биндить вьюхи. Я полез гуглить:«Butterknife kotlin». Вот тут-то я и поплыл. Оказалось что использовать ButterKnife в Котлине просто нет смысла. Нужно просто брать и юзать вьюшки, при этом не имея ни малейшего риска получить NPE.

    Если написать код на Джаве получим это
    public class MainActivity {
       private TextView textView; //1-ая строка
     
       @Override
       protected void onCreate(final Bundle savedInstanceState) {
           super.onCreate(savedInstanceState);
           setContentView(R.layout.activity_main);
           textView = findViewById(R.id.textView);//2-ая строка
           textView.setText("Hello world!");//3-я строка
        }
    }


    А теперь напишем с ButterKnife
    public class MainActivity...{
    
       @BindView(R.id.textView)TextView textView; //1-ая строка
    
       @Override
       protected void onCreate(final Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);
          ButterKnife.bind(this);//2-ая строка
          textView.setText("Hello world!");//3-я строка
       }
    }


    А теперь Котлин
    class MainActivity: AppCompatActivity() {
        override fun onCreate(savedInstanceState: Bundle?) {
            super.onCreate(savedInstanceState)
            setContentView(R.layout.activity_main)
            textView.text = "Hello world!"//1-ая и последняя строка
        }
    }


    3. Отсутсвие NPE


    NPE — это легенда в мире программирования. И в Котлине его просто нет еще до компиляции возможные места возникновения NullPointerException считаются синтаксической ошибкой. Вас просто заставляют сделать проверку на null.

    4. Код на порядок короче


    По статистике код в Котлине на 40% короче, и в этом легко убедится. Для того чтобы парсить ответ нужно было сделать модели. Никогда не думал что модель со столькими полями может быть такой короткой.

    Красивая и коротенькая модель в Котлине
    data class ResponseItem(@SerializedName("id")
                            @Expose var id: String?, 
                            @SerializedName("name")
                            @Expose var name: String?, 
                            @SerializedName("symbol")
                            @Expose var symbol: String?, 
                            @SerializedName("rank")
                            @Expose var rank: String?, 
                            @SerializedName("price_usd")
                            @Expose var priceUsd: String?, 
                            @SerializedName("price_btc")
                            @Expose var priceBtc: String?, 
                            @SerializedName("24h_volume_usd")
                            @Expose var _24hVolumeUsd: String?, 
                            @SerializedName("market_cap_usd")
                            @Expose var marketCapUsd: String?, 
                            @SerializedName("available_supply")
                            @Expose var availableSupply: String?, 
                            @SerializedName("total_supply")
                            @Expose var totalSupply: String?, 
                            @SerializedName("max_supply")
                            @Expose var maxSupply: String?, 
                            @SerializedName("percent_change_1h")
                            @Expose var percentChange1h: String?,
                            @SerializedName("percent_change_24h")
                            @Expose var percentChange24h: String?,
                            @SerializedName("percent_change_7d")
                            @Expose var percentChange7d: String?, 
                            @SerializedName("last_updated")
                            @Expose var lastUpdated: String?) 

    На самом деле код короче, потому что 2 аннотации(expose и serialized) в одну строку.

    Тот же класс в Джаве. Аккуратно море кода!
    @SerializedName("id")
        @Expose
        private String id;
        @SerializedName("name")
        @Expose
        private String name;
        @SerializedName("symbol")
        @Expose
        private String symbol;
        @SerializedName("rank")
        @Expose
        private String rank;
        @SerializedName("price_usd")
        @Expose
        private String priceUsd;
        @SerializedName("price_btc")
        @Expose
        private String priceBtc;
        @SerializedName("24h_volume_usd")
        @Expose
        private String _24hVolumeUsd;
        @SerializedName("market_cap_usd")
        @Expose
        private String marketCapUsd;
        @SerializedName("available_supply")
        @Expose
        private String availableSupply;
        @SerializedName("total_supply")
        @Expose
        private String totalSupply;
        @SerializedName("max_supply")
        @Expose
        private Object maxSupply;
        @SerializedName("percent_change_1h")
        @Expose
        private String percentChange1h;
        @SerializedName("percent_change_24h")
        @Expose
        private String percentChange24h;
        @SerializedName("percent_change_7d")
        @Expose
        private String percentChange7d;
        @SerializedName("last_updated")
        @Expose
        private String lastUpdated;
    
        public String getId() {
            return id;
        }
    
        public void setId(String id) {
            this.id = id;
        }
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    
        public String getSymbol() {
            return symbol;
        }
    
        public void setSymbol(String symbol) {
            this.symbol = symbol;
        }
    
        public String getRank() {
            return rank;
        }
    
        public void setRank(String rank) {
            this.rank = rank;
        }
    
        public String getPriceUsd() {
            return priceUsd;
        }
    
        public void setPriceUsd(String priceUsd) {
            this.priceUsd = priceUsd;
        }
    
        public String getPriceBtc() {
            return priceBtc;
        }
    
        public void setPriceBtc(String priceBtc) {
            this.priceBtc = priceBtc;
        }
    
        public String get24hVolumeUsd() {
            return _24hVolumeUsd;
        }
    
        public void set24hVolumeUsd(String _24hVolumeUsd) {
            this._24hVolumeUsd = _24hVolumeUsd;
        }
    
        public String getMarketCapUsd() {
            return marketCapUsd;
        }
    
        public void setMarketCapUsd(String marketCapUsd) {
            this.marketCapUsd = marketCapUsd;
        }
    
        public String getAvailableSupply() {
            return availableSupply;
        }
    
        public void setAvailableSupply(String availableSupply) {
            this.availableSupply = availableSupply;
        }
    
        public String getTotalSupply() {
            return totalSupply;
        }
    
        public void setTotalSupply(String totalSupply) {
            this.totalSupply = totalSupply;
        }
    
        public Object getMaxSupply() {
            return maxSupply;
        }
    
        public void setMaxSupply(Object maxSupply) {
            this.maxSupply = maxSupply;
        }
    
        public String getPercentChange1h() {
            return percentChange1h;
        }
    
        public void setPercentChange1h(String percentChange1h) {
            this.percentChange1h = percentChange1h;
        }
    
        public String getPercentChange24h() {
            return percentChange24h;
        }
    
        public void setPercentChange24h(String percentChange24h) {
            this.percentChange24h = percentChange24h;
        }
    
        public String getPercentChange7d() {
            return percentChange7d;
        }
    
        public void setPercentChange7d(String percentChange7d) {
            this.percentChange7d = percentChange7d;
        }
    
        public String getLastUpdated() {
            return lastUpdated;
        }
    
        public void setLastUpdated(String lastUpdated) {
            this.lastUpdated = lastUpdated;
        }
    


    Ну что, вам листать не надоело?

    Мне кажется разница на лицо. Скажете: ну это модели, с ними такое бывает. Когда я писал адаптер для RecylerView он был длиной всего в 50 строк. Такой же адаптер на джаве занял бы 80 — 90 строк.

    5. Нет Getter'ов и Setter'ов


    Это одна из главных причин по которой модели в Котлине такие короткие. Для того чтобы поменять значение переменной достаточно просто сделать:

    someModel.name = "new name"

    В Джаве для того же результата нужно объявить сеттеры, и только потом к ним обращаться. А один сеттер занимает 3 строки кода. И как вы видели в предидущем примере эта разница существенна.

    Заключение


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

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

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

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 106
    • +1

      Справедливости ради, стоит заметить, что в Java сеттеры и геттеры не обязательны. А в этом конкретном случае с ResponseItem от них не так уж много пользы.
      Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.

      • –5
        Тут вы безусловно правы. Но как я сказал ранее: адаптер на Джаве занял 80-90 строк, в то время как на котлине только 50
        • 0

          А зачем там одновременно аннотации @Expose и @SerializedName("...")? Они не конфликтуют?

          • 0
            Да нет все ок. Просто pojo генератор так сгенерил, вот и все.
        • +2
          Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.

          Завит от того, зачем нужны только лишь геттеры. Если для создания неизменяемой модели, то у Kotlin есть val:
          class ImmutableModel(val foo: String, val bar: String = "Опциональные аргументы, Java!")
          

          Если же нужно поместить какую-то логику в геттер, то можно так:
          val foo: String
                  get() = TODO("Implement getter")
          
          • +1
            Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.

            Вот так описывается поле с геттером


            val a = ""
            • –1
              А что с ситуацией когда одному только почитать, а другому еще и пописать? Два интерфейса?
            • +2
              Стоит отметить что data классы содержат реализации методов equals, hashcode, toString и componentN (для расщепления классов), так что на java ваш класс был бы еще больше. Что важно эти методы реализованы разумно, и разработчики языка учли множество подводных камней при их реализации.
            • +28
              Я дико извиняюсь, что сейчас достанется именно вашему посту, но он стал последней каплей в чашу моего терпения, касательно некоторого множества статей с определенной структурой.

              Все написанное ниже является сугубо моим мнением.

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

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

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

              *Ваш пример с моделью, и тем, что она короче и читается лучше.*

              Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.

              Если же мы говорим:

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

              Эту формулировку можно спокойно заменить на:
              «Мне понравился Kotlin, потому что:»
              «Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»

              В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.

              P.S.
              Я вот думаю, статью на эту тему написать, что ли.
              • –14
                Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно, ведь объем будет слишком большим, и вечерком сесть и налегке почитать не выйдет. Я уверен что и у Джавы найдется хоть один плюс по сравнению с Котлином, ничто не идеально. Но как мы выбираем что есть лучше? Мы создаем критерии по которым сравниваем два объекта. Какие-то критерии более важны, какие-то менее, другие просто критичны. В результате мы просто подсчитываем балы и тот у кого их больше и будет лучше, так работает наш мозг, потому что ничто в нашем мире не идеально.

                Давайте затронем другую животрепещущую тему: что лучше мак ос или винда. Мак быстрее, с малым количеством вирусов и уязвимостей, более стабилен. Но из недостатков то что нужно купить дорогое железо от apple, в то время винда есть и на более дешевых вариантах. Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.
                • +1
                  Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно


                  А вот тут вы не правы. Для развлекательного чтива под чай с булочкой возможно. А когда стоит выбор в какой язык упарываться рогом тратить сотни часов на обучение, то максимально субъективное чтиво, пусть и кратко-тезисное в самый раз.
                  • +3
                    «Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.»
                    «Не все так однозначно»(С) Ибо вам придется платить за лицензию винды, бюджетным вариантом будет компьютер с Линуксом
                    • +3
                      А давайте лучше научный трактат?) О том, чем Java лучше Kotlin?
                      Прям любопытно будет прочитать и сравнить.
                      • +5
                        Мне кажется, что вы неверно поняли посыл моего комментария.

                        Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.

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

                        Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.

                        Если коротко:
                        Вы обращаете внимание читателя на возросшую популярность языка.
                        Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
                        Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
                        Делаете заключение.

                        И, все бы было хорошо, если бы не маленькая ошибка:
                        В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
                        И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.

                        А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.
                        • –4
                          Я не толкаю мысль что Котлин полезнее Джавы, я толкаю мысль — что во многих аспектах он превосходит Джаву. Статья была предназначена для людей у которых был опыт разработки на Java. В комментах уже было упомянуто что документации в Android SDK на Котлине гораздо меньше, и человеку который вообще ничего не знает в андроиде разобраться с ним будет как минимум проблемно. Поэтому нельзя так просто взять и начать кодить на Котлине. Это как: «кодить нужно начинать на Pascal он изи, и только так можно выучить алгоритмы». Котлин сейчас еще слишком молод чтобы знать только его и ничего больше.
                      • +4
                        ибо если хоть в одном случае окажется, что Java лучше Kotlin

                        я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.


                        то утверждение неверно.

                        не стоит мыслить абсолютами. Если в 9 из 10-ти ситуаций kotlin лучше — то он лучше java. Это работает по сравнению плюсов и минусов. Так же у разных кейсов есть разный приоритет. К примеру null-safety — жирный плюс, с которым сложно считаться. Если какую-то редкую задачу проще решить на java (что сомнительно), то приоритет этого явно ниже. Ну думаю вы поняли идею.

                        • +3
                          What Java has that Kotlin does not:
                          Checked exceptions
                          Primitive types that are not classes
                          Static members
                          Non-private fields
                          Wildcard-types

                          Важно ли это — не думаю
                          • +2

                            По приведенной вами ссылке можно перейти по каждому пункту и выяснить почему это отсутствует. Там и мотивация почему так, и какая альтернатива… возможностей у вас меньше не стало, да и не забывайте что у Kotlin должна быть совместимость c Java так что в целом отсутствие чего-то не означает что вы не можете чего-то сделать.


                            В целом я считаю что отсутствие перечисленного это плюс. Ну и сравнивать таким образом языки слишком примитивно.

                          • –10
                            Пожалуй стоит начать с того что Котлин это следующее поколение, а как известно следующее поколение всегда превосходит предидущее, он создан на основе Джавы, с учетом всего крутого и всех косяков, и действительно тяжело найти кейс где Джава впереди
                            • +2
                              я бы сказал так: котлин — это джава, какой она должна была бы быть. Котлин перенял многие вкусности из других языков, в то время как джава очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.
                              И кто знает, не поспешил ли котлин в погоне за модой и не ждет ли его та же печальная судьба?
                              • +3
                                очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.

                                тут на самом деле все очень просто. Для того что бы эволюционировать — нужны эксперименты. Kotlin, Scala и некоторые другие JVM языки являются своего рода экспериментами. Определенные идеи могут спокойно перетечь в java, подтолкнуть его развитие.


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

                          • 0

                            Да вы что, это же не buzzword-oriented подход!

                          • +4
                            Опрос:
                            *Java, эти аргументы неубедительны
                            *перейду на Kotlin прям сегодня
                            *я уже давно на Котлине
                            *Возможно начну кодить на Котлине через месяц другой

                            Жизни за МКАДом не существует? =)
                            • +1

                              У нас в городе ровно одна вакансия по Kotlin, и 162 вакансии о Java.
                              Так что я сейчас собираюсь учить именно Java. Потому что, увы, практически исчезли чистые вакансии по PL/SQL, и в основном требуют PL/SQL + Java.


                              PS посмотрел Москву: 77 вакансий по Kotlin, против 1770 по Java и 1116 по C#.

                              • –2
                                Я не говорил про вакансии чисто по Котлин. Откройте вакансии по андроид разработке. В скиллах будет написано обязательное знание Джавы, а ниже почти в каждой пятой вакансии будет написано: будет круто если вы еще знаете Котлин.

                                Раньше такого было намного меньше, а сейчас таких вакансий все больше с каждым днем. Становится очевидным что Котлин набирает популярность. Это как Свифт на ios. Был Objective C вроде нормальный язык, но появился новый Swift, и через какие-то пару лет он уже отъел половину рынка. Не исключено что скоро это повторится и с андроидом.
                                • 0

                                  hh — не показывает вакансии "чисто по Котлин", он показывает ВСЕ вакансии в которых это слово упоминается, а их в Москве 77 вакансий.

                                  • 0

                                    Swift полностью поддерживается Apple, включая документацию, обучающие материалы и примеры. А насколько Google поддерживает Kotlin, кроме возможности создания на нём проектов в Android Studio?

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

                                      На текущий момент комьюнити Котлина по численности сильно уступает комьюнити Jav
                                      • +2
                                        Документации на Котлин действительно немного

                                        Документация по Котлину исчерпывающая, на сайте производителя. В слак каналах поддержка осуществляется самими разработчиками. На текущий момент 13447 пользователей, комьюнити очень дружелюбное и помощь поступает незамедлительно.
                                        • 0

                                          Не просто по Kotlin надо, а по Android SDK. И официальную документацию, а не Hello World-ы на коленке.

                                          • 0
                                            Начнем с того что в Котлине можно использовать Джава классы и поэтому вполне можно использовать документацию Джавы, и не будет никаких проблем.

                                            Честно говоря когда я делал трекер мне требовалась документация на уровне синтаксиса, а части которые относились к Android SDK я писал по аналогии с Java, и при этом не возникало никаких проблем
                                            • +1
                                              писал по аналогии с Java

                                              Современный вариант классического "программист на Фортране, способен на любом языке писать на Фортране"?

                                              • 0

                                                Переводить с Java на Kotlin? Очень "удобно".

                                          • +1
                                            настолько, что Google нанял Джейка Вортона работать над поддержкой Котлин.
                                            Один из первых результатов его работы — Kotlin code style
                                            • +1

                                              А это кто?

                                              • 0
                                                О мой Бог, вы не знаете кто этот Великий Человек? Он ведущий разработчик в Square, и он подарил миру столько прекрасного и упрощающего рутину обычному программисту: Retrofit(создание запроса с минимальным количеством кода), ButterKnife(упрощение биндинга вьюшек до нельзя, всего одна строка кода на каждую вьюшку, вместо двух с findViewById), приложил руку к Dagger(улучшает тестируемость кода), и это далеко не весь список. Поэтому любой андроидщик хоть раз в жизни юзал творения над которыми он работал. Вот за это он один из самых известных и уважаемых людей в мире андроид разработки.
                                    • 0
                                      я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.


                                      секвенсес не могут в параллелизм
                                      стримапи может в параллелизм
                                      но это с точки зрения сахара
                                      • –3
                                        Картинка то какая. Телефон на Java убитый и заляпанный, а на Kotlin сияющий и блестящий. Какой-то дотнетщиной пахнуло =)
                                        • +4
                                          Нету Getter'ов и Setter'ов

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


                                          Единственный стоящий аргумент — про более короткий код, но пример к нему ужасен.


                                          Почему бы не рассказать про автовывод типов, extension методы и прочие приятные штуки?

                                          • 0
                                            Почему бы не рассказать про автовывод типов, extension методы и прочие приятные штуки?

                                            Про это уже только ленивый не писал)
                                            • +2
                                              Дак и про то, что код на kotlin короче кода на java написано куча статей, это ведь не помешало автору еще раз это продублировать
                                            • –1
                                              Ладно, они реально есть, но фишка в том что они уже зашиты в сам язык, и не нужно объявлять их в коде.
                                            • +2
                                              Kotlin это когда хочешь писать на C# с JVM.
                                              • +2
                                                Давно простится статья «Kotlin vs C#». Сам ушел с C# на Kotlin, много плюшек есть в обоих языках (может потому что Бреслав работал в MS, до работы на JetBrains), но в котлине, на мой взгляд, все более удобно, те же екстеншены.
                                                • +1
                                                  Давно простится статья «Kotlin vs C#»

                                                  а напишите, будет интересно.
                                                  • +1
                                                    Уже начал, к сожалению не много свободного времени.
                                                  • 0
                                                    из команды Котлин Илья Рыженков ранее работал над Resharper — тоже без влияния C# не обошлось
                                                • +3
                                                  NPE — это легенда в мире программирования. И в Котлине его просто нету еще до компиляции возможные места возникновения NullPointerException считаются синтаксической ошибкой. Вас просто заставляют сделать проверку на null.

                                                  Вот тут Вы слукавили, замечательно прилетает с джавы.
                                                  • 0
                                                    Речь не о джаве, а о том, что дизайн языка запрещает неявный null — либо мы явно используем billable (в джаве все по умолчанию) типы, либо нас заставляют описывать какой-то dummy объект вместо null. Ситуация схожая с проверяемыми исключениями в джаве — либо обработай, либо явно выбрось наверх.
                                                    Другой вопрос, хорошо ли это (т.к. почти во всех статьях восхваляют данную фишку). Возможно, пусть прога лучше со свистом грохнется и покажет стектрейс, с исправлением ошибки за минуту, чем прога будет работать, но работать неправильно и хрен ты эту логическую ошибку найдешь.
                                                    • 0
                                                      Я про то, что NPE на рантайме, и в котлине поймать можно.
                                                      • 0
                                                        О том и речь — конечно, как явление, NPE в котлин существует, но случайно написать код, который его производит, уже чуть сложнее
                                                        • +1
                                                          Суть в том что его поймать тяжело. Конечно если сильно постаратся то и дьявола можно призвать. В Джаве вы можете просто забыть прописать проверку на null и у вас все крешнится. А Котлин заставит вас сделать проверку на null иначе он просто откажется компилироваться.
                                                    • 0
                                                      Я про то, что NPE на рантайме, и в котлине поймать можно.
                                                      • +3
                                                        Типичный статья фаната Котлина который даже не знает о всех его преимуществах и думает что его сила только в украшательствах и сокращении кода. Крайне печально.
                                                        • +1
                                                          Может Вы подскажете в чем сила?
                                                          • 0

                                                            Таких статей бесчетное количество. Например https://academy.realm.io/posts/oredev-jake-wharton-kotlin-advancing-android-dev/

                                                            • –1
                                                              Я описал то что реально меня очень впечатлило и чего я реально не ожидал. Если бы я описывал все его фичи, то статья б началась и закончилась ссылкой на документацию по Котлину :). А так я лишь делился своими ощущениями и впечатлениями.
                                                        • +3
                                                          4. Код на порядок короче

                                                          Слышали про Lombok? С ним ваш пример на Java приблизится к Котлину
                                                          3. Отсутсвие NPE

                                                          Лукавство. Есть механизмы по его предотвращению, но сам по себе NPE есть и никуда не делася
                                                          1. Отсутсвие точек с запятыми

                                                          Тут я сдаюсь и перехожу на Котлин )

                                                          Если серьезно, то почему бы не написать про действительно интересные вещи типа корутин, extension, легкости написания dsl и т.д.?
                                                          • 0
                                                            Если серьезно, то почему бы не написать про действительно интересные вещи типа корутин, extension, легкости написания dsl и т.д.?

                                                            Про корутины, это да, а про все остальное тут полно всего.
                                                            • –1
                                                              Lombok — это круто, но это сторонняя библиотека, а здесь уже все зашито в сам язык
                                                            • +1
                                                              Вот когда хайп уляжется и статьи про поней какающих радугами сойдут на нет, тогда посмотрим.
                                                              • –1
                                                                1. Отсутсвие точек с запятыми

                                                                Мне Котлин напомнил VB этим пунктом. Со многострочными конструкциями снова будут прыжки с бубном и обратными слешами? И конструкция a?.b?.c?.d() подозрительно напоминает On Error Resume Next, создающий массу неопределенного поведения.
                                                                В целом сама идея Котлина годная, но многие вещи очень спорны пока что.
                                                                • +1
                                                                  import lombok.Data;

                                                                  Data
                                                                  public class User {

                                                                  private String firstName;
                                                                  private String lastName;
                                                                  }
                                                                  • +5
                                                                    Хватит рекламить этот котлин! Такое чувство что JetBrains проплачивает такого рода посты. Я лично за Скалу, зачем вообще он был нужен, когда скала на момент создания уже была?
                                                                    • 0
                                                                      Ну Скалу все равно считают довольно сложным языком, да он легче чем тот же Си, но все же…

                                                                      Честно говоря еще неделю назад я тоже думал что в нем нету ничего такого. Но виной был страх что-то менять и было немного лень напрягаться.
                                                                      • +1
                                                                        А в чём выражается сложность Скалы? Синтаксис? Стандартная библиотека? Фреймворки? Тулзы для работы?
                                                                        • 0

                                                                          Да ни в чём.


                                                                          Синтаксис простой (на мой взгляд проще, чем в котлин).


                                                                          • В котлине есть специальный синтаксис для определния геттеров-сеттеров, в скале это просто методы типа def x =..., def x_=(...)
                                                                          • В котлине инлайн-функции втащены на уровень языка. Всё бы ничего, но в некоторых случаях это влияет на возможность использовать слово return.
                                                                          • В котлине есть более сложные типы (например, IntArray.() -> Unit). Впрочем., в скале есть path-dependent types, которые используются очень редко и отсутствуют в котлине. Синтаксис: objectName.TypeName
                                                                          • В котлине есть nullable типы. В скале это решено с помощью класса Option из стандартной библиотеки.
                                                                          • В котлине, чтобы определить оператор +, надо написать operator fun plus(...), в скале достаточно def +(...) и это самый обычный метод.
                                                                          • В котлин можно переопределить только несколько операторов, в скале — почти всё, что захочется, хоть ||, хоть !!!
                                                                          • В котлине методы в одну строчку принято определять как fun a() = ..., в несколько строчек fun a(){...} В скале принят только первый вариант.
                                                                          • Обращение к элементу массива и вызов функции — в котлин разные сущности, в скале и то и другое — круглые скобочки, массив являетя функцией Int=>T.
                                                                          • В котлин есть extension методы. В скале вместо это используются implicit преобразования, которые дают на порядки больше возможностей (С точки зрения скалы преобразование типа Int -> Long является неявным)

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


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


                                                                          Фреймворки — там могут очень много навертеть, используя систему типов на полную катушку. Вряд ли это недостаток языка.


                                                                          Про тулзы — не знаю что сказать.

                                                                          • –1
                                                                            В котлин можно переопределить только несколько операторов, в скале — почти всё, что захочется, хоть ||, хоть !!!

                                                                            А зачем?
                                                                      • +5
                                                                        Со стороны JetBrains, создание своего языка — очень годный ход. Это определенная сфера влияния в бизнесе, которая напрямую ведет к обогащению. Я же не думаю, что есть люди, которые верят в утверждение «мы создали его, чтобы вам было удобнее»? Тот же Oracle, не «так просто» скупает платформы, языки и системы.
                                                                        • –1
                                                                          JetBrains сделали Котлин в первую очередь для себя. Они активно юзают его внутри компании
                                                                          • +2
                                                                            Даже в интервью директора была фраза, что сделав язык, они получат влияние.
                                                                            • +2
                                                                              Настолько «для себя» что этот котлин форсится так неистово, что даже не хочется к нему прикасаться.

                                                                              На каждом втором русскоязычном бложеке по триста статей уровня «почему котлин в триллион раз лучше жавы, начинайте писать уже сейчас!!1», кликбейты про «новый основной язык разработки под ведроид» и просто откровенная реклама.

                                                                              Когда тебе так настойчиво запихивают в рот какую-то «вкусняшку», непроизвольно возникает тошнота.
                                                                              • 0

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

                                                                                • +1
                                                                                  Не только.

                                                                                  Реклама может содержать описание качеств продукта и оставлять пользователю выбор использовать его или нет — если продукт хороший пользователь сам придет к «продавцу». Если бы во всех этих статьях было бы только описание особенностей языка и то какие проблемы он решает — я бы наверняка попробовал на нем писать. Это была бы хорошая реклама которая уважает пользователя.

                                                                                  Есть другая реклама — полные императивных посылов крики «покупай, пользуйся, делай!!11» без единых описаний почему я должен пользоваться чем-то. Это реклама стиральных порошков, бытовых товаров и прочьего ширпотрепа — попытка перекричать голос разума яркими метафорами и безудержным восхвалением. Вот такая реклама у котлина и такая реклама вызывает только тошноту, потому что авторы считают идиотом неспособным к критическому мышлению которого нужно подтолкнуть в сторону «правильного» продукта.
                                                                          • +1
                                                                            используя скалу тебе надо тащить весь язык со всеми его библиотеками. Котлин работает поверх Java, коллекции Котлин — это обычные коллекции из Java, например, и потому размер его стандартной библиотеки значительно меньше. Для Андроид, в частности, это очень важно
                                                                            • 0
                                                                              Я не андроид разработчик, но всетаки поинтересуюсь:
                                                                              Котлин работает поверх Java
                                                                              Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM потом интерпретируется ведроид компилятором под DVM. Не очень понял что вы имеете ввиду?
                                                                              тащить весь язык со всеми его библиотеками
                                                                              Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?
                                                                              • –4
                                                                                Да, он работает поверх Джавы. Поэтому в Котлине можно юзать все что написано на Джаве. Еще он может компилиться в байт-код javascript
                                                                                • 0
                                                                                  работает поверх Джавы

                                                                                  Что вы все заладили, что в вашем понимании это означает? Я то думал это предусмотренная компилятором обратная совместимость с Java, в Scala тоже самое, потому что котлин это попытка JetBrains написать свою скалу, и что то мне подсказывает что писали они ее не с 0.
                                                                                  байт-код javascript
                                                                                  Что простите? (facepalm) В какой из множества вариаций javascript — bytecode, или они заставили все браузеры перейти на оди и тот же компилятор?
                                                                                  Складывается впечатление что у людей напрочь отсутствует понимание, того как работают языки вне красивых кнопочек и подсветок в их IDE…
                                                                                  • –2
                                                                                    Честно говоря я это не проверял но в документации читал что он может компилиться в javaScript
                                                                                    • +1
                                                                                      Да может, но не в javaScript Bytecode, У Scala тоже есть интерпритатор в js. ScalaJS называется вроде.
                                                                                      • –2
                                                                                        Спасибо, что разъяснили.
                                                                                • –1
                                                                                  Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM

                                                                                  Котлин написан поверх Java и в стандартной библиотеке, к примеру, не имеет своих коллекций, потому что он использует стандартные коллекции из Java. Если посмотреть к примеру ImmutableList — в байткоде это будет стандартный ArrayList из Java. И большая часть библиотеки Kotlin — это extension-функции над существующими классами Java. Поэтому рантайм и библиотека Котлин занимают в разы меньше места, чем аналогичный от Скалы.
                                                                                  Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?
                                                                                  Юморок на троечку. Посмотрите структуру apk — основную часть занимает dex-файл(ы). А еще поищите про dex-limit, почитайте вопли юзеров в Play Market, недовольных лишним мегабайтом размера приложения, и вы поймете, что Скала существенно увеличит размер установочного файла.
                                                                                  • –1
                                                                                    Теперь ясно что и куда тащиться) Действительно в этом приемущество Kotlin.
                                                                                  • 0
                                                                                    старый документ, но ознакомиться полезно
                                                                                • –1
                                                                                  А Вы попробуйте. Я два года писал на Scala, проходил курсы на Scala, агитировал руководство и коллег на Scala… А потом попробовал Kotlin и вот совсем на Scala возвращаться не хочется. И коллеги просто не нарадуются на Kotlin.
                                                                                • 0
                                                                                  Отсутсвие — как по стеклу провели.
                                                                                  • 0

                                                                                    А чем Groovy плох???

                                                                                    • +1
                                                                                      Он же вроде динамический?
                                                                                    • 0
                                                                                      Ну что, вам листать не надоело?

                                                                                      Чтобы избежать бойлерплейта, можно использовать lombok: projectlombok.org/features/all
                                                                                      • 0
                                                                                        В lombok по сравнению с Kotlin я пока вижу одну киллер фичу — логгеры)
                                                                                      • –6
                                                                                        Я старомоден и я люблю:
                                                                                        1 Java
                                                                                        2 писать код на Java
                                                                                        3 проверки на null в Java
                                                                                        4 геттеры и сеттеры в Java
                                                                                        5 смотреть как работает написанный код в Java

                                                                                        этот список могу продолжать бесконечно.
                                                                                        Меня умиляют высказывания вида «мы сможем меньше писать, язык сделает за нас <указать что сделает>». Мне не нравится, когда кто-то за меня что-то делает, да и выглядит все это, будто «пчелы против меда», ну как мы, разработчики, не будем писать код?
                                                                                        Меньше писать, выведение типов, прочие плюшки, очередной JS получается, не так ли?..
                                                                                        Обленились? Деградируем?
                                                                                        P.S. есть вопрос, который мучает меня последние пару лет, почему никто не пытается переписать C? а если пытается, то почему не кричит о том, что «мы сделали лучше чем C, айда все на нем писать»?
                                                                                        • +5
                                                                                          почему никто не пытается переписать C? а если пытается, то почему не кричит о том, что «мы сделали лучше чем C, айда все на нем писать»?

                                                                                          В 1983 году именно по этой причине был создан C++.

                                                                                          • 0

                                                                                            И попытки продолжаются, только теперь пытаются "переписать" и сам С++. (:

                                                                                            • 0
                                                                                              В принципе Джава стала той самой попыткой переделать С++, а потом Скала стала попыткой изменить Джаву, а после этого решили сделать новую Скалу и появился Котлин, так что дальше будут переделывать Котлин.
                                                                                              • 0
                                                                                                В принципе Джава стала той самой попыткой переделать С++

                                                                                                Пожалуй, но сейчас-то очевидно, что это скорее шаг в сторону.

                                                                                          • 0
                                                                                            Если вы так старомодны, так почему не пишите на Асамблере? :)

                                                                                            Наверное потому что Джава — лучше, проще, быстрее, и что-то делает за вас. Упрощение != деградация. Если вы считаете что проще — это хуже, тогда пойдите пешком в Барселону, да это сложнее чем полететь на самолете и через часиков 5 приземлится, но вы же считаете что проще это хуже.
                                                                                            • –3
                                                                                              Наверное потому что Джава — лучше, проще, быстрее, и что-то делает за вас. Упрощение != деградация. Если вы считаете что проще — это хуже, тогда пойдите пешком в Барселону, да это сложнее чем полететь на самолете и через часиков 5 приземлится, но вы же считаете что проще это хуже.

                                                                                              Не утрируйте, я с удовольствием пишу на асме там, где это удобно. Я с удовольствием пойду в Барсу пешком, мир посмотрю.
                                                                                              Упрощение != деградация

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

                                                                                                У вас какой год на календаре? Еще скажите что пишете на J2SE. Асамблер жутко неудобный, конечно выучить его по фану можно, но в работе его применять сомнительная затея, это мертвый язык, как латына.
                                                                                                • 0
                                                                                                  Вы, вероятно, никогда не писали для встраиваемых систем, асм вставки в Си — прекрасная вещь, упрощающая написание, а не рудимент.
                                                                                                  • 0
                                                                                                    Мне вот интересно: какая у вас ниша?
                                                                                            • +1
                                                                                              будто «пчелы против меда», ну как мы, разработчики, не будем писать код?

                                                                                              А вам платят за код? Ну тогда ладно...

                                                                                              • –1
                                                                                                Мне платят за решение поставленной задачи, без «ладно».
                                                                                                • 0
                                                                                                  Так что же для вас важно: писать код или решать задачи?
                                                                                                  • –1
                                                                                                    Вы путаете горячее с кислым.
                                                                                                    Я люблю писать код, а платят мне, — за решение задачи. Это немного разные вещи.
                                                                                                    • +1

                                                                                                      я не люблю писать тупой код. Так что как по мне ни о каком "пчелы против меда" речи быть не может.

                                                                                                      • –5
                                                                                                        Лол кек.
                                                                                                        Вы мне еще скажите, что «рокет сайенс еври дэй».

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.