LINUX.ORG.RU
Ответ на: комментарий от foror

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

Главным образом по следующим соображениям. БД оптимально работает, когда число соединений не больше числа ядер. Т.е. если у тебя 8 ядер, то максимум ставить 8-10 соединений. Можно поставить чуть больше, если БД кривая и часто упирается в I/O. Но в любом случае это не сотни соединений.

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

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

В go и erlang совсем другой рантайм. Имитировать его никому не нужно.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Spectator

Встать насмерть оно может только в случае бесконечного цикла на процессоре

Т.е. если я захочу в питоне или ноджс распаралелить парсинг какого-то контента, то я смогу использовать только один поток? И вынужден поднимать отдельный процесс на ядро процессора, для полной загружки ядер?

А как тогда с интеловским гипертредингом, он я как понимаю паралелится только внутри процесса? Тем самым если у меня 2 ядра с гипертредингом, я смогу их загрузить только наполовину на питоне или нодежс?

foror ★★★★★
()

У Netflix тормозила Java, переписали на node.js, теперь все работает быстро

Fix

У Netflix тормозила, переписали, теперь все работает быстро

ТС, ты хоть статью читал?

vertexua ★★★★★
()
Ответ на: комментарий от umren

Ближе к теме, не соскакивай. Netflix переписал тормозную шаблонизацию на сервере на SPA с большинством работы на клиенте. Да еще на каком клиенте - React.js. А потом «Ой быстрее стало, наверное JS быстрее Java». Для чистоты эксперимента пусть нодой на сервере пошаблонизируют то же самое что и раньше и посмотрят )

vertexua ★★★★★
()
Ответ на: комментарий от foror

Зависит от реализации интерпретатора. Однопроцессорным я назвал каноничный cpython, в котором GIL. PyPy-STM уже фактически работает в несколько потоков, хотя последний раз, когда я смотрел, оверхед был тот ещё. IronPython и Jython вроде бы тоже нормально параллелятся. Как эта обработка сделана внутри nodejs - понятия не имею.

В питоне для борьбы с GIL используется multiprocessing. Я лично с ним не работал, но вроде бы у него такие же интерфейсы, как и у threading модуля, но вместо треда он спавнит процесс. Скорее всего, есть готовые биндинги для асинхронных движков, которые позволяют без блокировки забирать результат вычислений, скинутых в отдельный процесс.

Spectator
()
Ответ на: комментарий от vertexua

Для чистоты эксперимента пусть нодой на сервере пошаблонизируют то же самое что и раньше и посмотрят )

я думаю ребята из нетфликс для чистоты эксперемента уже и делали разные реализации, просто кто тебе об этом скажет? пришли к выводу что java не нужна, а в conclusion написано что переведут все, ява это легаси которое отравляет наш мир

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

ребята из нетфликс
conclusion написано что переведут все

Походу в нетфликс за место индусов, хипстеров завезли...

ява это легаси которое отравляет наш мир

Альтернативы то нет... Посмотрим, что WebAssembly выродит, может будет альтернативой JVM.

foror ★★★★★
()
Ответ на: комментарий от umren

в conclusion написано

А в заголовке топика такое написано, что даже макском обратил взгляд на столь толстое 4.2. Второй раз такой трюк уже может не прокатить.

для чистоты эксперемента уже и делали разные реализации

Сидели переписывали UI своего мегасервиса 10 раз ради чистоты эксперимента, ага.

shahid ★★★★★
()
Ответ на: комментарий от shahid

А в заголовке топика такое написано, что даже макском обратил взгляд на столь толстое 4.2.

Правильный заголовок - половина успеха

Кроме того сразу понятно, кто пошел читать, а кто сразу все сложил в голове по заголовку

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

почему? что таково есть в яве, чего сейчас нет в других стеках?

- типизированный, простой, но не упрощенный как в go, синтаксис 
- мощная IDE (аж две штуки) с интеллектуальным автодополнением и рефакторингом 
- nashorn 
- перформанс на уровне С++ 
- нативный трединг 
- поддержка windows, unix, osx

Нету сейчас такого инструмента, кроме Java+JVM, чтобы это было все вместе и сразу.

foror ★★★★★
()
Ответ на: комментарий от foror

В своей нише — безусловно. Просто потому, что Java-апплеты сейчас почти никто не использует (ну кроме банков с хардварными токенами разве что).

MiniRoboDancer ★☆
()
Ответ на: комментарий от umren

Гуглоридер не нужен, он убивает весь профит RSS (подписка без внешней слежки).

MiniRoboDancer ★☆
()
Ответ на: комментарий от MiniRoboDancer

Да понятно, что кого-то устраивает на php писать сайты, на с++ делать десктоп, на python писать утилиты, на javascript делать фронтенд, а на java делать андроид. У кого-то есть ресурсы завозить под каждый из этих ЯП команду индусов или хипстеров.

У меня таких ресурсов нет и нет времени раскидывать силы на изучение зоопарка ЯП. Для меня java универсальный инструмент для решения выше перечисленных задач. Конечно пока приходиться разбираться с убожеством в виде javascript, но думаю с приходом webassembly можно будет выкинуть и его из списка.

Так что для меня альтернативы пока нет.

foror ★★★★★
()
Ответ на: комментарий от foror

Конечно пока приходиться разбираться с убожеством в виде javascript, но думаю с приходом webassembly можно будет выкинуть и его из списка.

Кажется ты не совсем понимаешь, что такое webassembly. У тебя и сегодня есть возможность использовать GWT. А webassembly это такая бинарная форма записи JavaScript-а, она ничего принципиально нового не даст. Ждать её смысла нет.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

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

Посути, они хотят изобрести свою JVM с блэк джеком и шлюхами. С возможностью как вручную управлять памятью, так и через GC.

foror ★★★★★
()
Ответ на: комментарий от foror

- типизированный, простой, но не упрощенный как в go, синтаксис
- мощная IDE (аж две штуки) с интеллектуальным автодополнением и рефакторингом
- nashorn
- перформанс на уровне С++
- нативный трединг
- поддержка windows, unix, osx

ничосе! и ты всем этим занимаешься? да еще на трех операционках одновременно?

umren ★★★★★
() автор топика
Ответ на: комментарий от foror

Да понятно, что кого-то устраивает на php писать сайты, на с++ делать десктоп, на python писать утилиты, на javascript делать фронтенд, а на java делать андроид. У кого-то есть ресурсы завозить под каждый из этих ЯП команду индусов или хипстеров.

У меня таких ресурсов нет и нет времени раскидывать силы на изучение зоопарка ЯП. Для меня java универсальный инструмент для решения выше перечисленных задач.

человек оркестр прямо

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

ничосе! и ты всем этим занимаешься? да еще на трех операционках одновременно?

Не понял юмора. JVM из коробки мне дает кросс-платформенность, мне особо не нужно ей заниматься.

человек оркестр прямо

А что тут особенного? Сайтами я давно занимаюсь, как клиентом, так и сервером. Десктоп еще на делфях пилил, на java очень похоже. Утилиты - так это каждый уважающий себя линуксоид должен уметь на баше, что-т изобразить. Но я сейчас еще пилю фреймворк, чтобы отказаться большей части и от баша. А андроид опять же - тот же десктоп.

Как видишь, java как язык дает огромную универсальность у меня фактически один JDK под все ниши, одни и теже фреймворки, библиотеки, привычная IDE, системы сборки и т.д.

И не нужно каждый раз вникать в новый ЯП и его подводные камни, в новые SDK, в новые либы, в новые IDE и т.д.

foror ★★★★★
()
Ответ на: комментарий от foror

Как видишь, java как язык дает огромную универсальность у меня фактически один JDK под все ниши, одни и теже фреймворки, библиотеки, привычная IDE, системы сборки и т.д.

Она может ее и дает, но везде есть инструмент который дает это лучше (и на Android кстати не Java в твоем понимании, там другое сдк и Dalvik)

И не нужно каждый раз вникать в новый ЯП и его подводные камни

Это плохо, т.к. универсальность всегда влечет за собой низкое качество

Кроме того, что бы зарабатывать много денег, тебе не нужно быть человеком оркестром и ты им по сути не можешь быть, поэтому разные инструменты существуют под разные задачи

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

Она может ее и дает, но везде есть инструмент который дает это лучше (и на Android кстати не Java в твоем понимании, там другое сдк и Dalvik)

СДК там очень похож, иначе оракл бы не наезжал на гугл, что они им кросс-платформенность ломают. ЯП - Java 7. Библиотеки можно запускать как на JDK, так и на Dalvik. IDE на базе Eclipse, система сборки из мира Java. Так что мне нужны минимальные затраты времени, чтобы вникнуть в Android.

Это плохо, т.к. универсальность всегда влечет за собой низкое качество

Понятие «низкое качество» относительны. Я согласен, что некоторые вещи лучше делать на С/С++. Но все остальные вещи можно сделать на java не теряя в качестве. Т.к. все эти ноджс, питоны, руби, пхп и даже не побоюсь этого слова go - на данный момент уступают джаве по перформансу и в удобстве разработки больших проектов.

Кроме того, что бы зарабатывать много денег

Не нужно быть программистом.

foror ★★★★★
()
Ответ на: комментарий от MiniRoboDancer

Тормозят не языки. Тормозит говнокод.

еще может тормозить _реализация_ конкретного языка.

Oxdeadbeef ★★★
()
Ответ на: комментарий от foror

Так что мне нужны минимальные затраты времени, чтобы вникнуть в Android.

You are doing it wrong, Android - совсем другая разработка и там мало чего общего с джавой которую ты пишешь на сервере или на клиенте, другой жизненый цикл приложения, большинство API - другие

Т.к. все эти ноджс, питоны, руби, пхп и даже не побоюсь этого слова go - на данный момент уступают джаве по перформансу и в удобстве разработки больших проектов.

тут у нас идет стандартный bullshit bingo промытых legacy мозгов которые уверовали в святость Java

Не нужно быть программистом.

no comments

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

большинство API - другие

Понятно, что другие. Но чтобы начать программить под iOS, нужно погрузиться в ЯП, понять стиль программистов, его СДК, разобраться с IDE и чем собирать проект. Затем только начать изучать API платформы.

Чтобы программить под Android - мне нужно разобраться, только с API системы. При этом дело это пойдет очень быстро, т.к. мой мозг уже настроен на работу в стиле Java, да к тому же 1/3 API из JDK.

тут у нас идет стандартный bullshit bingo промытых legacy мозгов которые уверовали в святость Java

Ни каких промытых legacy мозгов нет. В них лишь здравый смысл и жизненная опытность.

foror ★★★★★
()
Ответ на: комментарий от umren

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

foror ★★★★★
()
Ответ на: комментарий от foror

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

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

всю убогость и медлительность старта JVM

Достаточно сделать контейнер приложений, когда приложения будут запускаться уже на запущенной и прогретой JVM. Именно это, например, я делаю в своем фреймворке для написания системных утилит. Тем самым, хелло ворд отрабатывает за 5 мс (но вполне вероятно, я оптимизирую это и до <1мс), когда тот же хелло ворд на питоне - за 30 мс.

Если это решение не нравится, то можно просто кешировать сгенерированный JIT код.

Короче, это не аргумент, что нужно большое время для старта. Вопрос лишь в правильной реализации.

сколько она жрет памяти

Память она жрет лишь из-за кривых архитектурных решений из бородатых 90-х. Из-за UTF-16 строк, из-за отсутствия value types и все есть класс.

Так что это опять не аргумент при правильной реализации.

Поэтому, то я и смотрю с надеждой, что выродят из webassembly, может наконец сделают правильную «JVM», которая будет работать на любой табуретке и будет применяться повсеместно, кроме случаев, когда нужно посчитать какую-нибудь теорию струн.

foror ★★★★★
()
Ответ на: комментарий от foror

может наконец сделают правильную «JVM»

не сделают

которая будет работать на любой табуретке

не будет

когда нужно посчитать какую-нибудь теорию струн

не нужно

Oxdeadbeef ★★★
()
Ответ на: комментарий от foror

Забыл самое главное - громадная экосистема от Apache Foundation, JBoss Foundation, Eclipse Foundation, SpringSource, Google

vertexua ★★★★★
()
Ответ на: комментарий от foror

У меня таких ресурсов нет и нет времени раскидывать силы на изучение зоопарка ЯП

Ты преувеличиваешь насколько это сложно и долго

vertexua ★★★★★
()
Ответ на: комментарий от foror

JVM из коробки мне дает кросс-платформенность

Это стало не так актуально. Хотя спасибо Java за времена когда это было актуально.

Десктоп нужен малому количеству проектов, все серверное и браузерное. Теперь Java - хороший инструмент для написания серверных приложений. Причем кроме Linux ничего не надо поддерживать, всякие FreeBSD, Solarix, AIX и остальное говно может смело идти нахрен и гореть в аду для новых проектов.

vertexua ★★★★★
()
Ответ на: комментарий от umren

в итоге джавы в классическом понимании нет нигде, кроме сервера, десктоп просран, андроид это не джава, а на сервере есть решения и получше

Собствено миров осталось 4 - фронтенд, iOS, Android, сервер-сайд. Как бы ты не надрачивал на свои недоязычки, но Java крепко и прочно лидирует для новых и старых проектов в последних двух категориях. iOS и фронтенд - там свои инструменты.

vertexua ★★★★★
()
Ответ на: комментарий от foror

Память она жрет лишь из-за кривых архитектурных решений из бородатых 90-х. Из-за UTF-16 строк, из-за отсутствия value types и все есть класс.

Опять мимо, память она жрет из-за всех этих 100500 «gen» при сборке мусора, в которых указатели разбросаны как попало и часто нужно резервировать два обьема памяти для переноса групп указателей из одного места в другое чтобы уложить их компактнее. Зачастую вообще X памяти блуждает по 3X памяти операционной системыю

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Ты преувеличиваешь насколько это сложно и долго

Если я год писал на java, а затем решил писать на python, то придется восстанавливать знания по python'у и смотреть, что там нового появилось. Меня это не устраивает, если я переключил нишу разработки, то ЯП должен быть тот же, как и SDK.

Я уж не говорю о перерывах в несколько лет. Я, например, довольно хорошо ориентировался в php, а сейчас и не вспомню как там hello world написать.

Сейчас я ушел от веба и пилю системные проекты, и мне было бы удобно вернуться в веб с фронтендом на java, а не javascript. Т.к. последний я подзабыл и мне потребуется некоторое время, чтобы набрать темп на этом ЯП.

Это стало не так актуально. Хотя спасибо Java за времена когда это было актуально.

Да, не так актуально, но очень удобно для самих разработчиков. Захотел работаешь на маке, захотел вынудили - на винде и это очень удобно.

Опять мимо, память она жрет из-за всех этих 100500 «gen» при сборке мусора

Я говорил относительно других ЯП со сборщиками мусора, тот же Go кушает меньше памяти. Или у них GC более грамотно реализован? Отчего тогда не сделают такой же под Java?

foror ★★★★★
()
Ответ на: комментарий от vertexua

Собствено миров осталось 4 - фронтенд, iOS, Android, сервер-сайд

А эмбеддед? Да и я надеюсь, что гугл одумается в скором времени и выкатит шестой андроид на го или чем-нибудь другом (хоть на ноде). А то эта анально огороженная джава до добра не доведет. Еще на дуднет орали, что-то я исков от МС ни к моно, ни к кому-то другому не вижу. А в ораклах всегда одни отбитые работали.

lazy_aleks
()
Ответ на: комментарий от lazy_aleks

выкатит шестой андроид на го

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

что-то я исков от МС ни к моно, ни к кому-то другому не вижу

так оно еле шевелится, что возьмешь с голодранцев?

foror ★★★★★
()
Ответ на: комментарий от lazy_aleks

выкатит шестой андроид на го

go mobile уже есть и он реально работает :)

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

оно так шевелится, что джавка быстрее подохнет

Как-то слабо оно шевелится: https://www.google.com/trends/explore#q=xamarin, phonegap, android studio, un...

Думаю все споры разрешит webassembly, у которого изначально сильные позиции на всех популярных платформах, вплоть до всяких табуреток ) Осталось наблюдать за раком, щукой и лебедем - по классике пойдут и разосрутся, или сдвинут дело с места )

foror ★★★★★
()
Ответ на: комментарий от foror

Думаю все споры разрешит webassembly

ну так иди и юзай уже, webassembly === asm.js

umren ★★★★★
() автор топика
Ответ на: комментарий от foror

на запущенной и прогретой JVM

Каждый раз проигрываю.

Deleted
()
Ответ на: комментарий от vertexua

Кстати, как там Nashorn поживает, не следил годик где-то.

Вначале очень пристально следил, так как прикручивал его для сис. утилит, но потом снизошло озарение, что все эти скриптовые языки - нет за ними будущего )

Просто начав делать веб-фреймворк без поддержки типизации - у меня мозг потек, слава богу в babel трансляторе (es6->es5) есть, как в питоне 3, аннотации типов, так что можно как-то жить.

Если по сабжу, то JVM + движок насхорна с хелло ворд, выкушивает 75 метров оперативки. Появилась возможность кешировать на диск байт-код, который сгенерит движок. Стартует это дело - рука-лицо, порядка 2 сек.

Есть какой-то порт node.js - avatar, но за ним не следил, но люди вроде запускали популярные фреймворки. Как по мне бредовая идея портировать node.js на насхорн.

Из каких-то других проектов ничего нет, там был какой-то генератор pom.xml, строящийся из зависимостей определенных как JS объекты. Больше ничего не встречал.

По перформансу не скажу, но он определенно тяжелее v8, оперативку выжирает покруче джава.

В 9-ке сделают оптимизации, вот здесь про это подробнее https://www.youtube.com/watch?v=aROpSjXr4TU

Возможно будет поддержка es6. Впрочем, я его и сейчас уже научил понимать es6, через babel и собственную эмуляцию es6 модулей. Получается очень прикольно, делать штуки типа import {ArrayList} from 'java.util'.

foror ★★★★★
()
Ответ на: комментарий от vertexua

В общем, я его вижу только как некая прослойка, между клиентом и джавой, чтобы как-то иметь один общий код с клиентом (типа meteor.js). Но делать всякие генерации контента или обрабатывать запросы пользователей конечно только на java.

Эмуляция на нем node.js веб-фреймворков полнейший бред, который не выдержит конкуренции с v8.

foror ★★★★★
()
Ответ на: комментарий от foror

Эмуляция на нем node.js веб-фреймворков полнейший бред, который не выдержит конкуренции с v8.

резюмирую: насхорн не нужен, припарка мертвой платформе, сделали от истерики

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

резюмирую: насхорн не нужен, припарка мертвой платформе, сделали от истерики

Очень нужен, пока на webassembly нельзя будет запустить c# или допиленную java + project panama (хотя оракл может и не разрешить порт на строннюю vm). Nashorn пока может быть удобным средством для запиливания фреймворка типа meteor или angular 2, когда mvc на js, а вся сервер-сайда обработка запросов, кеши и json генерация на шустрой java.

foror ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.