Kotlin

Гуглить не умеешь => не для тебя.

Использую на платформе JVM, мне нравится. Из плохого - по моим ощущениям после релиза развитие сильно замедлилось и они сконцентрировались на кроссплатформенности (в частности Kotlin Native), которая лично мне нисколечко не интересна. Но в целом язык и в текущем состоянии весьма хорош.

Тоже показалось, что они значительные усилия тратят на этот native. Мне вот интересно, они правда считают, что достаточно сделать компилятор ЯП => LLVM или ЯП => js и можно дальше не развиваться по рынку, ожидая что вокруг языка сами появятся такие продукты как Flutter и React Native?

Kotlin классный, но javascript тут ни при чем.

Мне очень нравится. В контексте Android. Жить намного приятнее стало с Kotlin.

java, javascript, jvm, kotlin

найди лишнее

Idris лучше.

Мне очень нравится. В контексте Android. Жить намного приятнее стало с Kotlin.

Можно поподробнее в чем именно стало приятнее жить? Просто чаще всего мобильные приложения это «получить данные и показать их» (никакого рокет сайнс), а та же IDE делала всякие ставки и подстановки в один клик (тех же геттеров или подстановка типов). Действительно ли стало жить легче, или просто так сказали?

Мне понравились интерполяция строк (когда же уже дойдут до этого в Java, у всех давно есть) и функции-расширения, удобный сахарок. Хвалёный интероп с существующим кодом на Java лично мне не сильно понравился из-за разделения типов на обычные и nullable: из того, что я использую, часто приходилось писать !!. В целом первая ассоциация была «ух ты, Java на стероидах», кода действительно в среднем получается меньше, чтобы выразить ту же мысль, языком вполне можно пользоваться и будет более-менее удобно. Но опыт с Kotlin у меня совсем небольшой - один бот для телеграма и одно несложное десктопное приложение.
Из-за того, что все классы по умолчанию final, к сборщику приходится подтыкать костыль в виде плагина kotlin-allopen при использовании со Spring/Hibernate/etc.

Мне вот интересно, они правда считают, что достаточно сделать компилятор ЯП => LLVM или ЯП => js и можно дальше не развиваться по рынку, ожидая что вокруг языка сами появятся такие продукты как Flutter и React Native?

Я думаю, что они на это надеются. Им самим такой продукт вероятно не слишком нужен (в отличие от Facebook, например), поэтому делать просто чтобы был, вряд ли будут. А так людей в мире много, может кто и сделает.

Хвалёный интероп с существующим кодом на Java лично мне не сильно понравился из-за разделения типов на обычные и nullable: из того, что я использую, часто приходилось писать !!.

Покажешь пример? Есть ещё и платформенные типы и именно их использует компилятор для интеропа, в них не надо писать !!.

Из-за того, что все классы по умолчанию final, к сборщику приходится подтыкать костыль в виде плагина kotlin-allopen при использовании со Spring/Hibernate/etc.

Почему костыль-то? Официальный плагин. Если уж на то пошло, костыль это то, что жавовские фреймворки так любят наследоваться от твоих классов.

Покажешь пример?

Первое, что вспомнил - RestTemplate в {get,post}ForObject возвращает nullable тип, с которым так приходится делать. Но сейчас посмотрел, эти методы как раз @Nullable аннотированы, вполне возможно, и в остальных случаях так было. Насчёт платформенных типов в курсе, что с ними на свой страх и риск.

костыль это то, что жавовские фреймворки так любят наследоваться от твоих классов.

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

Насчёт платформенных типов в курсе, что с ними на свой страх и риск.

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

Kotlin поставит проверку на null сразу же, как только ты используешь этот тип в контексте того, что он не null.

Интересно. Т.е. если такая неожиданно оказавшаяся null'ом ссылка из Java-кода пойдёт в другие методы Kotlin-кода, где аргументы объявлены как не nullable, то NPE вылетит сразу же на месте вызова, и тогда стек-трейс может существенно короче получиться?

Да.

Да, я согласен, что мобильные приложения – это, в большинстве ситуаций, «получить данные и показать их», но даже в таких приложениях могут быть свои сложности. Показать данные тоже нужно суметь. :)

IDE – не волшебная палочка, ты всё равно контактируешь непосредственно с языком.

Мне, из того что предлагает kotlin, больше всего привлекают data-классы, null safety и функциональные возможности.

Да, в java тоже появились лямбды, null safety можно достичь средствами IDE и аннотациями, а data-классы можно генерировать каким-нибудь lombok, но с kotlin просто удобнее.

Это в идеальном мире клиенты - tiny client, в суровых реалиях API сделано жопой и тонна бизнес логики находится на клиентах, для показа одного экрана иногда надо сделать больше 1го и даже больше 2х запросов, что-то из этого при этом может отвалиться + это надо кешировать... В общем, не так всё прсто как ты думаешь.

жабка на андроиде - это нередко суровые реалии java 6. 7 жабу туда еще более менее завезли, а вот от 8 даже лямбды толком не доехали. так что котлин с его сахаром - это как базука после детского пистолетика

показа одного экрана иногда надо сделать больше 1го и даже больше 2х запросов

Больше двух запросов - да, теперь это действительно выглядит как «рокет сайнс» :) . На самом деле нет. То что тебе нужно получить больше данных чтобы отобразить побольше, не делают CRUD-приложение сложнее. Ну стало у тебя больше дата-классов и сервисов (в том числе для взаимодействия смежных данных и их кэширования), ну ничего в общем не поменялось.

больше всего привлекают data-классы

Мне интересно, они привлекают просто тем, что можно записать данные в одну строку или столбец? Насколько помню они не поддерживают наследование и по сути являются сишными структурами (без оптимизации и то, что поля надо объявлять в круглых скобках). Это действительно ощущается как некое новшество?

а data-классы можно генерировать каким-нибудь lombok,

IDE все это генерирует без lombok (просто получается обычная джава-простыня геттеров и сетеров и всяких хэш/иквэлс)

null safety можно достичь средствами IDE и аннотациями

null safety - штука полезная, но, по-моему, она притянута за уши? Кто-то прям реально от NPE страдал? Где-то еще сейчас пишут код, где пренебрегают null?

тоже появились лямбды

Лямбды штука хорошая в определенные моменты, но вложенный не читаемый (без IDE) калбэк-хелл, сомнительная радость. https://cdn-images-1.medium.com/max/1200/1*VyD7uBpMHNAaw4aAePzEtg.png Дело вкуса конечно, но без подсказок IDE тот код на грани читаемости (лапша)

IDE – не волшебная палочка

В случае таких языков как java и kotlin - все же волшебная.

Собственно это и обсуждаем, мол действительно ли такие сложные эти мобильные приложения, что люди на джава 6 прям вынуждены были страдать? Или момент притянут за уши?

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

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

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

Ты это можешь заказчику или боссу рассказать, как это все важно и незаменимо, но что такое мобильное приложение? Это получение готовых данных со своего сервера. Даже чужое API должно перевариться на твоем бэкенде. Ты вообще не должен как-то парсить приходящие твои же данные, тебе надо только раскидать по твоим дата классам, а потом по вьюхе. Что такое кэширирование в условиях отсутствия горизонтального масштабирования - ничего, ты можешь так же хранить все в своих дата классах, ограничив только частоту запросов и все. Что такое 5-6 запросов? Это смешно, у меня пет-проект по сервисам больше стучится на запрос.

Тоже самое касается и create/update/delete - ты можешь как на джаваскрипте распарсить для удобства пользовательский ввод, но все равно вся бизнес логика на бэкенде.

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

Не спорю что есть и сложные системы, но в среднем мобильное приложение, это действительно тонкий клиент (вам там бы и python за глаза хватило).

PS Это наверное особенность джавы. Ты вроде колошматишь тучу кода и кажется что делаешь что-то важное, там перекидываешь данные, что-то отбрасываешь и т.д., а на самом деле ты делаешь то же, что и js разработчик на тонком клиенте веба, который все делает тоже самое, но на порядок быстрее.

«у меня уже есть сайт, вам всего лишь надо для него сделать мобильное приложение!» (с)

Мне интересно, они привлекают просто тем, что можно записать данные в одну строку или столбец? Насколько помню они не поддерживают наследование и по сути являются сишными структурами (без оптимизации и то, что поля надо объявлять в круглых скобках). Это действительно ощущается как некое новшество?

Да, потому что одну строку поддерживать гораздо проще, чем 50. А если таких классов много, то это новшество ещё сильнее ощущается.

Я не спорю, что kotlin – это лишь сахарок, разной степени искусности, но тем не менее, вкусный сахарок.

null safety - штука полезная, но, по-моему, она притянута за уши? Кто-то прям реально от NPE страдал? Где-то еще сейчас пишут код, где пренебрегают null?

Может быть где-то и есть идеальный мир, где не пренебрегают null, но по моему опыту, NPE в статистике крэшей – это частый гость. Kotlin на 100% от них не спасёт, потому что есть платформенный код, где нет null safety, но дело упрощает.

Лямбды штука хорошая в определенные моменты, но вложенный не читаемый (без IDE) калбэк-хелл, сомнительная радость.

Без лямбд (а точне без RxJava/RxKotlin) сетевой код писать ещё более сложнее, чтобы он не скатывался в лапшу. Поэтому тут всё очень относительно. Без IDE с Android/Java вообще работать сложно, да и не понятно зачем это нужно.

В случае таких языков как java и kotlin - все же волшебная.

Не волшебная палочка в том смысле, что не скроет от тебя особенности языка. Писать на java и kotlin в одной и той же IDE – разные вещи.

Ты как-то очень уж сильно всё возводишь в абсолют. Не ситх-ли ты часом?)

Мобильные приложения не сложные, хотя бывают исключения, но их нужно обычно писать ОЧЕНЬ быстро, потому что всё слишком быстро меняется. Поэтому даже для простых приложений лучше работать на более эффективном языке с более эффективными инструментами. Kotlin хорош, но это не означает, что java – боль. Просто kotlin заметно упрощает жизнь, хотя и на java можно жить.

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

Потому что все преимущества на виду, на самом деле. Чего особо выдумывать.

На самом деле, быстрее самому попробовать что-то сделать на kotlin, чем обсуждать. Эффективнее будет. =)

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

Тыц

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

Не ситх-ли ты часом?

Кто? Это новый баззворд для тролля, или что?

Я «накидываю» реальность, на «вентилятор» опыта, чтобы человек выбросил из головы сохранёнки с митапа и включил критическое мышление, то есть чтобы задействовал опыт и сказал свое настоящие мнение.

Это не проблема котлина, это скорее сейчас проблема любой технологии, когда все как роботы говорят одно и тоже. Причем нередко, называя синие - мягким. Поэтому приходится предоставить контраргументы, чтобы человек вышел из привычной среды шаблонов и попробовал что-то сказать сам (если, конечно, у него вообще есть такое мнение).

На самом деле, быстрее самому попробовать что-то сделать на kotlin, чем обсуждать. Эффективнее будет. =)

Это так, если ты хочешь выбрать технологию. А вот если хочешь мнение услышать, это уже другое.

Tыц

Ничто не мешает создать класс-хендлер с хорошим заголовком, пускай даже с одним методом и передать его там где нужно. Тут вопрос конечно вкуса, но проблема в том, что лямбду тебе читать нужно всегда, чтобы её понять. А вот хендлер, с вменяемым названием, тебе либо вообще не придется, либо, скорее всего, прочитаешь один раз и как-то ассоциативно запомнишь (возможно второй раз уже не полезешь смотреть что это за хендлер если это UpdateHandler или ErrorHandler или ContractCacheHadler).

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

Если непонятно о чем я, то типа так

.subscibeBy(updateHandler, errorHandler);

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

По личному опыту: Очень зависит от ситуации, есть действительно tiny клиенты, где всё упирается в поход на REST API, парсинг JSON'a и отображение на экране, а есть приложения, где приходится пулять тонну запросов, слушать сокет, слушать пуши, при сваливании некоторых событий тригерить определенные действия, при этом, если свалятся другие события - либо ставить их в очередь, либо и вовсе игнорировать. В общем, приходишь к тому, что такая система уже намного сложнее чем простой клиент, возможно вся эта бизнес логика должна быть не на клиенте, но что имеем то имеем.

Как минимум в котлине сейчас сделали корутины - это отличный способ делать цепочки асинхронщины без RxJava в проекте (которая ну очень огромная и большинство её тащило в проект только ради async, не используя при этом 90% остального фреймворка). Да и в отличие от Java котлин развивается намного быстрее. Я сам ретроград до мозга кости, но последний проект мы пишем целиком на котлине и я очень доволен этим языком.

RxJava в проекте (которая ну очень огромная

Это в каком плане?

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