«Кому это нужно, когда есть православная Java?» Почему компании (не) переходят на Kotlin

21 комментарий
«Кому это нужно, когда есть православная Java?» Почему компании (не) переходят на Kotlin

В октябре прошлого года компании хвастали переходом с Java на Kotlin. Но не всё гладко. Официально компании не хотят комментировать ситуацию, но одни свернули эксперимент, другие только поддерживают существующий проект, третьи провели исследование и сделали вывод о нецелесообразности перехода на Kotlin. Пробуем выяснить у разработчиков, что не так с языком от JetBrains.

«Возможно, ещё раз попробуем, но только не знаю, когда»

Участник Belarus Kotlin User Group и идейный вдохновитель School.kt Кирилл Розов говорит: 

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

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

Кирилл отмечает, что хуже всего компании переходят на Kotlin в бэкэнд-разработке: «уж очень она неповоротлива».

Руководитель юнита в PandaDoc Сергей Плевко говорит, что изначально в их компании бэкенд делали на Python, затем два года назад «было принято решение внести какое-то разнообразие — пусть будет ещё и Java».

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

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

Что было здорово.

  1. Начать писать на Kotlin джависту довольно легко. Открыл мануал, прочитал три-пять страниц, и можно делать.
  2. Пришлась по душе идея с конвертацией целых классов на Java в Kotlin-код. 

Что было не очень хорошо.

  1. В Java практически не встречается багов, так работает среда разработки, а на Kotlin постоянно возникали какие-то мелкие нестыковки. Они фиксились быстро, за час можно было разобраться, в чём проблема. Но тратить целый час на что-то, что не касается твоей непосредственной работы, — согласитесь, неприятно. 
  2. Сам процесс работы со средой немного подтормаживает. Но если на Java он не раздражает, то на Kotlin процессор постоянно грузится и грузится — и ты почему-то наполняешься негативом: «Ну что так медленно!» Хотя, возможно, это связано с нашим проектом и с какими-то нашими библиотеками. 

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

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

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

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

По теме
Все материалы по теме

«Компаниям не интересны новые языки. Инициатива идёт снизу»

Лидер белорусской Kotlin User Group Руслан Ибрагимов говорит, что ему известно о нескольких случаях, когда компании поднимали вопрос о переходе с Java на Kotlin. И отказывались от этой идеи. 

— Причины две. Во-первых, все они посчитали, что Kotlin не даёт достаточно преимуществ перед Java. А во-вторых, сейчас одна из компаний находится в процессе миграции со своих собственных серверов на Google Cloud, и её руководство не хотело накладывать один большой переход на другой. 

Хотелось бы, конечно, детальнее познакомиться с результатами их внутреннего ресёрча — но, увы. Могу добавить лишь, что они даже не пробовали написать что-то на Kotlin — просто собрали «за» и «против» в теории. Знаю также, что в Onde сейчас проверяют идею полностью перевести систему на Kotlin, используя Kotlin Native для iOS и Kotlin JS для Web приложений, вместо аналогичных компиляторов для Java.

Тенденция такова, что компаниям в большинстве своём не интересны новые языки. Инициатива скорее идёт снизу: разработчики знакомятся с языком, влюбляются — и пытаются донести до команды и менеджеров, что «есть такой классный Kotlin, мы хотели бы писать на нём». В ряде случаев к ним прислушиваются.

Разработка на Kotlin, кстати, — плюс для многих кандидатов на вакансию программиста в компании: я, например, ни за какие «коврижки» не променяю Kotlin на Java. 

«Разработчики Senior+ воспринимают любой новый язык как что-то одноразовое»

Бэкэнд-разработчик одной из компаний (пожелал остаться анонимным) рассказывает:

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

Вторая причина заключается в том, что за всё время существования JVM-платформы широкое распространение получил только Java. А Groovy, Scala и другие языки, пережив непродолжительный всплеск в своём развитии, потихоньку угасли. Памятуя об этом, большинство разработчиков уровня Senior+ (а они могут быть как среди менеджеров, так и на стороне заказчика) воспринимают любой новый язык как что-то одноразовое, о чём через неделю все забудут. Такие люди уже всё для себя решили — и какие бы ни были у вас аргументы, в споре они всегда дают универсальный ответ: «У меня есть Spring, Guava и так далее».

Не знаю, почему так получилось (хотя в душе догадываюсь), но закоренелые бэкенд-разработчики даже мегапопулярные языки, как JavaScript, воспринимают как что-то несерьёзное. А Node.Js или Kotlin — да кому это нужно, когда есть православная Java?! И хотя с приходом Serverless часть этих людей потихоньку начинает переобуваться, процесс этот очень медленный.

Ещё один собеседник dev.by отметил, что «жирный плюс к Java добавляют ещё в университете — ведь Kotlin не изучают в вузах». Руслан Ибрагимов соглашается с этим, но с оговоркой:

— Университет даёт базу, но в реальной жизни мы очень часто используем другие технологии. А с другой стороны те же JetBrains серьёзно вкладываются в образование — что очень заметно в России: у них есть свои курсы по Kotlin в техвузах. Возможно, и у нас такие появятся. 

«Плюс для хайринга разработчиков: кандидаты отдают предпочтение таким проектам» 

Полгода назад разработчики Bamboo Apps рассказывали, что, когда выбирали язык для проекта от Jaguar Land Rover «Kotlin ещё был „тёмной лошадкой“ — заказчик решил не рисковать». Тем не менее команда сделала задел для перехода.

СТО компании Сергей Мищенко говорит, что «вопрос миграции затем поднимался несколько раз». А сам переход на Kotlin начал активно обсуждаться в конце зимы, перед релизом. Сейчас, говорит Сергей, компания приняла окончательное решение. Он признаётся, что тому немало способствовало заявление «Kotlin — first» для разработки под Android на Google I/O: 

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

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

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
1 комментарий
На студента БГУИР завели уголовное дело. Он уехал
На студента БГУИР завели уголовное дело. Он уехал
На студента БГУИР завели уголовное дело. Он уехал
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
1 комментарий
Чемоданова: работник госпредприятия «сливал» данные силовиков
Чемоданова: работник госпредприятия «сливал» данные силовиков
Чемоданова: работник госпредприятия «сливал» данные силовиков
7 комментариев

Обсуждение

amok
amok Team Lead в 2018-05-01
5

Интересная в PandDoc аргументация принятия технических решений....

-2

Зато по теме топика конкретно отметили по пунктам "за" и "против" с тех. точки зрения.

5

Просто опытные менеджеры знают, что senior+ разработчики топят за переход на "очередной убийца Java" на платформе JVM лишь для новой строчки в своем CV и возможности продать себя дороже, судьба проекта а тем более бизнеса заказчика их мало волнует

4

> судьба проекта а тем более бизнеса заказчика их мало волнует
Странно, да?

А вообще разрешить переписывать на Kotlin/Swift - это способ кинуть косточку заскучавшим программистам - считай, соцпакет, ну и привлекательнее вакансии для новых гребцов.

2

Жаль что у нас талантливых инженеров несравнимо больше чем менеджеров.

4

Все намного проще, не стоит думать что большинство тех кто себя называет Senior+ это некие светила понимающие отличие в языках программирования и как написать что-то сильно сложнее CRUD.
Уже давно моя практика показала что и Java они знаю кое-как, по верхам. Просто сложность проектов в которых они участвуют такова что таких знаний им хватает слихвой. А поскольку мир за пределами своих простых задач из типичной аутсорсинговой компании они не видели, то конечно же отностительно своего ареала являются элитой. Но в этом ничего предосудительного я не вижу, такова реальность.
Java в целом хороший язык, просто есть языки ещё лучше. Минусы Java в том что на сегодня язык можно считать достаточно низкоуровневым и многословным, что заставляет тратить время на решение вопросов которые уже решены синтаксисом других языков. Где то это не критично, а где то создает значительную сложность проекту. Библиотеки на Java чрезмерно раздуты. Тот же Spring со своим мануала по 1000+ страниц и столько же по модулям. Это просто монстр. Некоторые решения на Spring которые описываются на 10+ страницах и множеством классов, в других языках решаются "одной" функцией.
Но Koltin это не панацея. Он просто чуть лучше Java.
> Кирилл отмечает, что хуже всего компании переходят на Kotlin в бэкэнд-разработке: «уж очень она неповоротлива».
И это понятно. Те кому хотелось больше мозговой деятельности уже давно пишут на Scala. А те кто хотел скорости и результата на Clojure. Именно эти люди и тянут проекты на новые языки. В бэкэнде они в основном уже ушли от Java, тянуть на Kotlin просто некому и не целесообразно т.к. и Scala и Clojure на порядок превосходят Kotlin во всех отношениях. Но на Android ситуация иная, там из-за специфики платформы нет возможности перейти на Clojure или Scala, и нишу отлично занял Kotlin.
> Идея избавления от нулпоинтеров лично мне не очень понятна — это какая-то борьба с ветряными мельницами. И я бы не сказал, что проблема стоит так остро, что её нужно прямо «решать-решать».
Это чисто junior проблема, у меня этот аргумент всегда так же вызывает удивление. По сравнению с другими проблемами, NPE это где-то на уровне статистической погрешности. Но она почему то является важной догмой в среде проповедников Koltin.)

2

>А те кто хотел скорости и результата на Clojure

а что, есть такие, кто не хочет? И как вы скоростями то меряетесь, кто быстрее алгоритм сортировки напишет что ли?) Скорость разработки (imho) слабо зависит от языка, если речь идет о проверенном стеке. За то сильно зависит от уровня владения стеком dev команды и компетентности менеджеров (организации).

-1

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

4

Уау-уау, потише. Вы меня запугали своим профессионализмом. Вы "попробовали" писать на основных языках JVM. Хорошо. Но видите ли, ПРОБОВАТЬ и ВЛАДЕТЬ - это не одно и то же. Такие быстронаписатели доводят проект до ручки, ставят галочку в CV что они овладели технологией и валят дальше. А ты остаешься наедине с тоннами разминочного кода и отсутствием специалистов, готовых разгребать это. И на проде это ооочень быстро проясняется, к сожалению.
Совет. Не бойтесь казаться глупым. Человек, который боится этого глуп by default.

mr-smith
mr-smith Developer в Ближний Космос
0

Угу, я частенько читаю от "профи": "Я за 3 года сменил 4 проекта, 5 языков программирования" подразумевая свою крутость. Хотя на проектах потом остаются те, кто разгребает все это быстронаписанное и малограмотное. В любом деле нужен в первую очередь опыт - а опыт это время.

0

Отнять рынок у состоявшихся Python, Java, nodejs - это задача на грани фантастики. Инеграция IDE и языка - это не то преимущество, которое позволит это сделать.

0

В двух словах - "почему-то" и "не захотелось"

1

Люблю, когда говорят про "недостаточность преимуществ и плюсов". Ребята с квитанциями на почте примерно так же рассуждают.

0

Вспоминаются различные комические персонажи которых встречал в жизни, утверждающих что математика не нужна они и так без неё отлично живут.)

4

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

george
george Engineer в EIS
1

Но с третьей стороны приятно, когда говоришь коллеге "дерево" и он понимает, что речь идёт о связном ациклическом графе :)

1

Типа "Вася, как ты это написал? Ну, ты, и дерево!"

2

Многие на работе и без знания программирования обходятся, что уж там математика...

На самом деле на большинстве проектов вершина знаний -- это какой-нибудь Linked List или там с большего понимать, как HashMap работает. Поэтому я бы сказал, что на самом деле не особо надо.

george
george Engineer в EIS
0

del

mr-smith
mr-smith Developer в Ближний Космос
1

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

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже