Комментарии 52
Насколько я помню, обновлять/устанавливать сам XCode не обязательно — достаточно наличия XCode Command Line Tools. А они, в свою очередь, занимают аж 158 МБ (пруф). Основную массу и у рубей, и у ноды, и у иных составляют именно что зависимости.
Он использует много ресурсов в работе?
В этом абзаце
JVM так тяжела в работе?вода одна, и ни какой конкретики.
Где сравнение сколько ресурсов нужно ноде, ruby и jvm для обработки «тестового-нагрузочного» приложения? Подозреваю что JVM окажется тяжелее всех и цена сервера для него будет выше чем для других сред. А сравнение по весу файлов и количеству зависимостей это детский сад.
Кто в здравом уме запустит 5 или более процессов JVM?
Не совсем понимаю. С какого-то момента в 2016 году java обычные приложения (БД, обработка текста, ввод и вывод на экран) стало возможно запускать более, чем 5 штук на одной машине?
Я сталкивался с ситуацией, когда несколько java программ в ubuntu i5 32 gb просто хоронили ПК по процессору.
Почему не смогу указать детали, перед тем как учить java я старался найти вагон софта на java для дома и быта, чтобы посмотреть как оно там на платформе java. Запускал пачками. Да, переносимость среди ПК на современных ОС — отличная. Но несколько «редакторов» или подобных программ на java запущенных в разных процессах (разный софт) очень нагружали процессор.
В статье пишут, что теперь это не так, я просто хочу уточнить — это правда?
ps
Замечу здесь, чтобы не плодить комментарии.
«разогретое» приложение на Java порвет большинство конкурентов по параметру «кол-во обработанных запросов в секунду».
Несомненно, это моя неграмотность. Но если мне понадобится сделать сложные преобразования для 1 млрд строк разной длинны даже если изменения можно будет сделать stringbuilder'ом я лучше другой ЯП возьму, не java. А уж работа с чистым string проиграет почти всем языкам (кроме С#).
Java на сервере мне нравится за:
а) легкость деплоя — поставил пакет java8, запустил java -jar… Об этом упоминается в статье. С руби, например все не так гладко… А с другой стороны, программе на голанг и пакеты не нужны) Один бинарник.
б) экосистема. Много зрелых библиотек с хорошей документацией.
Мне понадобилась реализация протокола CoAP, самой полной и проработанной оказалась реализация на Java. Экономия сил и времени. А 1 млрд строк за миллисекунды мне обрабатывать не надо) Мне бы быстрее сервер в строй ввести.
в) JVM языки. Мешает статика? Groovy, Kotlin, JRuby. У меня есть двуязычный проект Java + Groovy, практически бесшовно стыкуются. Правда, проникшись идеями тов. Егора Бугаенко, груви в последнее время выпиливаю… А вот для DSL самое то.
г) IDEA действительно хороша для Java (эх, если бы еще не некоторое количество глюков..)
д) какое-то время назад надо было написать незатейливый, но кроссплатформенный десктопный клиент.
Проще всего мне было написать на Java FX. Скорее всего это только из-за того, что я знаком с Java.
а и б) Имею негативный опыт работы с российским софтом на java. Пара десятков страниц просто про подготовку системы, некоторые подводные камни (например, скопировать в определенный каталог в java home несколько файлов, требование установки именно определенной редакции java (даже не версии).
в) Согласен, была бы в php явная сильная статика (правда это уже не php).
г) Для меня это минус, когда для написания программ крайне желательна ide.
д) Согласен, я также однажды написал не на lazarus, а на netbeans с swing'ом (писал именно в ide, так как в блокноте бы не смог). Радует кроссплатформенность, но… Вот используется в организации софт на java, который давно уже настроили на java 6 и никто ради вас менять версию java не будет. Насколько хороша обратная совместимость в java?
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит embedded jre. Просто зазипованная папка, распаковать и запустить.
IDE vs VIM vs emacs vs whatsoever — спор неблагодарный и бесполезный, да. Для руби я использую текстовый редактор (ide лишь раздражает), для явы мне удобнее IDE.
Обратная совместимость есть. Сравнить особо не с чем. Слышал что у .NET с этим проблемы.
По поводу статей. Прогресс действительно есть, со временем совершенствуются GC, JIT-компилятор.
Когда я свитчнулся на руби, то слышал просто огромное количество критики от людей, которые с явой никогда не имели дело, кроме запуска каких нибудь чужих кривых десктопных программ. При этом у Ruby в то время были гораздо большие проблемы с производительностью, да и Ruby VM тоже имет GC (куда более простенький и гораздо менее настраиваемый) и склонность пожирать память. Просто CRUD-овые вебаппы ее много не едят, в принципе. Был опыт, когда нужна была обработка большого количества сильно связанных сущностей, rake таск на руби потреблял память сотнями МБ в сек.
Еще момент, яву все же нужно уметь готовить. Если бы большинство тех самых кривопрограмм ограничили heap до какого то приемлемого объема и настроили heap ratio так, чтобы jvm возвращала освобожденную память системе, возможно не было бы такой репутации, что ява требует ОЧЕНЬ много памяти. Впрочем, конечному пользователю это не очень интересно. Да и десктопный софт как явление помирает, чего его пинать лишний раз.
В очередном переводе автор пишет, что раньше никому в голову бы не пришло запускать 5 разных программ на java одновременно, а теперь легко. Это правда? Вы юзаете более 5 программ java на своем Пк одновременно?С приходом микросервисов порою необходимо подымать и больше 5 серверов, а еще IDE в несколько окон и дополнительные тулы. Конечно для комфортной работы в этом случае нужно порядка 16 Gb RAM, но больше всего съедает IDE; на микросервисы хватает по 200 мб, как на пару вкладок браузера :-)
А раньше этого не делали потому, что раньше более востребованным был подход с аппликешен контейнерами, когда в один контейнер запихивали и десять серверов. И запускать несколько таких контейнеров было действительно странным решением. Нужно было только в случае настройки/отладки кластеризации на уровне контейнера (к примеру shared-session между несколькими Tomcat инстансами).
Не очень понял, чем Груви противоречит идеям Егора.
А я сталкиваюсь с ситуацией когда приложение на ноде в одном процессе выжирает всю память из падает с OOM. Зато приложение на undertow и caeynne обрабатывает тысячи запросов и потребляет десятки мегабайт памяти.
Автор и правда немного передергивает факты.
- Java требует много памяти. Ну, в 2017 году может это уже и не так много, но совершающий полезную работу java процесс легче 300Мб RAM найти непросто
- Java приложения медленно стартуют и выходят на пиковое быстродействие не сразу
- Если вы измеряете время отклика java приложения в долях миллисекунд, придется оптимизировать настройки JVM
НО:
- "разогретое" приложение на Java порвет большинство конкурентов по параметру "кол-во обработанных запросов в секунду". Избыток памяти используется для экономии CPU.
- приложение — это файл или каталог с файлами. Из внешних зависимостей требуется только JRE
- переход на новую версию java почти всегда беспроблемный
Т.е. получаем идеальное решение для сервера, если есть память. И не очень хорошее решение для гуев.
О как можно обобщить всю экосистему до трех пунктов описывающих её. От 300мб, это какое-то наследие апликейшен серверов и спринга, не более.
Java приложения медленно стартуют и выходят на пиковое быстродействие не сразу
Мое приложение на undertow и cayenne стартует ~1s.
Java требует много памяти. Ну, в 2017 году может это уже и не так много, но совершающий полезную работу java процесс легче 300Мб RAM найти непросто
Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).
Если вы измеряете время отклика java приложения в долях миллисекунд, придется оптимизировать настройки JVM
Говорят есть такие GC, которые совсем без задержек, например в azul такой есть, а еще есть новый shenandoah...
В общем каждый раз когда говорят о джаве одно и тоже: берут худшие примеры в экосистемы джавы, и лучшие в своей.
А атом все еще тормозит сильнее чем idea, а webpack как запускался по 30-60 секунд (в зависимости от проекта), так и запускается.
Одна секунда — это много для десктопного приложения, качественный софт должен открываться сразу. В Java9 обещают модули и пока еще экспериментальную систему предкомпиляции модулей, посмотрим на результаты...
Три человека, которым нравится секундная задержка между кликом по ярлыку и появлением окна приложения?
Если приложение при этом открывает еще и последний проект, или скажем как firefox — все открытые ранее страницы, то ни о какой секунде на старт не может быть и речи, вообще говоря. В лучшем случае вы увидите пустое окно, и какие-то признаки активности. И данные (из интернета) за секунду вам никто не предоставит.
Не спорю, что это не возможно для больших приложений, но мало кто из нас пишет действительно большие приложения. А для типичного shareware в условиях очень жесткой конкуренции между десятком похожих программ время старта — очень важное преимущество.
Типичный пример — просмотрщик фотографий. Люди до сих пор любят ACDSee3 именно за очень быстрый старт.
И, кстати, я был бы очень рад, если бы смог запустить firefox за доли секунды, открыть новую вкладку и начать работу. А предыдущие пускай грузит где-то в фоне.
И да, новое пустое окно (в моем случае хром) вполне открывается за секунду. Как впрочем и новое окно в IDEA для нового класса в программе.
Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).
Справедливости ради, стоит отметить, что вы забываете про Meta Space. Он будет отъедать память, пока она есть в системе (по необходимости), даже если выставить -Xmx. Метаспейс нужно ограничивать отдельно, и это минимум +50 мб на x64.
И да, на x64 при -Xmx20M с SerialGC (как самой легкой) JVM даже не подымится. Compact3 profile возможно поможет, но с этим еще не игрался.
Вот так и выходим на минимум 200-300 Мб для работы приложения. Но взвесив все достоинства и недостатки, будет очевидно, что это небольшая плата за всю мощь, которую предоставляет JVM как платформа.
Вы бы ещё на си попробовали пописать для сравнения. Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
> Размер JDK при скачивании слишком большой?
Конечно большой. И не надо передёргивать про необходимость gcc — у меня оно и без того стоит. И даже если вы исповедуете подход «каждому процессу по виртуальной машине» никто не мешает вам подключить общие зависимости как единый ro-диск.
> Он использует много ресурсов в работе?
Конечно. Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск. Вопрос памяти вы тактично опустили. Вопрос времени голого старта на hellow world тоже. Вопрос сколько жрёт стандартная библиотека, которая всегда должна быть загружена — тоже. Если java такая лёгкая, то почему скрипты пишут на питоне, а не на джаве?
> Развёртывание слишком тяжёлое?
Как скрипт напишешь, так и будет. Верно для всех случаев.
> Она затормаживает вас день ко дню?
Конечно. У меня на 8-гиговом ноуте не запускается больше трёх джав одновременно — память заканчивается. При этом вспоминаем, что джава не умеет освобождать память добровольно, и когда у меня фризится подсветка синтаксиса в редакторе, проще убить и перезапустить процесс. Впрочем, однажды я запустил целых пять джав и остался относительно доволен — выделенную, но неосвобождённую память хитрая ОС спрятала в своп и почти к нему не обращалась. Своп от третьих лиц круче встроенного GC, дожили!
Разве же это единственный вариант? Там в Java тонко настраивается стратегия работы GC: хочется памяти, делаем GC агрессивнее, процессор кушается больше, память кушается меньше.
$ time java Hello
Hello, World!
real 0m0.075s
user 0m0.072s
sys 0m0.000s
И про память вы неправы — джава, во всяком случае, java8, умеет отдавать обратно неиспользуемую память. Другой вопрос, что если приложение написано криво и течет по памяти.
При этом вспоминаем, что джава не умеет освобождать память добровольно
Хорошая статья на эту тему: http://www.stefankrause.net/wp/?p=14
Одна опция запуска — и Java начинает спокойно отдавать память системе.
Кто вам сказал? Я вот на груви пишу. И поверьте — в большинстве случаев код получается намного проще. Да и медленнее питона тоже надо постараться сделать.
Это был сарказм?
https://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
https://tproger.ru/translations/command-line-tools-can-be-235x-faster/
Ну так чувак, который данные, влезающие в память одного узла кластера (не на диск даже, а в память) пытается вообще обрабатывать при помощи MapReduce на кластере — у меня нет для него цензурного названия. И для такого бенчмарка тоже.
Hadoop — это если совсем по-простому, такая штука, которую применяют, если данные перестали влезать на диск одной машины. И когда никакие баш скрипты для обработки просто неприменимы вообще.
but more often than not these days I see Hadoop used where a traditional relational database or other solutions would be far better in terms of performance, cost of implementation, and ongoing maintenance.
Это можно на русский перевести примерно так: а еще я часто вижу, как сегодня гвозди забивают шуруповертами. Не делайте так, забивайте молотком. Все-таки статья желтовата. Этот вывод — он очевиден почти с самого начала, когда объемы данных огласили.
Но ведь автор оригинального послания поступил точно также — нашёл какую-то одну специфическую задачу генерации pdf, где джава была быстрее руби и сказал, что RoR не нужно.
А для чего ноде компайлер? И для чего ноде компайлер в продакшене?
А как же девы на венде? Мингв качают?
За перевод спасибо.
некоторые модули, которые ставятся через npm, содержат нативный код
https://github.com/nodejs/node-gyp
Сборка же на продакшене — это, пардон, рукожопство и полный игнор на CI\CD раз среды дев и прод так сильно различаются, что деплой требует сборки прямо вот на продакшене (не считая того что тянуть не нужные зависимости — оригинальный автор бы еще эклипс в продашкет ставил бы).
Так все андроид приложения на почти-яве. И ничего. Просто надо зависимости с умом выбирать, а не фреймворки типа все включено. Среднее приложение на андроиде всего в полтора раза тяжелее такого же на айос (там си почти что), при том бОльшую часть занимают ресурсы а не код.
Чистой воды Окна Овертона.
Следующей статьей полагается утверждать, что если ваше приложение потребляет менее 1Гб, то это моветон!
Насчет «утилитки», то запущенная Idea на x64 всего 400Мб.
JVM не такая тяжёлая