Comments 52
Насколько я помню, обновлять/устанавливать сам XCode не обязательно — достаточно наличия XCode Command Line Tools. А они, в свою очередь, занимают аж 158 МБ (пруф). Основную массу и у рубей, и у ноды, и у иных составляют именно что зависимости.
Спасибо за информацию.
А где этот пункт?
В этом абзаце
Где сравнение сколько ресурсов нужно ноде, ruby и jvm для обработки «тестового-нагрузочного» приложения? Подозреваю что JVM окажется тяжелее всех и цена сервера для него будет выше чем для других сред. А сравнение по весу файлов и количеству зависимостей это детский сад.
Он использует много ресурсов в работе?
В этом абзаце
JVM так тяжела в работе?вода одна, и ни какой конкретики.
Где сравнение сколько ресурсов нужно ноде, ruby и jvm для обработки «тестового-нагрузочного» приложения? Подозреваю что JVM окажется тяжелее всех и цена сервера для него будет выше чем для других сред. А сравнение по весу файлов и количеству зависимостей это детский сад.
Кто в здравом уме запустит 5 или более процессов JVM?
Не совсем понимаю. С какого-то момента в 2016 году java обычные приложения (БД, обработка текста, ввод и вывод на экран) стало возможно запускать более, чем 5 штук на одной машине?
Я сталкивался с ситуацией, когда несколько java программ в ubuntu i5 32 gb просто хоронили ПК по процессору.
Деталей мало. Похоронить CPU можно на каком угодно языке. Может они что-то тяжелое все же делали?
По сути просто висели в процессах. Ну или простые анализаторы небольшого числа логов.
Почему не смогу указать детали, перед тем как учить java я старался найти вагон софта на java для дома и быта, чтобы посмотреть как оно там на платформе java. Запускал пачками. Да, переносимость среди ПК на современных ОС — отличная. Но несколько «редакторов» или подобных программ на java запущенных в разных процессах (разный софт) очень нагружали процессор.
В статье пишут, что теперь это не так, я просто хочу уточнить — это правда?
ps
Замечу здесь, чтобы не плодить комментарии.
Несомненно, это моя неграмотность. Но если мне понадобится сделать сложные преобразования для 1 млрд строк разной длинны даже если изменения можно будет сделать stringbuilder'ом я лучше другой ЯП возьму, не java. А уж работа с чистым string проиграет почти всем языкам (кроме С#).
Почему не смогу указать детали, перед тем как учить 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 на сервере мне нравится за:
а) легкость деплоя — поставил пакет java8, запустил java -jar… Об этом упоминается в статье. С руби, например все не так гладко… А с другой стороны, программе на голанг и пакеты не нужны) Один бинарник.
б) экосистема. Много зрелых библиотек с хорошей документацией.
Мне понадобилась реализация протокола CoAP, самой полной и проработанной оказалась реализация на Java. Экономия сил и времени. А 1 млрд строк за миллисекунды мне обрабатывать не надо) Мне бы быстрее сервер в строй ввести.
в) JVM языки. Мешает статика? Groovy, Kotlin, JRuby. У меня есть двуязычный проект Java + Groovy, практически бесшовно стыкуются. Правда, проникшись идеями тов. Егора Бугаенко, груви в последнее время выпиливаю… А вот для DSL самое то.
г) IDEA действительно хороша для Java (эх, если бы еще не некоторое количество глюков..)
д) какое-то время назад надо было написать незатейливый, но кроссплатформенный десктопный клиент.
Проще всего мне было написать на Java FX. Скорее всего это только из-за того, что я знаком с Java.
j_wayne мне так то всё равно, просто любопытно, почему настолько регулярно последние годы появляются статьи с одним содержанием «недавно java была совсем дохленькая, а теперь огогого зверь, всех рвёт». В очередном переводе автор пишет, что раньше никому в голову бы не пришло запускать 5 разных программ на java одновременно, а теперь легко. Это правда? Вы юзаете более 5 программ java на своем Пк одновременно?
а и б) Имею негативный опыт работы с российским софтом на java. Пара десятков страниц просто про подготовку системы, некоторые подводные камни (например, скопировать в определенный каталог в java home несколько файлов, требование установки именно определенной редакции java (даже не версии).
в) Согласен, была бы в php явная сильная статика (правда это уже не php).
г) Для меня это минус, когда для написания программ крайне желательна ide.
д) Согласен, я также однажды написал не на lazarus, а на netbeans с swing'ом (писал именно в ide, так как в блокноте бы не смог). Радует кроссплатформенность, но… Вот используется в организации софт на java, который давно уже настроили на java 6 и никто ради вас менять версию java не будет. Насколько хороша обратная совместимость в java?
а и б) Имею негативный опыт работы с российским софтом на java. Пара десятков страниц просто про подготовку системы, некоторые подводные камни (например, скопировать в определенный каталог в java home несколько файлов, требование установки именно определенной редакции java (даже не версии).
в) Согласен, была бы в php явная сильная статика (правда это уже не php).
г) Для меня это минус, когда для написания программ крайне желательна ide.
д) Согласен, я также однажды написал не на lazarus, а на netbeans с swing'ом (писал именно в ide, так как в блокноте бы не смог). Радует кроссплатформенность, но… Вот используется в организации софт на java, который давно уже настроили на java 6 и никто ради вас менять версию java не будет. Насколько хороша обратная совместимость в java?
Про десктопный софт на своем ПК ничего путного сказать не могу. Кроме IDE не использую.
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит embedded jre. Просто зазипованная папка, распаковать и запустить.
IDE vs VIM vs emacs vs whatsoever — спор неблагодарный и бесполезный, да. Для руби я использую текстовый редактор (ide лишь раздражает), для явы мне удобнее IDE.
Обратная совместимость есть. Сравнить особо не с чем. Слышал что у .NET с этим проблемы.
По поводу статей. Прогресс действительно есть, со временем совершенствуются GC, JIT-компилятор.
Когда я свитчнулся на руби, то слышал просто огромное количество критики от людей, которые с явой никогда не имели дело, кроме запуска каких нибудь чужих кривых десктопных программ. При этом у Ruby в то время были гораздо большие проблемы с производительностью, да и Ruby VM тоже имет GC (куда более простенький и гораздо менее настраиваемый) и склонность пожирать память. Просто CRUD-овые вебаппы ее много не едят, в принципе. Был опыт, когда нужна была обработка большого количества сильно связанных сущностей, rake таск на руби потреблял память сотнями МБ в сек.
Еще момент, яву все же нужно уметь готовить. Если бы большинство тех самых кривопрограмм ограничили heap до какого то приемлемого объема и настроили heap ratio так, чтобы jvm возвращала освобожденную память системе, возможно не было бы такой репутации, что ява требует ОЧЕНЬ много памяти. Впрочем, конечному пользователю это не очень интересно. Да и десктопный софт как явление помирает, чего его пинать лишний раз.
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит 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 обещают модули и пока еще экспериментальную систему предкомпиляции модулей, посмотрим на результаты...
Три человека, которым нравится секундная задержка между кликом по ярлыку и появлением окна приложения?
Вовсе не в этом дело. Что значит «должен открываться сразу»? Кому должен и почему? Софты — они разные бывают. Ожидания при открытии окна какой-нибудь 3D CAD или Фотошопа и окна vim — это совершенно разные вещи.
Если приложение при этом открывает еще и последний проект, или скажем как firefox — все открытые ранее страницы, то ни о какой секунде на старт не может быть и речи, вообще говоря. В лучшем случае вы увидите пустое окно, и какие-то признаки активности. И данные (из интернета) за секунду вам никто не предоставит.
Если приложение при этом открывает еще и последний проект, или скажем как firefox — все открытые ранее страницы, то ни о какой секунде на старт не может быть и речи, вообще говоря. В лучшем случае вы увидите пустое окно, и какие-то признаки активности. И данные (из интернета) за секунду вам никто не предоставит.
Не спорю, что это не возможно для больших приложений, но мало кто из нас пишет действительно большие приложения. А для типичного shareware в условиях очень жесткой конкуренции между десятком похожих программ время старта — очень важное преимущество.
Типичный пример — просмотрщик фотографий. Люди до сих пор любят ACDSee3 именно за очень быстрый старт.
И, кстати, я был бы очень рад, если бы смог запустить firefox за доли секунды, открыть новую вкладку и начать работу. А предыдущие пускай грузит где-то в фоне.
Да дело даже не в размере — дело в шаблонах использования. Если вы открыли приложение, и работаете в нем день — то 30 секунд с утра вам до лампочки. Это просто разные классы приложений. Да, для автономных утилит типа просмотра фоток время старта важно. А тот же самый просмотр фоток в рамках файрфокса — это уже совсем другая картина, тут уже нет никакого времени старта вообще, потому что вы как-бы открываете много разных страниц, на каждой из которых много разных картинок, которые скачиваются из интернета с разной скоростью, в разном качестве, и показываются в разном масштабе, а то и с фильтрами.
И да, новое пустое окно (в моем случае хром) вполне открывается за секунду. Как впрочем и новое окно в IDEA для нового класса в программе.
И да, новое пустое окно (в моем случае хром) вполне открывается за секунду. Как впрочем и новое окно в IDEA для нового класса в программе.
Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).
Справедливости ради, стоит отметить, что вы забываете про Meta Space. Он будет отъедать память, пока она есть в системе (по необходимости), даже если выставить -Xmx. Метаспейс нужно ограничивать отдельно, и это минимум +50 мб на x64.
И да, на x64 при -Xmx20M с SerialGC (как самой легкой) JVM даже не подымится. Compact3 profile возможно поможет, но с этим еще не игрался.
Вот так и выходим на минимум 200-300 Мб для работы приложения. Но взвесив все достоинства и недостатки, будет очевидно, что это небольшая плата за всю мощь, которую предоставляет JVM как платформа.
> Этот маленький динозавр на стоковом JVM (за исключением -server -Xmx=512M) производил PDF'ки так быстро, что он буквально убивал трёхнодовый кластер при каждом запуске.
Вы бы ещё на си попробовали пописать для сравнения. Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
> Размер JDK при скачивании слишком большой?
Конечно большой. И не надо передёргивать про необходимость gcc — у меня оно и без того стоит. И даже если вы исповедуете подход «каждому процессу по виртуальной машине» никто не мешает вам подключить общие зависимости как единый ro-диск.
> Он использует много ресурсов в работе?
Конечно. Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск. Вопрос памяти вы тактично опустили. Вопрос времени голого старта на hellow world тоже. Вопрос сколько жрёт стандартная библиотека, которая всегда должна быть загружена — тоже. Если java такая лёгкая, то почему скрипты пишут на питоне, а не на джаве?
> Развёртывание слишком тяжёлое?
Как скрипт напишешь, так и будет. Верно для всех случаев.
> Она затормаживает вас день ко дню?
Конечно. У меня на 8-гиговом ноуте не запускается больше трёх джав одновременно — память заканчивается. При этом вспоминаем, что джава не умеет освобождать память добровольно, и когда у меня фризится подсветка синтаксиса в редакторе, проще убить и перезапустить процесс. Впрочем, однажды я запустил целых пять джав и остался относительно доволен — выделенную, но неосвобождённую память хитрая ОС спрятала в своп и почти к нему не обращалась. Своп от третьих лиц круче встроенного GC, дожили!
Вы бы ещё на си попробовали пописать для сравнения. Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
> Размер JDK при скачивании слишком большой?
Конечно большой. И не надо передёргивать про необходимость gcc — у меня оно и без того стоит. И даже если вы исповедуете подход «каждому процессу по виртуальной машине» никто не мешает вам подключить общие зависимости как единый ro-диск.
> Он использует много ресурсов в работе?
Конечно. Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск. Вопрос памяти вы тактично опустили. Вопрос времени голого старта на hellow world тоже. Вопрос сколько жрёт стандартная библиотека, которая всегда должна быть загружена — тоже. Если java такая лёгкая, то почему скрипты пишут на питоне, а не на джаве?
> Развёртывание слишком тяжёлое?
Как скрипт напишешь, так и будет. Верно для всех случаев.
> Она затормаживает вас день ко дню?
Конечно. У меня на 8-гиговом ноуте не запускается больше трёх джав одновременно — память заканчивается. При этом вспоминаем, что джава не умеет освобождать память добровольно, и когда у меня фризится подсветка синтаксиса в редакторе, проще убить и перезапустить процесс. Впрочем, однажды я запустил целых пять джав и остался относительно доволен — выделенную, но неосвобождённую память хитрая ОС спрятала в своп и почти к нему не обращалась. Своп от третьих лиц круче встроенного GC, дожили!
>>Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск.
Разве же это единственный вариант? Там в Java тонко настраивается стратегия работы GC: хочется памяти, делаем GC агрессивнее, процессор кушается больше, память кушается меньше.
Разве же это единственный вариант? Там в Java тонко настраивается стратегия работы GC: хочется памяти, делаем GC агрессивнее, процессор кушается больше, память кушается меньше.
Тебе надо заранее указать максимальный порог — и JVM под это будет подстраиваться. Но если ты работаешь с данными, ты не знаешь заранее, сколько именно тебе понадобится памяти, чтобы их обработать, и значит не можешь выставить лимита. А без выставления лимита gc будет расширять память пока ОС ему это позволяет вместо того, чтобы чистить старое. Такая вот узкая заточка под серверные нужды, где нагрузка хорошо прогнозируется и можно учесть ожидаемое потребление памяти
С дефолтными настройками так, но это всё настраивается. Не только максимальный порог, но и на каком количестве занятой памяти и как часто запускать GC. Если переусердствовать, правда, возникнет другая проблема — слишком частые или длинные паузы на GC, либо слишком много процессора будет жрать на 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 начинает спокойно отдавать память системе.
>почему скрипты пишут на питоне, а не на джаве?
Кто вам сказал? Я вот на груви пишу. И поверьте — в большинстве случаев код получается намного проще. Да и медленнее питона тоже надо постараться сделать.
Кто вам сказал? Я вот на груви пишу. И поверьте — в большинстве случаев код получается намного проще. Да и медленнее питона тоже надо постараться сделать.
>Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
Это был сарказм?
Это был сарказм?
это было округление в большую сторону. На самом деле:
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/
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/
На самом деле статью писал дурак. Который вообще не понимает, что такое Hadoop, зачем и когда его нужно применять. Скока-скока там гигабайт данных? Почти четыре?
Ну так чувак, который данные, влезающие в память одного узла кластера (не на диск даже, а в память) пытается вообще обрабатывать при помощи MapReduce на кластере — у меня нет для него цензурного названия. И для такого бенчмарка тоже.
Hadoop — это если совсем по-простому, такая штука, которую применяют, если данные перестали влезать на диск одной машины. И когда никакие баш скрипты для обработки просто неприменимы вообще.
Ну так чувак, который данные, влезающие в память одного узла кластера (не на диск даже, а в память) пытается вообще обрабатывать при помощи MapReduce на кластере — у меня нет для него цензурного названия. И для такого бенчмарка тоже.
Hadoop — это если совсем по-простому, такая штука, которую применяют, если данные перестали влезать на диск одной машины. И когда никакие баш скрипты для обработки просто неприменимы вообще.
Ну в той статье в выводах как раз и написано «не будьте дураками и не используйте hadoop когда всё можно посчитать на одной машине». Но кое-кто умудрился прочитать ту статью и сделать для себя вывод «баш скрипты быстрее 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.
Это можно на русский перевести примерно так: а еще я часто вижу, как сегодня гвозди забивают шуруповертами. Не делайте так, забивайте молотком. Все-таки статья желтовата. Этот вывод — он очевиден почти с самого начала, когда объемы данных огласили.
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.
Это можно на русский перевести примерно так: а еще я часто вижу, как сегодня гвозди забивают шуруповертами. Не делайте так, забивайте молотком. Все-таки статья желтовата. Этот вывод — он очевиден почти с самого начала, когда объемы данных огласили.
> сделать для себя вывод «баш скрипты быстрее hadoop» :)
Но ведь автор оригинального послания поступил точно также — нашёл какую-то одну специфическую задачу генерации pdf, где джава была быстрее руби и сказал, что RoR не нужно.
Но ведь автор оригинального послания поступил точно также — нашёл какую-то одну специфическую задачу генерации pdf, где джава была быстрее руби и сказал, что RoR не нужно.
Про 5 приложений хочу отметить, что сын у меня играл в майнкрафт и игра у него сворачивалась, а он все время заново запускал.В итоге запустил штук шесть экземпляров и ничего, все работало! 8гб, AMD Phenom x2
А для чего ноде компайлер? И для чего ноде компайлер в продакшене?
А как же девы на венде? Мингв качают?
За перевод спасибо.
некоторые модули, которые ставятся через npm, содержат нативный код
https://github.com/nodejs/node-gyp
Ну да — и много вы знаете модулей которые требуют нативного кода? Я несколько и они крайне спецефичные (не считая разве что сислога, и то который можно без нативного кода сделать).
Сборка же на продакшене — это, пардон, рукожопство и полный игнор на CI\CD раз среды дев и прод так сильно различаются, что деплой требует сборки прямо вот на продакшене (не считая того что тянуть не нужные зависимости — оригинальный автор бы еще эклипс в продашкет ставил бы).
Сборка же на продакшене — это, пардон, рукожопство и полный игнор на CI\CD раз среды дев и прод так сильно различаются, что деплой требует сборки прямо вот на продакшене (не считая того что тянуть не нужные зависимости — оригинальный автор бы еще эклипс в продашкет ставил бы).
Так все андроид приложения на почти-яве. И ничего. Просто надо зависимости с умом выбирать, а не фреймворки типа все включено. Среднее приложение на андроиде всего в полтора раза тяжелее такого же на айос (там си почти что), при том бОльшую часть занимают ресурсы а не код.
Java жрать меньше не стала, просто с законом Мура 1Гб памяти на утилитку теперь можно назвать «JVM не такая тяжёлая» =)
Чистой воды Окна Овертона.
Следующей статьей полагается утверждать, что если ваше приложение потребляет менее 1Гб, то это моветон!
Чистой воды Окна Овертона.
Следующей статьей полагается утверждать, что если ваше приложение потребляет менее 1Гб, то это моветон!
Скорее так: java сколько жрала, столько и жрет, просто аппетиты других программ и инструментов стали гораздо больше и на их фоне java не настолько и прожорливая. Ну и памяти стало больше, да.
Тут Вам удобство и скорость разработки, а также кроссплатформенность, очень быстрая виртуальная машина и Вы хотите, чтобы приложения жрали немногим больше, чем на C?
Насчет «утилитки», то запущенная Idea на x64 всего 400Мб.
Насчет «утилитки», то запущенная Idea на x64 всего 400Мб.
Sign up to leave a comment.
JVM не такая тяжёлая