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

Ну и одновременно с этим стояла задача прокачать скилы чтоб типа мощно, модно, молодёжно. Поэтому получился следующий стэк: Angular 16.0.0, SpringBoot 3.0.6, Java 17 ну и Kotlin. Про недостатки ангуляра и спринга здесь опущу и сфокусируюсь на моих эмоциях по поводу последнего.

Услышал я о нём давно. Уж точно не помню когда. Может быть году в 15-ом, может раньше. Скажу сразу. Не интересовался, не читал. Страничку вики открыл только сейчас. И представление моё о нём было как некий язык, со своим синтаксисом и чудо компилятором, который что-то чудесничал и делал сразу байт код мимо стандартного java-компилятора. Не знаю, почему так думал. Может где-то прочитал, может не мог поверить, что великий Kotlin это тот же Groovy. Не знаю. Забегая наперёд – это всё-таки ещё один Groovy. Вот в таком вот приподнятом настроении я открыл https://start.spring.io/.

IDE

Приподнятое настроение закончилось ещё до того как я написал свою первую строчку кода на Kotlin-е. Когда я два или три дня потратил на интеграцию Kotlin-воркспейса в Eclipse. И честно признаюсь, у меня уже была стойкая и разумная мысль послать его к чертям и захерячить всё на Java. Сей разумный шаг не дала совершить моя профессиональная гордость. Я, если честно, так и не понял, в чём заключалась проблема. Сначала накатил честный плагин из маркет плейса. И проект упал. Я за 10+ лет такой ошибки в эклипсе не видел. Не могу заскриншотить её. Не думал, что буду писать это, так что не собирал скрины. Помню красный крест при открытии “Package Explorer”. Интернет плохо помогает в этом. Я даже писал отдельную тулзу для переименования файлов плагина (добавлял расширения “.class”) – не помогло. Пофиксил только установлением ещё одного плагина, где присутсвует имя Kotlin. Их там два вроде всего было. И вот с этим всем барахлом эклипс не очень хорошо себя чувствует. Часто уходит в норэспонс, особенно, когда пользуешь контекстное меню. При этом съедается CPU безбожно. Периодически приходится перезагружать IDE.

RedCode

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

Static

Первое, наверное, с чем я столкнулся это статические методы. Здесь разработчики Kotlin-а поступили ещё лицемерней, нежели разработчики Java. Если разработчики Java везде где только можно вопят о том что Java это объектно-ориентированный язык, при этом скромно умалчивают о процедурном бекдоре в виде модификатора static, то разработчики Kotlin-а решили вопрос кардинально – запретили этот модификатор! Совсем. Но статический доступ есть. Через одно, извините, место.

Не знаю, какие преимущества такая реализация статики даёт по сравнению с Java статикой. То, что усложнили жизнь программисту – это факт.

NonNull

Ещё одна параинодальная фича. Среди конфигураторов спринга когда-то бытовало мнение, что NPE это плохо. И возможно оно так и было лет эдак 10+ назад. Сейчас даже для спринга нет такой проблемы. К тому же в последних Java версиях эта ошибка довольно качественно описывается. Так что для меня как программиста проблемы null не существует. Вот в принципе. Все возможные NPE должны отлавливаться на этапе тестирования. А для меня в программе null быть обязан. Особенно в высоко нагруженных системах, где создавать объекты-пустышки или обёртки слишком дорого. null вполне себе однозначное определение состояния объекта. В Kotlin-е зачем-то решили это как-то фиксить. Думаю, это была модная фича на заре становления этого языка. Дабы привлечь конфигураторов с секты спринга и прочих блаженных мечтателей избавления от шайтан-нуля.

В Котлин-е подошли прямолинейно. Где бы ты ни инициализировал переменную, ты обязан определить может ли она принимать значения null или нет. Я не знаю чем думали такие как Тагир изобретая этот подход, но применять на практике мне было не удобно от слова совсем. Наверное предполагается иметь в голове совершенно продуманную архитектуру вашего приложения вплоть до того будет та или иная переменная нулём или нет. И только после этого начинать писать код. Я, к сожалению, так не умею. И мне было ооочень некомфортно периодически скакать по классам и править уже написанный код. И хорошо, когда это прицепом не тянет интеграцию с фрейморками. В таком случае застряёшь на некоторое время, думая как это пофиксить. Не понял, не принял.

Замыкания

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

Что такое Unit и почему я должен указать его, чтобы проигнорировать результат выполнения?.. И почему я должен активизировать лямбду так же как создаю новый объект? И вообще это что, создание объекта или вызов метода?!

А здесь про “лаконичность”:

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

К “лаконичности” ещё можно отнести имена класса: Scanner::class, Scanner::class.java, javaClass.

Коллекции

Здесь тоже, я считаю, разработчики Kotlin выстрелили себе в ногу преследуя цель сделать что-то лучше, нежели ребята из Sun\Oracle. Не буду закапываться по мелочам. Скажу моё общее впечатление, что легко юзать Java коллекции у меня не получилось. Постоянно приходилось искать те или иные воркэраунды в, казалось бы, примитивных операциях. А разбираться в скудном предложении от Kotlin-а мне не хотелось.

Cast

Думаю, уже можно сложить мнение как протекала разработка, было открыто много страничек в браузере. Сложилось впечатление, что Kotlin не особо описан в интернете. Решения если и находились, то непрямые и с трудом. Но больше всего времени было потрачено на поиск причины бага, связанного с приведением типа. К сожалению, подробных деталей я уже здесь не приведу – давно это было. Что помню. Значит, данные у меня хранятся в файле в виде обычного json. При старте, я выгружаю json (список моих фильмов) ну и далее пользую по коду. И вот при выгружении данных я приводил их к моему типу. Kotlin это пропускал без ошибок. Всё типа ок. Ну а далее по коду, когда я пытался итерировать по списку моих данных, Java ругалась, что не может закастить мапу к моему типу объекта. Вот тут началось. Наверное, я испытывал панику спринг конфигуристов на заре зарождения сего чуда. Ошибка вроде понятна. Но абсолютно не понятно почему. Ведь надеешься на то, что Kotlin принял приведение к типу. В процессе поиска я и нашёл компилированные Java файлы.

Как можно наблюдать ничего нового. Тот же Groovy. Последний можно перегружать в рантайме. Можно ли такое делать с Kotlin – не знаю.

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

Пока всё. Не знаю будет ли что-то ещё. Я лично не нашёл для себя, каких либо мега-ацки крутых фич, которые бы привлекли меня и дальше пользовать Kotlin.