65 айтишников задержаны.
33 — неизвестно где.
21 вышли на свободу.

«Кому это нужно, когда есть православная 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. Также это плюс для хайринга разработчиков, так как кандидаты отдают предпочтение таким проектам. 

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

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

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

Криптобиржа Прокопени выделит $100 тысяч пострадавшим на акциях
Криптобиржа Прокопени выделит $100 тысяч пострадавшим на акциях
Криптобиржа Прокопени выделит $100 тысяч пострадавшим на акциях
6 комментариев
«Доля нечестных протоколов — 30%». «Голос» опубликовал промежуточные итоги
«Доля нечестных протоколов — 30%». «Голос» опубликовал промежуточные итоги
«Доля нечестных протоколов — 30%». «Голос» опубликовал промежуточные итоги
2000 + Аркадий Добкин. Глава EPAM присоединился к обращению айтишников
2000 + Аркадий Добкин. Глава EPAM присоединился к обращению айтишников
2000 + Аркадий Добкин. Глава EPAM присоединился к обращению айтишников
3 комментария
Руководство ADANI призвало прекратить насилие и освободить граждан
Руководство ADANI призвало прекратить насилие и освободить граждан
Руководство ADANI призвало прекратить насилие и освободить граждан

Обсуждение

amok
amok Team Lead в Ergalio
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.

0

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

0

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

0

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

1

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

0

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

4

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

george
george Engineer в EIS Group
1

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

1

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

2

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

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

george
george Engineer в EIS Group
0

del

1

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

Спасибо! 

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

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