13 521
правка
Изменения
Новая страница: «Java - попытка поиска альтернативы / За что я не люблю Java Мысли - Много минусов - СИСЕК НЕТ…»
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
Вы вроде говорили, что там достаточно кратких тезисов для дальнейшего обсуждения.
Я там записал какой-то поток мыслей, но это не тезисы, конечно... Если кратко описать суть доклада, то как-то так:
Доклад служит высокой цели расширения кругозора слушателей и рассказывает про нашу попытку что-то изменить в нашем мире ява-разработки. Зачем менять? Ну, все же знают, что Алиса сказала про IT - нужно бежать очень-очень быстро, чтобы только остаться на месте. Спойлер: далеко убежать не удалось, но опыт был интересным.
Первая часть доклада - фичи языка/платформы. Почему на яве не писать системный софт? Откуда в андроиде "зигота"? Кто быстрее - ява или яваскрипт? Есть ли жизнь за пределами Spring-а? Почему PHP-шники не хотят писать на яве? Из-за чего вообще "обидно", чего так не хватает при Java-программировании? Что-то из этого поправимо сейчас? А есть ли шансы, что поправится в будущем?
Вторая часть - IT-мода на микросервисные архитектуры - к счастью, уже проходящая. Главный вопрос здесь в том, какой урок из этой "моды" стоит нам вынести.
Ну и напоследок вас ждёт краткий рассказ про vert.x - асинхронный фреймворк нового поколения от Eclipse - и нашу попытку улучшить им себе жизнь.
Мысли
- Много минусов
- СИСЕК НЕТ
- Что на ней писать-то?
- Там, где нужно быстро - пишут на 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
Вы вроде говорили, что там достаточно кратких тезисов для дальнейшего обсуждения.
Я там записал какой-то поток мыслей, но это не тезисы, конечно... Если кратко описать суть доклада, то как-то так:
Доклад служит высокой цели расширения кругозора слушателей и рассказывает про нашу попытку что-то изменить в нашем мире ява-разработки. Зачем менять? Ну, все же знают, что Алиса сказала про IT - нужно бежать очень-очень быстро, чтобы только остаться на месте. Спойлер: далеко убежать не удалось, но опыт был интересным.
Первая часть доклада - фичи языка/платформы. Почему на яве не писать системный софт? Откуда в андроиде "зигота"? Кто быстрее - ява или яваскрипт? Есть ли жизнь за пределами Spring-а? Почему PHP-шники не хотят писать на яве? Из-за чего вообще "обидно", чего так не хватает при Java-программировании? Что-то из этого поправимо сейчас? А есть ли шансы, что поправится в будущем?
Вторая часть - IT-мода на микросервисные архитектуры - к счастью, уже проходящая. Главный вопрос здесь в том, какой урок из этой "моды" стоит нам вынести.
Ну и напоследок вас ждёт краткий рассказ про vert.x - асинхронный фреймворк нового поколения от Eclipse - и нашу попытку улучшить им себе жизнь.