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, что может в один день при смене профиля пригодиться.

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

Комментарии (89)


  1. akryukov
    12.12.2017 21:57

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


    1. vlad2711 Автор
      12.12.2017 22:00

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


      1. akryukov
        12.12.2017 22:06

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


        1. vlad2711 Автор
          12.12.2017 22:08

          Да нет все ок. Просто pojo генератор так сгенерил, вот и все.


    1. Serg_de_Adelantado
      12.12.2017 23:49

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

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

      Если же нужно поместить какую-то логику в геттер, то можно так:
      val foo: String
              get() = TODO("Implement getter")
      


      1. qwert_ukg
        13.12.2017 06:12

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

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


        val a = ""


      1. domix32
        13.12.2017 14:48

        А что с ситуацией когда одному только почитать, а другому еще и пописать? Два интерфейса?


    1. jericho_code
      13.12.2017 11:38
      +1

      Стоит отметить что data классы содержат реализации методов equals, hashcode, toString и componentN (для расщепления классов), так что на java ваш класс был бы еще больше. Что важно эти методы реализованы разумно, и разработчики языка учли множество подводных камней при их реализации.


  1. LonelyDeveloper97
    12.12.2017 22:06
    +1

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

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

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

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

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

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

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

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

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

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

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

    P.S.
    Я вот думаю, статью на эту тему написать, что ли.


    1. vlad2711 Автор
      12.12.2017 22:24

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

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


      1. Nikobraz
        13.12.2017 04:57

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


        А вот тут вы не правы. Для развлекательного чтива под чай с булочкой возможно. А когда стоит выбор в какой язык упарываться рогом тратить сотни часов на обучение, то максимально субъективное чтиво, пусть и кратко-тезисное в самый раз.


      1. saag
        13.12.2017 11:39
        +1

        «Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.»
        «Не все так однозначно»(С) Ибо вам придется платить за лицензию винды, бюджетным вариантом будет компьютер с Линуксом


      1. TheKnight
        13.12.2017 14:18

        А давайте лучше научный трактат?) О том, чем Java лучше Kotlin?
        Прям любопытно будет прочитать и сравнить.


      1. LonelyDeveloper97
        13.12.2017 15:01
        +1

        Мне кажется, что вы неверно поняли посыл моего комментария.

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

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

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

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

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

        А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.


        1. vlad2711 Автор
          13.12.2017 15:15
          -1

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


    1. Fesor
      12.12.2017 23:14

      ибо если хоть в одном случае окажется, что Java лучше Kotlin

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


      1. Djaler
        12.12.2017 23:48

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

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


        1. Fesor
          13.12.2017 09:21

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


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


      1. vlad2711 Автор
        12.12.2017 23:52

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


        1. Lure_of_Chaos
          13.12.2017 06:45

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


          1. Fesor
            13.12.2017 09:02

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

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


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


    1. yarric
      13.12.2017 00:41

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


  1. myxo
    12.12.2017 22:22
    +1

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

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


    1. Idot
      13.12.2017 05:15

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


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


      1. vlad2711 Автор
        13.12.2017 11:48

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

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


        1. Idot
          13.12.2017 12:09

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


        1. yarric
          13.12.2017 13:18

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


          1. vlad2711 Автор
            13.12.2017 13:38

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

            На текущий момент комьюнити Котлина по численности сильно уступает комьюнити Jav


            1. qwert_ukg
              13.12.2017 13:51

              Документации на Котлин действительно немного

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


            1. yarric
              13.12.2017 13:52

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


              1. vlad2711 Автор
                13.12.2017 14:15

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

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


                1. Idot
                  13.12.2017 14:18

                  писал по аналогии с Java

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


                1. yarric
                  15.12.2017 10:18

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


          1. basnopisets
            13.12.2017 22:16
            +1

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


            1. yarric
              15.12.2017 10:25
              +1

              А это кто?


              1. vlad2711 Автор
                15.12.2017 10:44

                О мой Бог, вы не знаете кто этот Великий Человек? Он ведущий разработчик в Square, и он подарил миру столько прекрасного и упрощающего рутину обычному программисту: Retrofit(создание запроса с минимальным количеством кода), ButterKnife(упрощение биндинга вьюшек до нельзя, всего одна строка кода на каждую вьюшку, вместо двух с findViewById), приложил руку к Dagger(улучшает тестируемость кода), и это далеко не весь список. Поэтому любой андроидщик хоть раз в жизни юзал творения над которыми он работал. Вот за это он один из самых известных и уважаемых людей в мире андроид разработки.


  1. GrandArchTemplar
    12.12.2017 23:48

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


    секвенсес не могут в параллелизм
    стримапи может в параллелизм
    но это с точки зрения сахара


  1. Terras
    13.12.2017 00:12

    Картинка то какая. Телефон на Java убитый и заляпанный, а на Kotlin сияющий и блестящий. Какой-то дотнетщиной пахнуло =)


  1. lgorSL
    13.12.2017 00:57

    Нету Getter'ов и Setter'ов

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


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


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


    1. qwert_ukg
      13.12.2017 05:56

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

      Про это уже только ленивый не писал)


      1. darjke
        13.12.2017 06:49

        Дак и про то, что код на kotlin короче кода на java написано куча статей, это ведь не помешало автору еще раз это продублировать


    1. vlad2711 Автор
      13.12.2017 12:03

      Ладно, они реально есть, но фишка в том что они уже зашиты в сам язык, и не нужно объявлять их в коде.


  1. Solexid
    13.12.2017 03:20

    Kotlin это когда хочешь писать на C# с JVM.


    1. qwert_ukg
      13.12.2017 06:07

      Давно простится статья «Kotlin vs C#». Сам ушел с C# на Kotlin, много плюшек есть в обоих языках (может потому что Бреслав работал в MS, до работы на JetBrains), но в котлине, на мой взгляд, все более удобно, те же екстеншены.


      1. F0iL
        13.12.2017 13:57

        Давно простится статья «Kotlin vs C#»

        а напишите, будет интересно.


        1. qwert_ukg
          13.12.2017 14:01

          Уже начал, к сожалению не много свободного времени.


      1. basnopisets
        13.12.2017 22:24

        из команды Котлин Илья Рыженков ранее работал над Resharper — тоже без влияния C# не обошлось


  1. qwert_ukg
    13.12.2017 05:54

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

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


    1. Lure_of_Chaos
      13.12.2017 06:40

      Речь не о джаве, а о том, что дизайн языка запрещает неявный null — либо мы явно используем billable (в джаве все по умолчанию) типы, либо нас заставляют описывать какой-то dummy объект вместо null. Ситуация схожая с проверяемыми исключениями в джаве — либо обработай, либо явно выбрось наверх.
      Другой вопрос, хорошо ли это (т.к. почти во всех статьях восхваляют данную фишку). Возможно, пусть прога лучше со свистом грохнется и покажет стектрейс, с исправлением ошибки за минуту, чем прога будет работать, но работать неправильно и хрен ты эту логическую ошибку найдешь.


      1. qwert_ukg
        13.12.2017 06:45

        Я про то, что NPE на рантайме, и в котлине поймать можно.


        1. Lure_of_Chaos
          13.12.2017 06:49

          О том и речь — конечно, как явление, NPE в котлин существует, но случайно написать код, который его производит, уже чуть сложнее


        1. vlad2711 Автор
          13.12.2017 11:52

          Суть в том что его поймать тяжело. Конечно если сильно постаратся то и дьявола можно призвать. В Джаве вы можете просто забыть прописать проверку на null и у вас все крешнится. А Котлин заставит вас сделать проверку на null иначе он просто откажется компилироваться.


  1. qwert_ukg
    13.12.2017 06:44

    Я про то, что NPE на рантайме, и в котлине поймать можно.


  1. Arnis71
    13.12.2017 10:05

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


    1. qwert_ukg
      13.12.2017 10:46

      Может Вы подскажете в чем сила?


      1. Arnis71
        13.12.2017 15:17

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


        1. vlad2711 Автор
          13.12.2017 15:21

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


  1. maxzh83
    13.12.2017 10:27

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

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

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

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

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


    1. qwert_ukg
      13.12.2017 10:39

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

      Про корутины, это да, а про все остальное тут полно всего.


    1. vlad2711 Автор
      13.12.2017 16:21

      Lombok — это круто, но это сторонняя библиотека, а здесь уже все зашито в сам язык


  1. OLDRihard
    13.12.2017 11:18

    Вот когда хайп уляжется и статьи про поней какающих радугами сойдут на нет, тогда посмотрим.


  1. Konachan700
    13.12.2017 11:50

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

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


  1. bex2014
    13.12.2017 11:53

    import lombok.Data;

    Data
    public class User {

    private String firstName;
    private String lastName;
    }


  1. Space_Cowboy
    13.12.2017 11:54

    Хватит рекламить этот котлин! Такое чувство что JetBrains проплачивает такого рода посты. Я лично за Скалу, зачем вообще он был нужен, когда скала на момент создания уже была?


    1. vlad2711 Автор
      13.12.2017 12:01

      Ну Скалу все равно считают довольно сложным языком, да он легче чем тот же Си, но все же…

      Честно говоря еще неделю назад я тоже думал что в нем нету ничего такого. Но виной был страх что-то менять и было немного лень напрягаться.


      1. Enverest
        13.12.2017 16:26

        А в чём выражается сложность Скалы? Синтаксис? Стандартная библиотека? Фреймворки? Тулзы для работы?


        1. lgorSL
          14.12.2017 15:20

          Да ни в чём.


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


          • В котлине есть специальный синтаксис для определния геттеров-сеттеров, в скале это просто методы типа 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. qwert_ukg
            15.12.2017 06:03

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

            А зачем?


    1. vshaldin
      13.12.2017 12:15

      Со стороны JetBrains, создание своего языка — очень годный ход. Это определенная сфера влияния в бизнесе, которая напрямую ведет к обогащению. Я же не думаю, что есть люди, которые верят в утверждение «мы создали его, чтобы вам было удобнее»? Тот же Oracle, не «так просто» скупает платформы, языки и системы.


      1. vlad2711 Автор
        13.12.2017 12:16

        JetBrains сделали Котлин в первую очередь для себя. Они активно юзают его внутри компании


        1. Terras
          13.12.2017 14:22

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


        1. Flux
          13.12.2017 23:11

          Настолько «для себя» что этот котлин форсится так неистово, что даже не хочется к нему прикасаться.

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

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


          1. Fesor
            14.12.2017 13:10

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


            1. Flux
              15.12.2017 19:20

              Не только.

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

              Есть другая реклама — полные императивных посылов крики «покупай, пользуйся, делай!!11» без единых описаний почему я должен пользоваться чем-то. Это реклама стиральных порошков, бытовых товаров и прочьего ширпотрепа — попытка перекричать голос разума яркими метафорами и безудержным восхвалением. Вот такая реклама у котлина и такая реклама вызывает только тошноту, потому что авторы считают идиотом неспособным к критическому мышлению которого нужно подтолкнуть в сторону «правильного» продукта.


    1. basnopisets
      13.12.2017 22:22
      +1

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


      1. Space_Cowboy
        14.12.2017 10:58

        Я не андроид разработчик, но всетаки поинтересуюсь:

        Котлин работает поверх Java
        Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM потом интерпретируется ведроид компилятором под DVM. Не очень понял что вы имеете ввиду?
        тащить весь язык со всеми его библиотеками
        Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?


        1. vlad2711 Автор
          14.12.2017 11:05

          Да, он работает поверх Джавы. Поэтому в Котлине можно юзать все что написано на Джаве. Еще он может компилиться в байт-код javascript


          1. Space_Cowboy
            14.12.2017 11:21
            -1

            работает поверх Джавы

            Что вы все заладили, что в вашем понимании это означает? Я то думал это предусмотренная компилятором обратная совместимость с Java, в Scala тоже самое, потому что котлин это попытка JetBrains написать свою скалу, и что то мне подсказывает что писали они ее не с 0.
            байт-код javascript
            Что простите? (facepalm) В какой из множества вариаций javascript — bytecode, или они заставили все браузеры перейти на оди и тот же компилятор?
            Складывается впечатление что у людей напрочь отсутствует понимание, того как работают языки вне красивых кнопочек и подсветок в их IDE…


            1. vlad2711 Автор
              14.12.2017 11:24

              Честно говоря я это не проверял но в документации читал что он может компилиться в javaScript


              1. Space_Cowboy
                14.12.2017 11:44

                Да может, но не в javaScript Bytecode, У Scala тоже есть интерпритатор в js. ScalaJS называется вроде.


                1. vlad2711 Автор
                  14.12.2017 11:48

                  Спасибо, что разъяснили.


        1. basnopisets
          14.12.2017 11:13

          Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM

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


          1. Space_Cowboy
            14.12.2017 11:33
            -1

            Теперь ясно что и куда тащиться) Действительно в этом приемущество Kotlin.


        1. basnopisets
          14.12.2017 11:18

          старый документ, но ознакомиться полезно


  1. jorl
    13.12.2017 16:18

    Отсутсвие — как по стеклу провели.


  1. GamaleyVV
    14.12.2017 10:20

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


    1. qwert_ukg
      14.12.2017 12:49

      Он же вроде динамический?


  1. iki
    14.12.2017 11:05

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

    Чтобы избежать бойлерплейта, можно использовать lombok: projectlombok.org/features/all


    1. TheKnight
      14.12.2017 14:01

      В lombok по сравнению с Kotlin я пока вижу одну киллер фичу — логгеры)