Недавно, 6 мая этого года, в OpenJDK вошёл JEP 425, который добавит к Java 19 в качестве превью-фичи Виртуальные треды.
Пожалуй, этот JEP — самое большое изменение семантики языка после появления Дженериков. Его масштабы трудно оценить. Для начала попробуем прикинуть, как оно может отразиться на нашей зарплате.
Рынок труда JDK экосистемы
Посмотрим на график ниже. Он основан на данных опросов сайта StackOverflow за 2020 и 2021 годы с количеством участников в 34 и 47 тысяч соответственно. Отображены данные, которые касаются языков экосистемы JDK: Clojure, Scala, Kotlin и Java; а также языков C# и F# экосистемы DotNet.
По оси X отложен процент участников опроса, который указал конкретный язык программирования (ЯП) в качестве основного. За точку отсчёта в 100% взяты джависты.
По оси Y отложена медиана годовой зарплаты. Это данные глобального мирового рынка труда, а не какой-то отдельной страны. Точнее, той его части, которая оказалась представлена в опросе на StackOverflow.
Тенденция понятна. Слева и вверху графика расположились языки программирования, позиции которых оплачиваются хорошо, но такую работу трудно найти. Справа и внизу находятся языки, которые оплачиваются похуже, зато они лидируют на рынке труда. Тренд иллюстрируют кривые для результатов 2020 и 2021 годов в JDK. Данные C# и F# добавлены на график для сравнения.
Чем вызван такой разрыв в зарплатах? Да, программировать на Clojure и Scala сложнее, чем на Java. Однако не всегда сложность монетизируется. Теоретические исследования редко финансируются бизнесом. Какую практическую пользу приносит разработка на Scala и Clojure, что её ценят так высоко?
«Точка Нетфликса»
Готовность бизнеса оплачивать головоломную работу объясняет концепция «Точки Нетфликса» за авторством Томаша Нуркевича. Томаш разделяет серверное программирование на два сорта: блокирующее и реактивное. О содержании терминов и чем одно отличается от другого мы поговорим позже.
Стоимость разработки и эксплуатации распадается в представлении Нуркевича на три составляющие: разработка, железо и поддержка. Затраты меняются при развитии: этап малой компании, стартап или большое предприятие. Для малой компании блокирующий подход в целом может стоить где-то вчетверо дешевле реактивного. А по мере роста предприятия стоимость разработки блокирующим способом увеличивается быстрее, чем реактивная альтернатива.
В какой-то момент на этапе зрелого стартапа («точка Нетфликса» в терминологии Нуркевича) реактивный подход становится дешевле блокирующего. Далее затратная на старте технология экономит средства компании.
Обратим внимание на соотношение между составляющими внутри выбранного подхода. В случае блокирующего приложения стоимость железа совпадает с ценой разработки, а стоимость поддержки много меньше этой пары. Разбираться с ошибками и отлаживать блокирующий код легко. Вместе с тем в проекте быстро накапливается сложность. Блокирующий код плохо приспособлен для композиции по фичам и масштабирования.
В случае реактивного приложения стоимость поддержки сравнима с ценой разработки. При рефакторинге кода легко ошибиться. Стектрейсы недоступны. Разобраться с ошибкой бывает очень непросто. Цена железа составляет меньшую долю стоимости и почти не меняется. Код хорошо масштабируется.
Авторская ремарка
Обратите внимание на различие в стоимости железа между подходами в правой части графика. Там двадцатикратная разница! Может быть Томаш Нуркевич её преувеличил?
Мой практический опыт подтверждает оценки Томаша. Разница в стоимости на графике эквивалентна разнице в пропускной способности для одной и той же конфигурации железа. Группа разработчиков «Юзтеха» (и я в их числе) создаёт следующую версию российской Системы межведомственного электронного взаимодействия (СМЭВ). Про нынешнюю версию (СМЭВ-3) уже много написано на Хабре. На предварительных испытаниях наша версия показывает производительность на два порядка большую, чем СМЭВ-3. Нуркевич не обманывает.
Заключительные тезисы
Рассмотренные материалы приводят нас к выводам, которые я изложу здесь в виде тезисов и раскрою в продолжении этой заметки.
Неадекватность мейнстрима
Обычные в нашей отрасли языки серверного программирования — неадекватные. Созданный с помощью языка продукт либо неэффективно работает с железом, либо невероятно сложен в разработке и поддержке. Как мы дошли до жизни такой и как Loom обещает это изменить — увидим в продолжении.
Слоган Loom
Проект Loom выдвигает лозунг «Программировать как будто синхронно, работать как будто асинхронно» (Code like sync, work like async). Экономический аспект лозунга в том, чтобы объединить все сильные стороны блокирующего и реактивного подхода: дешёвую разработку и поддержку, высокоэффективное использование железа, возможность масштабирования. Достижимы ли эти обещания? Посмотрим в продолжении.
Какое мне дело до Loom?
Если вы работаете в старой доброй Java блокирующим способом, то у вас есть хороший шанс повысить с помощью новой фичи эффективность работы с железом. Конечно, от этого ваша компания не превратится в Нетфликс, но расходы на железо сократит. А это неплохой повод для повышения зарплаты.
Чем Loom может помочь экосистеме JDK в целом, тоже разберём в продолжении заметки.
