Хабрахабр

«Крайне мало кто реально пишет бэкенд на Котлине» — интервью с Пашей Финкельштейном

Как стать программистом от безысходности и подняться к вершинам успеха? Сегодня в нашей виртуальной студии на вопросы отвечает Паша asm0dey Финкельштейн. Паша – один из немногих, кто разбирается в создании бэкендов на Kotlin. Кроме того, он пилит опенсорс, активно участвует в жизни сообщества, и, на минуточку, — побывал на почти всех наших московских Java-конференциях.

Во-первых, ты выступаешь на Joker с докладом. — Есть несколько тем, которые можно обсудить. В-третьих, ты постоянно ходишь на наши конференции и почему-то считаешь, что это хорошо.
Во-вторых, ты активный участник сообщества, постоянно что-то делаешь.

Я, как и большинство людей, страдаю синдромом самозванца, у меня нет ощущения, что я много чего полезного делаю, особенно для Java-сообщества, особенно в последнее время. — По поводу того, что я участник сообщества. Она маленькая и удобная.
Последнее, что я сделал полезного для сообщества — мы с ребятами написали клёвую библиотеку для Spring, которая называется spring-flow-state-machine, которая позволяет управлять состояниями объектов в приложении.

— Это та самая библиотека, которая сейчас пиарится на главной Спринга?

Spring Statemachine управляет состоянием приложения, когда твое приложение представляет из себя какую-то finite statemachine и в разных состояниях работает по-разному. — Нет, наверное, там Spring Statemachine, и она дико убогая: она очень плохо написана, очень странно работает и делает совсем не то. А наша задача — подумать о том, чтобы у тебя транзакции работали и всё такое. Мы сделали другую штуку: когда у тебя есть какая-то сущность, ты для неё задаешь жизненный цикл и можешь её по этому жизненному циклу гонять. Главное, что там есть удобный DSL, который позволяет говорить, откуда куда можно и что нужно делать по дороге.
У нас просто в одном правильном месте стоит аннотация @Transactional, как ты понимаешь, и этого достаточно для того, чтобы мы говорили, что оно управляет состоянием.

— А я правильно понимаю, что, поскольку эта штука у тебя управляет абстрактными вещами, на ней можно сделать то же самое, что делает Spring Statemachine?

Основной сущностью, которой управляет эта штука, является, кажется, entity with id или что-то в этом роде. — Да, правда, есть нюанс. Это действительно очень маленькая библиотека из двух интерфейсов, двух exception'ов и четырех классов.

— А та штука, которую Spring сделал — почему ты считаешь, что это нечто странное и непонятно зачем нужное?

Оно заявлено, как будто умеет вообще всё. — Оно понятно, зачем нужное, просто сделано очень плохо. Кстати, кажется, к Spring Batch обычно примерно те же претензии.
Во-первых, примеры, которые у них приведены в документации, не собираются, а во-вторых, если попытаться покопаться в исходном коде (а ты всегда копаешься в исходном коде Спринга, когда хочешь что-то сделать, потому что далеко не всё написано в документации), ты выясняешь, что он написан так, как лучше писать не надо.

— Ты Spring Batch тоже использовал?

— Мне кажется, я использовал почти всё, что есть в экосистеме Спринга.

— И как — продолжишь использовать?

Это был не мой выбор. — Ты знаешь, на следующем месте работы у меня не будет Спринга, у меня будет ЕЕ. Его написал в одно лицо какой-то Java-чемпион. Наверное, я бы использовал Спринг, но вообще-то я в нашем подкасте как-то рассказывал, что сейчас мой фаворит — это микрофреймворк Jooby, который умеет всё на свете. Оно прикольное, у него есть экосистема, в отличие, кстати, от всех остальных микрофреймворков.
Там есть тоже dependency injection, который построен на Guice.

— Я вижу, что есть два варианта — для Java и для Kotlin.

На Scala, наверное, тоже можно, но придется отказаться от Guice, который наверняка со Scala не работает. — Я подозреваю, что можно для чего угодно. А это делается в Guice.
Я, как обычно, люблю constructor injection с аннотациями.

— А если такое приложение можно будет собрать с помощью GraalVM статически — это будет просто космос.

Это как Spring — конечно, что-то выиграешь по перформансу.
— Я не думаю, что ты там много чего выиграешь.

— Поднимать скорость стартапа, например.

— Конечно же мы в продакшн потащим какую-то маргинальную штуку, написанную одним Java-чемпионом, и будем там бороться за скорость стартапа!

— Понятно.

— Наверное, ребята, которым по-настоящему важна скорость стартапа, берут какой-нибудь Azul Zing и тюнят им что-нибудь на голом SE написанное.

— А я правильно понял, что та библиотека, которую ты писал, она опенсорсная и всё такое?

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

То есть писали вы ее в рабочее время.
— Понятно.

— Да, писали в рабочее время.

— А как ты думаешь, есть какая-то перспектива писать софт в нерабочее время?

А последнее, что я написал… сейчас в России актуальна проблема с блокировками, а для меня актуальная проблема — эти блокировки обходить. — Я пишу софт в нерабочее время, правда, сейчас это не настоящий софт. И в Ansible Galaxy тоже расшарил.
Есть замечательный прокси-сервер, который называется 3proxy, вот я под Fedora, Ubuntu, Debian и Centos написал Ansible playbook, протестированный во все концы, и расшарил его на GitHub.

— А где ты находишь время на вот это всё?

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

— Что бы ты посоветовал тем, кто хочет начать писать что-то в опенсорс, но никак не получается?

И в зависимости от ответа на вопрос, попробовать что-нибудь написать.
— Спросить себя, почему не получается?

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

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

Бывает две причины: ты еще совсем мало времени вообще занимаешься чем-то таким в программировании, и тебе кажется, что это что-то предельно скучное, и тогда вероятно, правда, на этом этапе ты никому не можешь помочь. Если непонятно, кому ты нужен, вопрос, опять-таки, почему. Это был его путь в программирование (это шутка, конечно). Хотя я знаю людей, например, Слава Семушин — первое, что он сделал — стал контрибьютить в Alt Linux до того, как начал программировать куда-то там в продакшн. И вот это уже не шутка.
Но он реально ничего не понимал, когда начал, разбирался по ходу.

В этой ситуации очень долго был я. Бывает такое, что люди долго занимаются энтерпрайзом и не понимают, что могут сделать. Я 6 лет уже был в энтерпрайзе и не понимал, что я могу сделать. Еще года 4 назад точно. Это должно быть согласовано с работодателем. Но со временем я увидел, что вот этот вот компонент системы, который я хочу переписать, в принципе можно выделить в отдельный модуль и его заопенсорсить. Главное — сделать первый шаг.

Например, Тинькофф не горит желанием какие-то свои бэкенд-компоненты опенсорсить, хотя теоретически можно было бы.
Иногда работодатель не хочет согласовывать, это довольно живая тема.

Главное, выделить это в отдельный компонент. Ты начинаешь видеть возможности со временем. Потом на следующем проекте ты увидишь, что эту штуку можно выделить тоже.
Если работодатель не разрешит, будете внутри работодателя использовать, будет такое внутренний опенсорс, как делают в каком-нибудь Zalando.

Или написать её заново, например.
— Ух ты.

Одной из проблем, которую мы решали на прошлом месте, было логирование. — Насчет «написать заново». Стандартное решение для этого — ELK stack, ElasticSearch, Logstash, Kibana. Понятно, все крупняки заморочены с централизованным логированием, без этого жизни вообще нет. ElasticSearch, Kibana работают хорошо, а Logstash — не очень. Только есть маленькая проблема — это Logstash. Если он работает не персистентно, то размер очереди у него — 5000 сообщений. Он либо работает не персистентно, либо очень медленно. Мягко говоря, неприятная особенность. Напихал больше — сообщения начинают дропаться. В Сбербанке мы написали свой Kafka logback appender, который тоже заопенсоршен и вполне себе отлично работает.
Поэтому у нас вместо него была Kafka.

— Так вот кто это был!

— Их уже три, я не уверен, что ты именно наш видел.

Возвращаясь к теме опенсорса и логгирования. — Ладно. А почему люди используют в энтерпрайзе централизованные логгеры постоянно, пытаются их сами писать, если там есть Linux и придуманные дедами способы — залить все в файлик, например?

Там есть rsyslog, который является хорошим форматом, но, мягко говоря, не адаптирован, например, к Джаве, потому что если ты посмотришь на какие-нибудь стектрейсы, то внезапно выяснится, что стектрейсы — это много строчек, а не одна. — Я не знаю в Линуксе нормального централизованного логгирования. Если это всё замешается в одну большую кучу, мне кажется, больно будет всем.
Так что и в rsyslog-е это будут отдельные записи лога.

— Да, наверное.

Я обычно запариваюсь, когда у меня есть какое-то решение, я пытаюсь найти его место в CAP-теореме. — А еще я, честно говоря, не знаю, какие гарантии дает rsyslog. Но быстро я его определить не смог. И я по rsyslog просто не нашел этой информации, может, я плохо искал. Какие там таймстемпы будут у того, что он зашипит куда-нибудь? Он нам вообще гарантирует доставку и за какое время? Если он не гарантирует доставку, это совсем беда. Если он гарантирует, это уже неплохо, если ты нормально ведешь логи со всякими там спанами и трейсами, тогда ты всё равно разберешься, что бы он там ни сделал. Это при том, что я плохо знаю Кафку, честно говоря.
Кафке в этом смысле я доверяю больше, но у нее больше пропускная способность.

— Там нужно еще как-то поделить, наверное, логи на критичные/не критичные, потому что если сервер логирования все-таки вылетит, то никогда не узнаешь, что произошло.

Мы бегаем в каком-нибудь Докере и у нас логи в stdout вводятся от уровня ERROR. Пока мы с тобой говорим о Джаве, всё совсем просто. Я тот человек, у которого дебажные логи вообще-то никогда обычно не выключаются. А в Кафку льется всё, начиная от дебага или от трейса. Я еще ни разу не дожил до этого светлого момента, когда я понял — всё, я больше не использую дебажные логи для разбора проблем.

— А ты не боишься, что пропускная способность, например, сети Кафки просто возьмет и закончится, если все эти терабайты логов туда полетят?

Основная проблема, как его хранить, а не как его передавать. — Мы всегда были слишком маленькими, у нас было 100 Гб логов в день, а 100 Гб — что это за объем? А у тебя реально были терабайты логов?

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

Мне кажется, или вы пошли не тем путем, когда сделали логи синхронными, по сети?
— Подожди.

— Нет, они как раз лились именно в Кафку.

Вряд ли у вас был вариант делать асинхронно, вам нужно было бы дождаться ACK от Кафки хотя бы от одной ноды, даже если вы совсем упороты и вам не хочется гарантии на логи. — Но синхронно? Хотя бы один ACK вы всё-таки дожидались.

— Наверное, да.

Но мы этот appender завернули в AsyncAppender, а потом экспериментально посчитали, сколько у нас сообщений бывает в пике, и буфер в этом AsyncAppender выкрутили на чуть-чуть больше, типа там пик плюс 10%. — Я так говорю, потому что мы писали logback appender, я понимаю, чем мы руководствовались. Получилось, что у нас приложение не блокируется.

А почему в Джаве это всё не стандартно, почему надо писать руками?
— Какие страшные рассказы у тебя.

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

— То есть ты считаешь, там нет каких-то библиотек, которые можно добавить в Maven, и всё само установится?

Конечно, у них есть библиотеки для логирования, они и в Джаве есть, и понятно, как к ним приделывать аппендеры. — Давай начнем с того, что у них нет нормального Maven, у них ведь Ninja, Make, CMake, qmake и всё немножко тяжело с Maven. А если ты посмотришь на какой-нибудь Rust, там что-то совсем грусть-печаль. Причем в Джаве они красивые, гибкие, работают обычно с фасадами и всем таким. Я с трудом осилил, как их конфигурировать.
Я не знаю, куда там класть и записывать свои логгеры.

— То есть на самом деле Джава тебе нравится?

Мне нравится Котлин как язык и Джава как экосистема. — Мне нравится экосистема. Когда-то я торчал на Groovy, у меня даже есть футболка от Баруха с надписью Groovy.
Кстати, ни одного языка, лучше Котлина, я сейчас вообще не знаю.

— Выбирая между Java, Scala, Groovy и Kotlin – почему именно Kotlin?

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

— В Скале доделали макросы, получается?

И если ты еще умнее, то ты используешь библиотеку типа Cats. — Я хочу сказать, что они работают, но я не хочу сказать, что ими можно пользоваться. Но этот код никто не может читать, кроме тебя.
Но это, наверное, на том же уровне, когда ты стал чуть-чуть умнее и тебе уже скучно использовать scalaz, и ты используешь Cats.

— И других адептов Cats.

— Ты так говоришь, как будто это правда, но это не правда, потому что другие адепты Cats используют его по-другому.

— В этом и есть часть мощности этой системы.

— Очень мощная, напоминает BFG.

— Которым ты стреляешь себе под ноги.

Кстати, заметил — люди, которые пишут на Скале, иногда забывают думать. — Иногда себе, иногда другим, как повезет. У них зато красивые вызовы в базу каким-нибудь сликом (или что там сейчас модно для работы с SQL в Скале).
У них такие красивые концепции, что они могут сделать 2 инсерта подряд в разных местах и не подумать о том, что это всё нужно как-то завернуть в транзакцию.

— Но ты же в Джаве можешь в двух местах сделать...

В Джаве не принято делать сложные вещи. — Но в Джаве у меня есть Spring, и я ставлю аннотацию @Transactional. А в Скале принято. В Котлине, похоже, кстати, тоже. Еще они иногда любят кричать, что любой валидный джава-код — это любой валидный груви-код, но это неправда, потому что там не работают anonymous inner classes. Насчет Груви – это крутой язык, конечно, пока не залезаешь в байткод с одной стороны или не напарываешься на то, что ты не понимаешь, какого типа у тебя объект. Ты должен создать лямбду и потом ее кастовать. Нельзя взять и инстанциировать. С другой стороны, никакой новой сложности. И поэтому я выбираю Котлин, у него немного другой синтаксис, чем в Джаве, но там есть конвертер, если очень хочется. Ты ctrl-кликаешь на двойное равно и переходишь на метод equals.
Нет ничего такого, где ты не мог бы ctrl-кликнуть на что-нибудь и не перейти.

Сейчас многие не очень доверяют Джаве, потому что это Oracle, а что делать с JetBrains? — Такой скользкий момент: а ты доверяешь JetBrains? Там нормальные ребята сидят, развивают язык?

У меня нет варианта «не доверять». — Не хочу спойлерить кусок доклада, но в целом мне нравится, как они говорят, и мне нравится то, что я вижу. Наверное, Rust (разрабатывается Mozilla), Golang разрабатывается Google. Окей, ну не доверяю я JetBrains, тогда всё становится совсем грустным, потому что какие еще у нас языки разрабатываются каким-то относительно вменяемыми людьми? Просто непонятно, кому и почему можно доверять. Плюс они все разрабатываются сообществами в том числе, даже Джава. У меня проблемы с паранойей, я в нее не умею.

Joker — одна из основных наших конференций, и мы постоянно пишем о ней на Хабре. В первый день конференции Joker (19-20 октября 2018) Паша будет рассказывать о бэкендах на Kotlin в докладе «Котлин — 2 года в продакшне и ни единого разрыва». Если есть возможность — обязательно приходите.

— Недавно мы с Барухом обнаружили некое исследование на тему Котлина, которое показывает, что программа на Котлине в 40 их попугаев (попугаев исследования) лучше, чем программа на Джаве.

— Не лучше, а короче, если мне память не изменяет.

Они измеряли это всё в код-смеллах (code smell). — Там и короче, и лучше. Наверное, в каком-то смысле это можно заменить словом «лучше».
Не знаю, как это сказать.

Только знаешь, в любом сравнении двух языков есть одна маленькая проблема. — Отлично. Правда ли код-смеллы одинаково качественно меряют в Джаве и в Котлине? Правда ли реализовали одну и ту же задачу и правда ли были одинаковые инструменты измерения? Или на Джаве пишут последние 20 лет и код смеллов научились находить 800, а на Котлине пишут 2 года и научились находить 20?

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

Одна из целей моего доклада — ускорить этот процесс. — Понятно, что весь Android почти переехал на Котлин (современная разработка), а бэкенд переезжает очень медленно. Это же только для мобилок! Когда я пришел в HH на собеседование и сказал, что последние два года я пишу бэкенд на Котлине, мне сказали, а что, так можно? Вероятно, и сотрудники тоже не знают. Работодатели реально не знают, что так можно. Да какие 10! Про объём адаптации сложно говорить, думаю, что в Android к 80-90%, а в бэкенде — процентов 10 максимум, наверное. А вот если засчитать только новые проекты, то может будет процентов 10.
Если считать все легаси-системы, там и двух процентов не наберется.

— То есть как минимум такая вещь, как Котлин на бэкенде, уже существует?

И до этого тоже писал.
— Да, я же в Центре Недвижимости от Сбербанка писал.

Просто многие говорят, что это маркетинг JetBrains, и живые люди по-другому будут на это реагировать.
— Хорошо.

— Часть моего доклада посвящена тому, что в итоге вся джава-часть компании стала переходить на Котлин после того, как наш проект успешно полетел.

Во-первых, ты можешь смешать Джаву и Котлин в качестве базы. — Вот, и следующий вопрос дальше возникает: какой процент кода на Котлине составляет приложение? Во-вторых, Котлин можно использовать как DSL и начать переписывать всё подряд на него.

Имеет смысл писать проект на Котлине целиком. — С моей точки зрения, ситуаций, когда нужно осмысленно мешать Джаву и Котлин, существует очень мало. Но надо сказать, что «Java2Kotlin»— ну так себе инструмент, не идеальный.
Может быть, если ты чувствуешь, что ты будешь переводить приложение на Котлин целиком, ты можешь сначала начать писать новые классы на Котлине и потом в какой-то момент начать конвертировать старые классы из Джавы в Котлин и ручками их подравнивать.

— Под «Java2Kotlin» ты имеешь в виду Ctrl C – Ctrl V в Идее между файлами?

— Да, но там еще есть какой-то отдельный шорткат, наверное.

— Кстати, я пытался когда-то для Скалы использовать именно Ctrl C – Ctrl V в Идее, но там получался редкостный трешняк в качестве результата.

Я пишу лучше. — Мне тоже не нравится, что делает Java2Kotlin. У тебя есть два пути: либо ты конвертируешь весь проект, особенно если он не очень большой, и потом ты исправляешь все неправильные места. Иногда с этого можно начать, конечно. Но тебе, наверное, захочется с чего-то начать.
Либо ты это делаешь по одному классику: переписывать руками очень долго, много механической работы.

— Не возникает ли там каких-то сложностей, связанных не с тупым синтаксисом, а со смысловой частью?

— Возникает, я про это расскажу в докладе.

Когда Котлин добавляется в проект, дальше растет его количество или падает? — Хорошо. Сколько должно быть Котлина, чтобы он начал всё пожирать?

Мы сразу писали приложение на Котлине, кроме одного случая. — У меня нет такого опыта. Ты ориентируешься в экосистеме плагинов к Идее?

— Немного.

Там есть какое-то хитрое сочетание клавиш, ты его вводишь, и у тебя возникает строка для подсказок, ты туда вводишь путь, и у тебя сам находится контроллер и метод, который за этот путь отвечает.
— Некоторое время назад мой друг, Слава Артемьев, написал сравнительно популярный плагин к Идее, который помогает ориентироваться в спринговых и ЕЕ-шных эндпоинтах.

— В Community Edition это, наверное, очень полезная штука.

— Оно и в Community Edition работает, и в Ultimate.

— В Ultimate не особо нужно, эта фича уже есть в Spring-плагине.

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

— В Спринг-плагине, кажется, есть вкладочка endpoints, но настолько хорошо она работает, я не знаю.

Она знает endpoint'ы, но разве она умеет удобно по ним искать?
— Так она же не маппится на конкретные урлы.

Ладно, я понял, этот плагин лучше.
— Нет, ты должен их листать.

Как обычно, более-менее нечувствительна к регистру и всё такое.
— Тут же штука, у которой как в Идее всё устроено, когда ты нажимаешь Shift-Shift-Shift, начинает что-то писать, Shift-Shift-Shift подсказывает тебе всё, что есть в Идее, а эта штука сама ищет тебе endpoint'ы и методы, отвечающие за урлы.

— А, то есть это Search Anywhere, только для урлов и эндпоинтов.

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

— К этому приводит именно введение Котлина или просто то, что ты включил голову?

Я не считаю, что, чтобы писать на Котлине или на Джаве, надо иметь много мозга.
— Мне кажется, что первое.

Там, в том числе в этом исследовании, показано, что улучшилось качество кода. — Я не про то. Выходит, что когда человек начинает писать на новом языке и он специально сделал такое осмысленное решение, то он и код начинает писать более осмысленно, и автоматически получается, что код у него лучше.
И мы с Барухом по этому поводу немного поспорили в кулуарах.

И редкие исключения. — Скорее, мой пример это опровергает, потому что, как ты понимаешь, плагин к Идее никто не начинает писать, не включая голову, потому что это штука, которой никто никогда не занимался, кроме людей, которые на этом специализируются. Но ты пытаешься сразу писать хорошо. Конечно, есть комьюнити-плагины. Там нет всех этих бесконечных Java-паззлеров, еще и Идея помогает. Нет, дело в том, что на Котлине проще писать хорошо. И всё такое. Если ты пишешь generic недостаточно широко, она тебе подскажет, что тут есть invariants, добавь ключевое слово in. Он, скорее, сам получается. На Котлине просто легче писать хороший код. Например, если вы пишете на Haskell, то как вы работаете с коллекцией? Опять же, есть редкие исключения. Вы говорите: map, fmap, фильтр и всё такое.

— На джавовских стримах то же самое.

Конечно, в Котлине есть замечательная штука — sequence. — Проблема вот в чем: если ты на Котлине попытаешься неэффективно работать с коллекцией, у тебя она будет каждый раз представляться как новая, будет в новый лист складываться. Они тут — то же самое, что в Скале.

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

— Можешь подробнее?

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

У тебя есть конвейер операций, ты в удобном тебе темпе обрабатываешь содержимое коллекции.
— Ты можешь это буферизованно делать, например.

В Джаве у нас есть не так много вариантов: мы либо пишем for-циклы с преобразованием, либо мы пишем оптимизированный for-цикл, где мы заранее считаем (и это было моим baseline), какие именно мы операции произведем над каждым элементом. — Более-менее да. Это можно делать на стримах, а в Котлине — двумя методами: sequence'ами и не sequence'ами. На самом деле мы умножаем на 2 и прибавляем 6 в этом случае. Мы создаем кучу ненужных коллекций и всё такое. Несиквенсами, понятно, получается очень медленно из-за дикого оверхеда на всем. Быстрее, чем стримы в джаве. А с сиквенсами работает быстро. Но главное, что с сиквенсами, если запускать под Граалем, у тебя результат улучшается до baseline.

— В смысле, до циклов?

— Да, до одного максимально-оптимального цикла.

— Мне кажется, это та штука, которую в GraalVM хотели сделать частью платной редакции.

В JDK10 с JVMCI оптимизация даже близко не так хороша, как в GraalVM EE, но заметно лучше, чем на обычном C2.
— Я тоже так думаю.

— Я-то думаю, ты пошел улучшил Community Edition до не-Community Edition, и думаю, что тебя вечером убьют.

Я, к сожалению, даже не смотрел код. — Нет. Я, конечно, вру в этом месте, но у меня нет времени.
Нет времени.

Исходя из твоей же терминологии 🙂
— У тебя нет мотивации!

— Поэтому я специально сказал, что я вру.

Поговорим на отвлеченную тему: как войти в айти. — Хорошо. Вопрос заключается в следующем: ты всегда работал программистом?
Тема животрепещущая, в том числе для наших читателей на Хабре.

По образованию я психолог в бизнесе. — Нет. И то, что я сейчас скажу, никаким другим людям, наверное, не подходит: когда я закончил учиться, я пошел работать сначала в техподдержку, а потом стал сисадмином, у меня неплохо получалось. Я закончил факультет психологии в Высшей Школы Экономики по специальности «психолог в бизнесе». Меньше, чем я получал админом. В 2008 году был кризис, меня сократили, и я стал искать работу, меня позвали попробовать пойти программистом за совсем небольшие деньги. Я стал программистом от безысходности.
Я пошел, попробовал, и случайно у меня получилось.

— А на чем ты программировал?

Java меня воткнула больше, чем C++ Builder, особенно учитывая то, что, когда я писал в C++ Builder, я вообще ничего не понимал. — Первые месяца 4 программировал на C++ Builder, а потом у нас там внутри открыли маленькие курсы по Java, на которые я, по-моему, ходил один, честно говоря. У меня там даже приложение написано, которое с базой работало. Я натаскивал иконочки и пытался связывать действия. Я уже не помню, как оно было написано, я просто знаю, что оно до сих пор работает.

— Там были компоненты — VCL, вот это вот.

Но с базой я работал реальными запросами, я даже их генерировал где-то там, собирал по каким-то правилам. — В общем, да. Сейчас бы я, наверное, поостерегся так писать.
Это было что-то страшное, у меня был один большой класс с окном и второй класс с SQL, который собирался и выполнялся.

— Особенно на C++.

На C++ нет какого-то стандарта, как принято, поэтому, в принципе, можешь делать, как хочешь. — Да на чем угодно, особенно на Java, тут так не принято. Хотя, когда ты собираешь интерфейсик в NetBeans, то видишь такую портянку кода, которую ты сам бы никогда не написал. А в Джаве всякие MVC. Там все эти GroupLayout или BorderLayout. Не потому, что плохо, просто очень сложно. Хорошо, что я десктоп давно не писал, меня бы уже не брали никуда как десктопо-писателя.
Я не могу их запомнить, они невероятно сложные, с моей точки зрения, до сих пор не понимаю, как это работает.

— А Джава на десктопе еще жива, кроме IDE-шек?

Я бы, наверное, сейчас выбрал какой-нибудь Electron.
— Спорный вопрос.

Тем более что ты можешь одновременно писать и на электроне, и на Java.
— Я бы тоже.

С моим-то языком всё опять-таки совсем просто: Котлин хорошо компилируется в JavaScript. — Я могу писать всё на Котлине, из этого генерируется электрон потом. Подключай библиотечки и всё.

— А с моим языком под названием GraalVM всё еще проще, ты можешь Electron скомпилировать Граалем и запускать JavaScript через полиглот-рантайм.

Если без шуток, ты, конечно, можешь. — Ты будешь вынужден страдать от джаваскрипта. У нас же есть Truffle-компилятор для JavaScript? На Nashorn ты мог сделать очень похожую вещь. Ты можешь сейчас то же самое продолжать не Насхорном, а Трюфелем.

А тут ты просто можешь скопипастить готовый Electron, и он у тебя запустится.
— Тут же вопрос в том, что, если у тебя Nashorn, ты должен руками стек собирать и мучаться.

— А ты уверен, что запустится?

— Я видел в чатике, как люди запускали старую версию Electron.

— А почему старую?

Их нужно постоянно выравнивать между собой.
— Там постоянно апается версия Node.js, и в Graal своя собственная версия Node.js, она не совсем без патчей.

— Все эти нейтив биндинги поддерживаются?

Но иногда они всё-таки нехорошо работают.
— Да.

Я взял целую пачку новых незнакомых технологий — Node.js, Electron Builder, SQLite и ORM к нему. — Я тут писал маленькое приложение на электроне для себя. Я засабмитил баг-репорт, сказал, что не работает. Я не знаю, будет ли это всё работать под Трюфелем, потому что кто знает — нейтив биндинги к SQLite — они еще недавно на 10й Ноде не собирались. И меньше чем через месяц они добавили поддержку.

— В целом, наверное, предполагается, что хороший код должен хорошо работать.

Так вот я лучше на Котлине. — Наверняка. Ты можешь собрать нормальное красивое приложение на Джаве, засунуть туда прямо JRE, обрезанную и кастрированную. С другой стороны, если Java FX, и, в принципе, наверное, с появлением 10-й Джавы всё становится не очень страшно. Не знаю, нужно ли это кому-то. Оставить только то, что тебе нужно — может, будет и неплохо. Я вообще не понимаю, нужен ли сейчас хоть кому-то вообще десктоп, кроме редких ситуаций.

— Есть набор кейсов, когда нужен десктоп и больше ничего другого.

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

Например, у тебя есть какой-то to do list, куда ты постоянно что-то записываешь. — Или у тебя какой-то desktop environment в операционной системе, и тебе хочется, чтобы у тебя была максимальная супер-отзывчивость. Главное, что, когда ты меняешь вкладки, ты меняешь контекст. Одно дело, когда ты открываешь браузер, переходишь на вкладку, тратишь время, чтобы это развернуть и переключиться. Либо у тебя просто хоткей на клавиатуре — ты нажимаешь F1, и у тебя всё быстро выползает.

Чтобы по-настоящему быстро и отзывчиво всё работало – это в терминальных CLI-приложениях. — Мне кажется, что правда жизни заключается в том, что для этого нужен терминал. Он умеет всё, в том числе считать за тебя приоритеты по заданным правилам.
Я это знаю, я использую Task Warrior, потому что он идеален.

То, что ты изучил синтаксис Джавы, не значит, что у тебя после этого какая-то работа будет. — Мы не договорили про «войти в айти». Что дальше делать?

— Ты слышал, что у меня нерелевантный опыт?

— Делись им дальше.

— У меня проблема, я вообще никогда в жизни джуниоров не нанимал.

Вот ты выучил синтаксис, дальше что?
— Но ты же был джуном когда-то.

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

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

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

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

Я зациклен на деньгах, но очень ограниченно. — Работать, пока интересно и пока есть какие-то перспективы. Обычно потребности со временем растут. Денег должны платить столько, чтобы хватало на все твои потребности. В общем не то чтобы я просто гоняюсь за деньгами. У меня приближается третий ребенок, поэтому потребности еще немного вырастут. На следующую работу я иду даже с понижением по деньгам.

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

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

Ты знаешь столько всяких интересных вещей и можешь это рассказать. — Кстати! Почему же ты не бываешь у нас на конференциях каждый год с каким-нибудь новым докладом?

— Мне не кажется, что я знаю достаточно, чтобы много рассказывать.

— Но ты всё-таки пришел!

Крайне мало кто реально пишет бэкенд на Котлине. — Случайно получилось так, что у меня есть более-менее уникальная экспертиза для отрасли. И у них, вероятно, и нет вот этой жилки евангелизма. Похоже, что никто из них не горит желанием рассказывать об этом. Поэтому мне, конечно, интересно. У меня всегда есть желание научить других правильно жить (или хотя бы попытаться). Более того, в этом докладе в какой-то степени заинтересован я сам, потому что следующий работодатель, к которому я приду и попрошу писать на Котлине, скажет: «С чего бы?», я скажу, что вот, я делал доклад на Joker, давайте посмотрим.

— Как сформулировать тот момент, когда ты понимаешь, что тебе экспертности хватает идти делать доклад?

Доклад делается не из-за того, что у тебя есть экспертность, а из-за того, что у тебя есть какой-то опыт и желание о нем рассказать. — Никак. А вот осознанная тема «для рассказать» у меня возникла не так давно. Желание рассказать у меня есть уже с первого раза, когда я попал на JPoint. Такая тема, чтобы можно было минут 45 рассказывать.

Почему они нужны? — Почему конференции? Из того, что ты вообще на них ходишь, получается, что они тебе нужны.

— Нет, из того, что я на них хожу, получается только то, что я на них хожу.

— Но тебе же они зачем-то нужны?

Я не уверен, что я на конференции хожу за информацией. — Не знаю, насколько честно я готов отвечать на этот вопрос. В некотором плане, я хожу на конференции, чтобы ты меня знал.

— Это нормальная идея.

Мне полезно вообще, чтобы рынок меня знал просто с точки зрения моей стоимости, особенно если я произвожу хорошее впечатление. — Когда я говорю «ты», имеется в виду еще куча людей, которые меня запоминают. Я постоянно нахожусь в поиске более интересной работы. А я стараюсь это делать, потому что я на самом деле вроде бы не так мало знаю, и мне постоянно не хватает интересной работы. Крайне редко появляется что-то, что кажется более интересным, чем то, что есть у меня сейчас.

Такой возможности нет вообще нигде. С другой стороны, я хожу на конференции, чтобы лазить в кишочки. Да, я вряд ли смогу использовать эти знания, но это просто интересно. Я ходил слушать про то, как устроен Azul Zing, потому что это интересно. У меня еще проблема: я достаточно мало читаю книжки. Это вряд ли можно прочитать в какой-то книжке. Я, наверное, один из немногих хоть сколько-то серьезных технарей, которые вот так вот живут. Я предпочитаю читать художественную литературу. А в референсах и вайтпеперах редко бывает такая информация.
Я читаю референсы, вайтпеперы, но почти никогда не читаю книги.

— Да и в книгах не так часто такая информация бывает.

Последняя значимая книжка, которую я прочел по Java — «Java Concurrency in Practice», а по Java экосистеме — «High-Performance Java Persistence», Vlad Mihalcea (это очень хорошая книжка). — Книги мне прям тяжело даются, честно говоря. Но обычно это очень тяжелое чтение, и мне не дается.

— Стоит ли читать доку Джавы?

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

— Наверное, я бы так, кстати, и сделал.

— Это замечательный путь, я ничего против не имею.

— Мне тоже очень интересно, как делают люди типа тебя, которые сразу могут нормально написать.

Это очень важно. — Нет задачи написать нормально, есть задача написать. Когда я чему-то учусь, я не могу просто осмыслить кучу информации и потом пойти писать. Вообще задача написать нормально возникает далеко не всегда, особенно, когда ты учишься. Может быть, ты знаешь, что я иногда пишу подкаст. Я всегда начинаю с экспериментов. У меня нет задачи что-то прочитать и, значит, я экономлю кучу времени, потому что я сразу сажусь и начинаю использовать какую-то технологию, либо в рабочем проекте, либо в каком-то домашнем, в тестовом. В первом выпуске, который мы записали и опубликовали, я рассказывал о том, что я успеваю всё изучать только потому, что я никогда не откладываю это на потом. Но для начала я смогу рассказывать, что я понимаю, как этим пользоваться. Потом, если понадобится, я углублюсь. Спрингом я начал пользоваться до того, как понял, как он работает. На следующем этапе я могу рассказывать, что я знаю, как это работает. Наверное, лет за 6.

Увидимся на Joker, обязательно приду послушать твой доклад.
— Кажется, нам пора сворачиваться 🙂 Спасибо большое!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть