Java настолько тормозной, что даже JS/V8 быстрей?

теперь осталось переписать на .net

А потом на PHP и пропустить через hiphop.

Java настолько тормозной, что даже JS/V8 быстрей?

Скорее всего тормозной говнокод переписали на нормальный код. Язык здесь не причем.

на нормальный код

Язык здесь не причем.

Мы все еще говорим об одном и том же JS?

Скорее всего тормозной говнокод переписали на нормальный код. Язык здесь не причем.

И эти люди ругают PHP.

Так и запишем: на жабе пишут в основном кривопопые обезьяны.

Говнокод переписали

Скорее всего тормозной говнокод переписали на нормальный код. Язык здесь не причем.

Поддерживаю это суждение. Поправьте если не прав, но похожая ситуация кажися была в Facebook'е, где Александреску переписал какой-то компонент с PHP на D попутно оптимизируя. Новая реализация летала, но есть ли в этом заслуга D совершенно непонятно.

И таки Netflix всё равно молодцы. Заниматься всякими оптимизациями и переписываниями стоит когда у тебя клиенты есть. Преждевременная оптимизация зло.

Так и запишем: на жабе пишут в основном кривопопые обезьяны.

А что, разве не так?

Статью то читал? Там речь о том что большую часть рендеринга перенесли на браузер. А JS используют чтобы можно было рендерить одинаково и на сервере, и на клиенте.

забавно, что они юзают Томкат в продакшене. Он же течет, не? Мы сами юзаем томкат, но это чисто как спасение от ненужных фич, и всегда можно рестартнуть когда раздуется. А тут Сам Его Величество Netflix с безразмерными бюджетами, могли бы ораклвское поделие прикупить...

плюс Struts, который вроде бы уже закопали давно

читал конечно, Java ты в таком ключе не сможешь использовать очевидно, еще один минус кроме тормознутости, отсутствие единой кодовой базы, gwt то слился и уступил место настоящему языку

А что не так, если сильно охото в нём даже с биарными данными сейчас работать нормально можно, хотя это уже не js, а чёрти что:)

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

ps. и тысячи синглтонов!

ло-ло-ло.

отсутствие единой кодовой базы

scala + scala.js. Брат жив.

Хотя js-индусов найти намного проще, чем scala-программистов...

scala.js

ахахахххахахаа, ты этим пользовался?

хотя это уже не js, а чёрти что

Во первых этого HTML5 требует, во вторых фундаментально то ничего не изменилось же от того что добавили какие то API (DataView), работает то так же все.

За время существования проекта в нем накапливается множество костылей, переделывается архитектура, но не целиком а частями и в результате у разработчиков возникает понимание (основанное на опыте использования проекта), как нужно реализовать проект с учетом реальных нагрузок, требований и способов эксплуатации. Поэтому на чем его не переписывай, он будет лучше. Переписали бы на Java, была бы статья, что Java круче Java. :-)

Так что все темы «Мы переписали проект с XXX на YYY», означают не что YYY круче XXX, а что разработчики не осилили плавную переделку проекта, а решили переписать его с нуля с учетом накопленного опыта.

ахахахххахахаа, ты этим пользовался?

Да, каждый день пользуюсь.

дай угадаю, это какой внутренний продукт для гос органов который не завязан на десяток либ (и это не джеквери!) ?

на нормальный код

если забыть, что речь про js, то даже вполне себе нейтральная фраза получается

читал конечно, Java ты в таком ключе не сможешь использовать очевидно, еще один минус кроме тормознутости, отсутствие единой кодовой базы, gwt то слился и уступил место настоящему языку

Так причем тут тормознутость джавы? Где независимые бенчмарки? Какой-то анонимус наклепал статью и мы теперь должны верить ему на слово?

Например, https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test... нода сливает в 6 раз, джаве при работе с JSON.

А в джаву между прочим давно завезли Nashorn. А потому, можно запилить гораздо более крутой веб-фреймворк, чем где-либо еще.

И вообще, почему не переписали на модный ныне Go?

дай угадаю

Совсем не внутренний, с государством не связанный. Разные свободные проекты на scala.js гуглятся легко.

который не завязан на десяток либ

Дык scala.collection, scala.concurrent, scala.* и стандартный просто синтаксис scala заменяет кучу сторонних либ.

Если причина всех этих эмоций в неразделённой любви к ноде.жс, то на голом js сильно далеко не уедешь, и всякие синтаксические говнопосахаривания типа кофескрипта/тупоскипта/быкбона/жэкуери и прочих ангуляров тоже не помогут на серьезном убер-проЭкте. Пройдёт лет 10-20, и в толксах появится героическая ниочёмная новость, что где-то выкорчевали node.js, и какой-то показатель взлетел в небеса.

нода сливает в 6 раз, джаве при работе с JSON.

ага, весь мир переходит на ноду, а в синтетическом тесте при генерации ответа в json(!), нода сливает яве в виде netty(!) который ниразу ничего не умеет делать, да и в которой даже толком асинхронных драйверов к базам нет (лолз)

А в джаву между прочим давно завезли Nashorn

толк от завезли? ты понимаешь что такое экосистема где 170 тыщ пакетов асинхронны? и насхорн который никому нахер не сдался?

И вообще, почему не переписали на модный ныне Go?

го не умеет в единый код с фронтом потому что, для них это критично

Так причем тут тормознутость джавы?

У жабы тормознутость в её «программистах», почти всегда не умеющих в асинхронность. js благодаря своей однопоточности вынужденно лишился такого народного достояния как синхронное блокирующее i/o с СУБД и прочими.

Если причина всех этих эмоций в неразделённой любви к ноде.жс, то на голом js сильно далеко не уедешь

а js он маленький сам по себе и не тащит кучу мусора, хочешь collection? берешь underscore или lodash, а стандартный просто синтаксис es6 в связке со свободной работой с любыми либами в отличии от, делает scalajs жалкой подделкой которая не нужна

а js он маленький сам по себе

Бинарный что ли?

хочешь collection? берешь underscore или lodash

И что меняет? Заменяем одни 50кб на другие 50кб, да?

а стандартный просто синтаксис es6

Кросскомпиляция под es5, es6, strong js, jvm? Не, не слышал.

в связке со свободной работой с любыми либами в отличии от

В отличии от чего, если не секрет?

И что меняет? Заменяем одни 50кб на другие 50кб, да?

7 kb

Кросскомпиляция под es5, es6, strong js, jvm? Не, не слышал.

не понял в чем преимущество

В отличии от чего, если не секрет?

http://www.scala-js.org/doc/calling-javascript.html
http://www.scala-js.org/doc/export-to-javascript.html

в отличии от такой параши

в отличии от такой параши

Кто-то выше кукарекал про 170к пакетов (очень сомнительного качества кстати), но добавить в build.sbt пакет с scala.js интерфейсами к какой-то либе или намалевать свой интерфейс за пару минут — уже параша. Логика достойна снисхождения.

не понял в чем преимущество
7 kb

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

7 kb

Кстати по гордому упоминанию js-микроразмеров сразу детектятся специалисты по написанию write-only кода на js. Некоторые из ранее уволенных даже пробелы экономили(!).

намалевать свой интерфейс за пару минут

фантазия достойна похвалы

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

подпустили, «брат жив»

Кстати по гордому упоминанию js-микроразмеров сразу детектятся специалисты по написанию write-only кода на js. Некоторые из ранее уволенных даже пробелы экономили(!).

зачем их экономить? sbt же умеет их убирать, не?

Тормозило, переписали, перестало тормозить. Прохладная история, немедленно на главную.

Там нормально все, драмы нет. Даже цифры про 70% правдоподобные.

То ли дело пейпал, вот там настоящий прорыв был.

ораклвское поделие прикупить

Верный путь в вечное рабство.

ага, весь мир переходит на ноду

Как-то не видел про весь мир. Если смотреть тренды hhttps://www.google.com/trends/explore#q=node.js%2C%20golang%2C%20spring%20mvc%2C%20java%208%2C%20ecmascript&cmpt=q&tz=Etc%2FGMT-6 то ноджс нашел свой максимум, как минимум год без движений.

в синтетическом тесте

Давай не в синтетическом http://benchmarksgame.alioth.debian.org/u64/javascript.html Все равно слив в разы по 80% позиций.

ответа в json(!)

А в чем должен отдавать ответ сервер-сайд?

нода сливает яве в виде netty(!) который ниразу ничего не умеет делать

А голый ноджс умеет что-то больше java+netty?

да и в которой даже толком асинхронных драйверов к базам нет (лолз)

Драйвера к БД, это примитивы, их обычно никто не использует напрямую, а оборачивают в какой-либо другой фреймворк. Если нужна асинхронность, подбери нужный тебе фреймворк или orm для асинхронной работы с БД.

В этом и заключается преимущество java. Захотелось зеленые треды, подбери фреймворк. Захотело асинхронность - подбери фреймворк. И не надо на каждую хотелку учить новый ЯП.

толк от завезли?

Очередная универсальность, теперь у java программистов есть возможность удобно совмещать фронтенд и бекенд - как и в node.js Правда фреймворков на этот счет пока не завезли. Но это решаемо, я например, пилю такой фреймворк. Наверняка еще кто-то пилит, может на гитхабе уже что-то есть.

ты понимаешь что такое экосистема где 170 тыщ пакетов асинхронны?

А зачем асинхронность на каждый чих? Она полезна при IO, а в остальных ситуациях не вижу смысла, лишний оверхед.

Java опять сливается из-за своей тормознутости

Вылези уже из криокамеры, джава давно сравнима по производительности с ЯП класса С++ для долгоживущих задач (сервер-сайд в их числе).

А тормознутость системы зависит от прямоты рук, можно и на С, написать тормознее, чем на JavaScript. Вот эта табличка http://benchmarksgame.alioth.debian.org/u64/performance.php?test=binarytrees тому пример.

sbt всё умеет, речь о pure-js'никах, специалистах по написанию компактного одноразового быдлокода, считающих что чем меньше кода — тем быстрее он работает. Т.е. про тех, о ком оп-пост.

подпустили, «брат жив»

Конечно же мелочась по килобайтам, ты гордо можешь похвастаться проектом, где есть хотя бы 2000 исходников на js, и ни одной проблемы с типами и прочим...

фантазия достойна похвалы

Скажи честно, код по твоей ссылке можно вообще как-то написать медленее чем за 2 минуты?

Драйвера к БД, это примитивы, их обычно никто не использует напрямую, а оборачивают в какой-либо другой фреймворк. Если нужна асинхронность, подбери нужный тебе фреймворк или orm для асинхронной работы с БД.

JDBC же синхронный блокирующий на socket IO, не? Это порождает другую проблему: JDBC неявно принуждает программистов делать последовательные селекты вместо параллельных. Либо надо задирать объемы в thread-pool'ов и пулов коннекшеннов, наслаждаясь сопутствующими потерями на переключениях контекстов на проце, которые проявляются на высокой параллельной нагрузке в виде 5-10-20%+ в поле sys в top'е. Ещё есть асинхронные, обычно кустарные, не-JDBC драйвера. Поправьте, т.к. могу ошибаться.

Кстати, а в ноджс честная асинхронность, с рантаймом, который вытесняет заблокированные таски? Т.е. как в go или erlang?

В jvm (т.е. scala, clojure в том числе) с этим проблемы, если таска блокирующая, то все - считай нативный тред выпал из работы. Хотя там какой-то quasar запили, вставляющий в байт-код yield и пытающийся эмулировать рантайм подобный go или erlang. Кто-нибудь его пробовал?

Не замечал, что томкат течёт.

в которой даже толком асинхронных драйверов к базам нет (лолз)

Нет ничего более бесполезного, чем асинхронные драйверы к базе.

В ноде один поток. Если кто-нибудь его заблокировал, то все клиенты ждут.

Нет ничего более бесполезного, чем асинхронные драйверы к базе.

Почему? Если отправили запрос на удаленный сервер, то чтобы не ждать ответа и не блокировать тред, запускаем его асинхронно и тем самым другие файберы вытеснят ожидающий таск с треда и займутся другими делами.

По крайне-мере в go или erlang примерно так, как я понимаю?

В питоне тоже. Асинхронность решает 99% возникающих с этим проблем.

отстаёте от менстима, жс-базворды старенькие

В питоне тоже. Асинхронность решает 99% возникающих с этим проблем.

Как оно решает, если поток заблокировать? Все же встанет.

Язык здесь не причем.

Язык - нет, V8 - да. Не знаю, сколько душ инженеры google продали дьяволу за такую скорость, но практика показывает, что он **чертовски** быстрый для интерпретатора скриптового языка.

Блокировать? у тебя же все неблокирующее в ноде, все асинхронное.

Я не зря тебе говорил про экосистему.

другие файберы вытеснят ожидающий таск с треда и займутся другими делами

Очень грубо говоря, есть thread-pool и очередь задач.
В пуле кол-во потоков равно кол-ву CPU.
Очередь задач раскидывает задачи по свободным потокам, по возможности учитывая cpu cache coherence.

В случае асинхронной работы с базами будет маленькая задача «отправить запрос к базе» и листенер в netty, который потом отправит на исполнение новую задачу: «обработать результат запроса». Т.е. «вытеснения» как такового нет, и паразитные context switch снижены до минимума. По такому принципу устроен например play framework. Но такая работа на блокирующем io заблокирует весь сервис очень быстро, и для блокирующих операций тут нужен отдельный thread-pool (ExecutionContext).

На erlang есть глобальный thread-pool легких тредов, где их обычно тысячи и миллионы. Размер thread-pool задается параметром при запуске beam (это vm erlang'а). Большой thread pool жрёт много RAM и повышает долю паразитных, хоть и легковесных, переключений контекста на CPU. Я не считаю, что модель многопоточности erlang хороша: неоправданные расходы на RAM, на серьезной нагрузке ощущаются потери на переключениях и нужно вручную педалировать per-thread GC, для обмена сообщениями между потоками используется memcpy() либо сериализация в блобы. Но из-за отсутствия изменяемых типов данных в erlang и глобального GC что-то лучше придумать там проблематично.

Встать насмерть оно может только в случае бесконечного цикла на процессоре. Вся ожидающая чего-либо работа с сетью и диском, будь то загрузка данных из базы, передача их клиенту, запросы на сторонние сервисы - идет асинхронно.