JavaGovno — различия между версиями

Текущая версия на 00:26, 9 февраля 2019

Java - попытка поиска альтернативы / За что я не люблю Java

Мысли - Много минусов

 - СИСЕК НЕТ
 - Что на ней писать-то?
   - Там, где нужно быстро - пишут на C++ (игры-биржи-системный софт)
     - Ибо JVM-то сама по себе быстрая, НО! У неё же как минимум GC. А ещё из-за ориентации на многопоточность трудно сделать shared-nothing / thread-per-core
   - Там, где нужно много сети - пишут на том, что умеет работать как событийная машина
   - Там, где более-менее пофиг - есть куча альтернатив. Скриптота, Go...
   - ML - питон, юля (а был хадуп, да. но оказался слегка тормоз ну и писать неудобно)
   - Десктоп - всё-таки в основном пишут нативно
   - Ну, мобилы... да - тут зря оракл судится, Андроид спас яву
   - Остаётся "энтерпрайз" / "банки". Но что такое "энтерпрайз"? Я пока знаю только одну характеристику и она не хорошая - это те компании, в которых всё плохо, медленно, легаси и так далее. Качество кода? Не... чот не видел. Может где-то есть страна единорогов, но...
 - С другой - там, где не нужно - есть дохрена альтернатив, причём не только скриптота - ещё Go
 - Событийной машины нет [ссылки на извраты: quasar, ea-async - но специфично и не очень удобно - драйверы к БД - отдельный изврат и т.п.] => проигрывает JS и Go (да-да, nodejs тащит 1млн соединений на 1 хосте)
 - Зато куча херни для многопоточности, с которой можно огрести много весёлых багов
 - Встроенного синтаксического сахара нет [и видимо не будет]. Ни async/await, ни перегрузки, ни JSON, ни хотя бы просто встроенного в синтаксис хеша. Тем, кто не писал на чём-то другом оно, может, и не надо. Но, простите, в C++ я могу сказать json["x"] = 1. А в java нет.
 - Много легаси. Аппликейшн серверы (неудачная попытка шаред хостинга на яве), IBM MQ, EJB, куча спецификаций и т.д и т.п. Потому что сделали ещё вот тогда и - ну, работает, не переписывать же
 - Причём с другой стороны матёрым чувакам, которые ещё кодили на EJB - наоборот смешно смотреть на новодел, потому что вот это всё ещё вот тогда в 2000 было уже возможно
 - С одной стороны, толстое встроенное API, которое тащат от версии к версии и тяжело развивают с сохранением совместимости
 - С другой - оно хоть толстое, но его не достаточно для написания веб-приложений!
 - Поэтому любое приложение тащит сразу 50-100 мб зависимостей
 - Разделяемых библиотек нет
   - При этом хаос с версиями библиотек не хуже, чем в NPM
   - Можно бесконечно смотреть на три вещи - как горит огонь, как течёт вода и как работает Maven
   - Системный софт вообще не попишешь, там без разделяемости никак
 - Один из вариантов это был бы AOT. Его нет.
   - В C# есть (GAC)
   - В Dalvik/ART есть
   - А в яве нет
 - Поэтому ЖОР ПАМЯТИ!
 - На андроиде, пока не было AOT, вообще была ЗИГОТА (мега-костыль)
 - На самом деле есть OSGi. Но специфичная вещь и редко кто её юзает
 - А, ещё один важный момент
   - К яве и C# не пишутся (точнее, плохо пишутся) внешние биндинги. Был бы Android Framework на C - можно было бы кодить на любых языках. Я бы кодил)
 - Поэтому же медленный запуск
   - Правда, смотрите на nodejs (V8) и учитесь скорости - он и на быстрый старт, и на JIT оптимизирован. Хотя чему-то и он, конечно, у JVM сам научился
 - Память течёт, как и везде (кроме ПХП) или хуже
 - Разработчиков нет/дороже (пока в вилларибо настраивают сборку, в виллабаджо уже сделали MVP). Ну тут некоторое лукавство - для разработчика-то это плюс :)
 - ...и хорошим - грустно. В итоге вместо тупого монолита на ПХП появляются микросервисы, рэббиты, синхронизаторы баз данных и так далее...
 - Из-за типизации - сплошной ORM. Из-за сплошного ORM - никто ни хрена не знает, как работает СУБД. То есть средний уровень так себе.
 - Ценность готового софта на яве во многом сомнительная
   - Странная культура разработки. Крупные "куски софта" - довольно страшные
   - DDD... что-то там ещё DD...
   - Из свежего есть правда эластик и логстеш. Но логстеш СИЛЬНО ругают за жор ресурсов.
 - А вот например Go
   - Веб-френдли: встроенные массив и хеш, встроенная JSON сериализация
   - Эффективная и простая многопоточность - goroutine-ы
   - Умеет как статическую, так и динамическую сборку
   - Совместим с C библиотеками
   - Интересные решения на тему наследования
   - Популярен и в вебе, и для системного софта
   - Нет эксепшнов (плохо), нет генериков (где-то хорошо, где-то плохо)
   - Синтаксис немного безумный
 - А вот например node.js
   - Самый быстрый движок из всех интерпретируемых языков - "нативные модули не нужны"
   - "First-class" событийная машина, async/await
   - Нейтральный C-подобный синтаксис
   - Возможность сборки в том числе серверного кода в единый bundle (был опыт по превращению ~500 мб зависимостей в 1 12 мб файл)
 - А например PHP
   - Узкоспециализирован, но очень удобен, для веба
   - Для написания веб-приложения достаточно встроенных возможностей. Зависимости в 90% случаев не нужны ВООБЩЕ
   - Кардинально решены проблема утечек памяти, расхода ресурсов
   - Кардинально другой подход к работе приложения (отсутствие прогрева)
   - Жора памяти тоже нет
   - Полный "serverless" ещё со времён шаред хостингов

- Засилье Spring

 - Не от хорошей жизни: по сути, спринг путём грязных хаков добавляет в яву динамику (связывания в рантайме), которой там так не хватает
 - И синтаксического сахара - местами и имхо некрасиво.
 - Даже сами концепции DI/IoC в первую очередь популярны именно в яве и C#. Разработчикам ядра Linux про это расскажите - обсмеют
 - "А как нам протестить один класс отдельно, если там статические ссылки на другие"... Когда это в PHP было проблемой? Убей не пойму
 - "Изолента-ориентед-программинг". Ощущение, как будто насовываешь в разные места кусочки изоленты и они в рантайме как-то в итоге слипаются
 - Всё это ценой ЕЩЁ БОЛЬШЕГО времени запуска, может и пять минут быть. Цикл "code-test" СЛЕГКА замедляется

- IT-фэшн - мода на микросервисы (уже подыхает)

 - Микросервисы, естественно, не обязывают писать на яве
 - Однако МНОГИЕ адепты рассказывают про микросервисы именно в контексте явы
   - Либо у них была ява и монолит стал говном
   - Либо у них была ява, всем надоело на ней писать и захотели писать на питоне и получили микросервисы
 - Есть целые Spring Cloud-ы про микросервисы. В других языках такого нет! - видимо, не нужно
 - На практике тоже не раз слышал про применение MSA именно от тех, кто работает с явой
 - Есть подозрение, что постулат "толстый монолит превращается в говно" - тоже исходит от них - видимо, это ява-проблемы
 - При этом микросервисы на яве - совсем не микро. Даже vert.x, даже spark тянут с собой метров по 100 зависимостей.
 - Не, никто не спорит - можно прикольно поупражняться и потом сходить на конференцию рассказать про свой опыт. Были доклады от Одноглазников, которые изобрели свой сериализатор, чтобы гонять данные юзеров между (микро?)сервисом юзеров и другими сервисами
 - Поправка - если вы Гугл или Фейсбук - то микросервисы у вас, конечно, возникнут сами по себе
 - Если "сами по себе" они не возникают - они вам не нужны. поупражняться можно, но это тупо затраты в никуда (на инфраструктуру...).
 - Даже Фаулер говорит "monolith first".
 - Единственная польза - продавать это другим таким же бедолагам.
 - "А если один сервис на спринге всю память сожрёт..." - ну ой. Не пишите на спринге, пишите на пхп. Точно не сожрёт.
 - Подобный опыт у нашей компании есть на практике. Вдаваться в детали не буду - наверное, нельзя - но, в общем, с MSA может быть на ПОРЯДОК дороже, чем без, при отсутствии каких-либо выгод.

- Попытка улучшить жизнь: vert.x

 - Что это такое
 - Попробовали на этом написать прототип новой системы
 - Увы, java IMDG - говно 100%, спросите БДСМщика (Jepsen)
 - Попытка межсервисной коммуникации по "шыне" умерла при первой же подаче нагрузки
 - Шынные сервисы не дружат с vertx-web
 - Библиотеки непривычные, Quasar кривой
 - Многоязыковость - маразм (зачем писать на яве, если потом писать на руби)
 - ea-async - не очень удобно, т.к. почти "лестница колбэков"
 - Ну и - явистам всё это не нужно, им и со спрингом и 5 минутами запуска хорошо
 - Остальным тоже не нужно, т.к. им не нужна ява (картинка "совершенство не требует доработок")
 - Итог: штука интересная, но на практике не прижилась
 - Возможно, где-то может быть полезно, само существование событийной машины - это уже что-то
 - Ну и если я что-то буду писать на яве - велика вероятность, что именно на вертексе

- Ещё есть Spark - http://java-source.net - сплошные инструменты

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

Я там записал какой-то поток мыслей, но это не тезисы, конечно... Если кратко описать суть доклада, то как-то так:

Доклад служит высокой цели расширения кругозора слушателей и рассказывает про нашу попытку что-то изменить в нашем мире ява-разработки. Зачем менять? Ну, все же знают, что Алиса сказала про IT - нужно бежать очень-очень быстро, чтобы только остаться на месте. Спойлер: далеко убежать не удалось, но опыт был интересным.

Первая часть доклада - фичи языка/платформы. Почему на яве не писать системный софт? Откуда в андроиде "зигота"? Кто быстрее - ява или яваскрипт? Есть ли жизнь за пределами Spring-а? Почему PHP-шники не хотят писать на яве? Из-за чего вообще "обидно", чего так не хватает при Java-программировании? Что-то из этого поправимо сейчас? А есть ли шансы, что поправится в будущем?

Вторая часть - IT-мода на микросервисные архитектуры - к счастью, уже проходящая. Главный вопрос здесь в том, какой урок из этой "моды" стоит нам вынести.

Ну и напоследок вас ждёт краткий рассказ про vert.x - асинхронный фреймворк нового поколения от Eclipse - и нашу попытку улучшить им себе жизнь.