Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Проект Wikipedia перешёл на использование HHVM для выполнени..., opennews (ok), 07-Янв-15, (0) [смотреть все] А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было , Ящ (ok), 11:10 , 07-Янв-15, (1) –7 // Что кстати характерно, она может и не сильно тооще бы стала у них там в после, vitalif (ok), 11:19 , 07-Янв-15, (3) +1 // На графике загрузка ЦП уменьшилась с 60 до 10 - в шесть раз, что вполне неплох, Нанобот (ok), 11:59 , 07-Янв-15, (9) +1 1 И поддерживать было бы проще, чем устраивать попрыгушки с одной среды исполн, Ящ (ok), 12:01 , 07-Янв-15, (10) +2 // Жаба-то, Grammar_Nazi (?), 15:51 , 07-Янв-15, (31) +2 Жаба - не то , Аноним (-), 00:43 , 09-Янв-15, (85) edited Не-торт , count0krsk (ok), 20:27 , 09-Янв-15, (101) Да будто их каждый день устраивают Жаба всяко не лучше, уж кол-во непереносимого, cmp (ok), 16:24 , 07-Янв-15, (33) –2 Мсье, вы когда в последний раз видели Java Или вы пишите нам из криокамеры , Аноним (-), 18:36 , 07-Янв-15, (38) Вы не работали с Java всерьез и порете чушьЭта платформа на сегодня обеспечивает, edwin3d (ok), 18:53 , 07-Янв-15, (41) +1 Даже палкой с трех метров трогать не хочуПотому что, дистр какого размера бинар, cmp (ok), 22:02 , 07-Янв-15, (52) –1 Разрабатываете случаем не на PhpStorm А то он тоже долго грузится, если вы пони, vn971 (ok), 00:43 , 08-Янв-15, (54) +2 нет, не разрабатываем, исключительно эксплуатируем и как показывает практика - а, cmp (ok), 04:06 , 08-Янв-15, (56) –1 Дружище, абсолютно согласен по поводу Java Нет, может проггерам и видно, что та, Аноним (-), 10:16 , 12-Янв-15, (109) Т е открываем рот не имея реального опыта работы Когда ф-ть php достигнет 5 от, edwin3d (ok), 08:40 , 08-Янв-15, (61) +1 Когда функциональность java достигнет хотя-бы 1 от наушников сообщите А вообще , рубин (?), 13:12 , 08-Янв-15, (73) +1 Уважаемый, опыт работы может быть разным, ваши супер нагруженные сервера это отл, cmp (ok), 16:01 , 08-Янв-15, (77) –2 Жаба как эталон дырявости , tor (??), 14:15 , 12-Янв-15, (110) На жабе или не на жабе, на, в любом случае, с самого начала надо писать на норма, YetAnotherOnanym (ok), 11:51 , 07-Янв-15, (7) +6 // стартапы редко пишутся на нормальных языках быстренько набросать на руби сайтик, Гаражник (?), 20:44 , 07-Янв-15, (49) +1 Ага, её бы тогда вообще не существовало Нет сайта - нет проблем , Аноним (-), 14:00 , 07-Янв-15, (22) +5 Это как раз общая беда многих проектов Сначала некие энтузиасты, часто весьма н, edwin3d (ok), 18:51 , 07-Янв-15, (40) –1 // а потом приходят профессионалы с такой же низкой квалификацией и начинают пере, all_glory_to_the_hypnotoad (ok), 20:24 , 07-Янв-15, (48) +4   // Ваше словоблудие не имеет ничего общего с реальным положением дел К примеру прин, edwin3d (ok), 21:41 , 07-Янв-15, (50) –1   Знал бы типичную аудиторию пыхеров и ява гогнокодеров, то не писал бы такой херн, all_glory_to_the_hypnotoad (ok), 17:24 , 08-Янв-15, (80)   Да, в дополнении Java позволяет делать такие вещи, про которые в других платформ, edwin3d (ok), 21:59 , 07-Янв-15, (51) –1   Тоже мне, аргумент Сейчас такая задача тривально решается на Go или node js Ра, Crazy Alex (ok), 14:05 , 08-Янв-15, (75) +2   С Go не работал проф , комментировать не имею права Про Node У Вас недопони, edwin3d (ok), 14:53 , 08-Янв-15, (76) –2   Я намекал, что есть масса способой обработать большой поток запросов И нормаль, Crazy Alex (ok), 19:31 , 08-Янв-15, (83)   Теперь я понял, что Вы изначально имели ввиду жаль, что нам понадобилось так, edwin3d (ok), 10:26 , 09-Янв-15, (91) –1   Это какой-то детский сад, как раз иллюстрация к картине профессионализма типично, all_glory_to_the_hypnotoad (ok), 22:30 , 08-Янв-15, (84) +2   Вообще-то в 90-е самым продвинум откровением был prefork Та модель в которой гов, edwin3d (ok), 10:13 , 09-Янв-15, (90) –1   Сколько же словестного поноса, ужас Всё верно, только писать нужно правильно, , all_glory_to_the_hypnotoad (ok), 22:15 , 09-Янв-15, (105)   Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема, Аноним (-), 19:48 , 07-Янв-15, (44) +2 // mediawiki в свое время поразил меня качеством кода, по сравнению с другими php-п, dev (??), 12:04 , 08-Янв-15, (68) ага, были бы проблемы куда круче , all_glory_to_the_hypnotoad (ok), 20:21 , 07-Янв-15, (47) А разве 2 раза не равно 200 , Аноним (-), 11:19 , 07-Янв-15, (2) // Если сократить среднее время сохранения страницы на 200 , получится машина време, EHLO (?), 11:31 , 07-Янв-15, (6) +5 // Увеличение на 45 - это почти в полтора раза Но никак не в два , юзер (??), 12:22 , 07-Янв-15, (12) +2 // Не увеличение, а сокращение ускорилось , Аноним (-), 13:26 , 07-Янв-15, (15) ЕГЭ-шные математики понабежали x-45 0,55xx 0,55x 1 8 - что и есть почти , Аноним (-), 13:33 , 07-Янв-15, (16) +1 Непонятно чего на человека налетели - написано ведь неправильно тоесть скорость , anonymous (??), 14:32 , 07-Янв-15, (27) +2 // Прошу прощения, конечно, не 2 2 а 1 81 и соответственно ускорение на 81 81 , anonymous (??), 14:42 , 07-Янв-15, (28) А есть сравнение сабжа с opcache, Аноним (-), 11:22 , 07-Янв-15, (4) –2 // Это вопрос, Аноним (-), 11:29 , 07-Янв-15, (5) +3 // Это вопрос, EHLO (?), 12:30 , 07-Янв-15, (13) +3 // Вопрос ли это вопроса или вопрошение спрашивающего , Kodir (ok), 14:06 , 07-Янв-15, (24) +2 Ты задаешь слишком много вопросов , Какаянахренразница (ok), 18:46 , 07-Янв-15, (39) +5 Написано же, что с 5 6 где опкеш по дефолту включен , разрыв не такой уж большо, йцу (?), 09:08 , 08-Янв-15, (62) // Уверен, дело явно не в опкеше, ибо ни кто в здравом уме и до этого без опкеша не, funny_falcon (?), 10:43 , 08-Янв-15, (66) // Значит неверно понял вопрос Вообще бенчмарков за последний код была целая куча,, йцу (?), 13:07 , 08-Янв-15, (72) Вот и славно поработали, а то понимаешь прочтите сообщение от Джимми Уэйлса , Аноним (-), 11:57 , 07-Янв-15, (8) +2 А что ты сделал для хип-хопа в свои годы , Аноним (-), 12:11 , 07-Янв-15, (11) +7 // гггг Я так понимаю, Богдан Титомир и был основоположником ПХП , Kodir (ok), 14:07 , 07-Янв-15, (25) –3 // А разве это не Децл пел в свое время , count0krsk (ok), 21:17 , 09-Янв-15, (103) –1 не дождались PHP NG, а могли бы получить тот же двухкратный прирост на самом об, Sylvia (ok), 13:05 , 07-Янв-15, (14) // Некоторые вон реактос уже ждут 17 лет Может быть, ну его, это ожидание , Аноним (-), 13:49 , 07-Янв-15, (18) +3 // Да ладно Зачем Для чего почему Разве они не вымерли выросли ещё, так и жд, EuPhobos (ok), 23:51 , 10-Янв-15, (108) +1 и как там с совместимостью если в обычном php только и успевают раздавать depre, бедный буратино (ok), 13:49 , 07-Янв-15, (19) –1 // PHP NG тоже уже реально работает, это текущая ветка разработки релиз планируется, Sylvia (ok), 17:31 , 07-Янв-15, (36) +1 // xcache - это стороннее расширение, которое никогда не было частью проекта php В, Аноним (-), 20:02 , 07-Янв-15, (46) –1 не надо мне рассказывать,автор не только не сделает форк без опкод кешера, но и , Sylvia (ok), 22:02 , 07-Янв-15, (53) а что не так с opcache , Аноним (-), 17:17 , 08-Янв-15, (78) нет свапа на диск - требуется выделение большого сегмента памяти, сразу под все, Sylvia (ok), 01:57 , 09-Янв-15, (86) Ну я имею ввиду чисто как опкод-кэшер Со свопом понятно, хотя у меня даже крупн, Аноним (-), 18:09 , 09-Янв-15, (100) Что интересно - PHP7 даёт сопоставимую по крайней мере производительность при , йцу (?), 13:14 , 08-Янв-15, (74) –1 Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип, Аноним (-), 17:24 , 08-Янв-15, (79) В плане типов - уже сто лет как существует type hints и активно используется для, йцу (?), 11:20 , 09-Янв-15, (94) так уже работоспособно , берем снапшот с git master и вперед на подвиги Dне, Sylvia (ok), 02:15 , 09-Янв-15, (87) PHP, Wordpress - Тяп ляп и в production , Graynder (ok), 02:51 , 09-Янв-15, (88) ну у большинства так и естьhttp blog bnkomi ru content post 13855 vovka_327873, Sylvia (ok), 05:46 , 09-Янв-15, (89) стоп, а разве JIT уже в мастере Стогов вроде писал, что пока только работают на, йцу (?), 11:08 , 09-Янв-15, (92) ветку phpng уже отправили в master, дачто там с JIT я пока не в курсе, большинст, Sylvia (ok), 11:19 , 09-Янв-15, (93) Ну да, про это в курсе Но нет, JIT там пока нет Не факт что будет в PHP7, хотя, йцу (?), 11:22 , 09-Янв-15, (95) Совместимость на уровне php-кода - практически 100 , за исключением пары недокум, Аноним (-), 19:57 , 07-Янв-15, (45) хип-хоп маньяки на острие атаки ps не взлетит в смысле, завтра ещё 400 серверо, бедный буратино (ok), 13:48 , 07-Янв-15, (17) –8 // Уже взлетело и развернуто , Аноним (-), 13:50 , 07-Янв-15, (20) +3 чтоб взлетело, попробуй его авиатопливом заправлять а то на самогоне оно ясен п, Нанобот (ok), 19:25 , 07-Янв-15, (43) –1 этот хихивм поддерживает последние фичи пыха , manster (ok), 14:02 , 07-Янв-15, (23) –2 // больше того он ещё и типизированный PHP поддерживает под названием Hack , vitalif (ok), 17:10 , 07-Янв-15, (34) Да У меня завелся и взлетел портал без проблем Проблемы возникли со сторонними, SubGun (ok), 02:20 , 08-Янв-15, (55) Вместо миграции на новую версию php, они смигрировали куда-то вбок , universite (ok), 15:18 , 07-Янв-15, (30) а где исходники хочу под слакварей попробывать, qwerty (??), 15:56 , 07-Янв-15, (32) –2 // http hhvm com на i686 не работаеть, и не будет , Sylvia (ok), 17:34 , 07-Янв-15, (37) За 9 месяцев можно было переписать всё на что-то более адекватное, чем php И ни, th3m3 (ok), 17:28 , 07-Янв-15, (35) –1 // Ага, давай, начинай переписывать Ты сначала посмотри сколько там кода, а потом , vitalif (ok), 19:19 , 07-Янв-15, (42) +4 // А что поделать , th3m3 (ok), 07:42 , 08-Янв-15, (60) // Может попробовать перестать нести чушь , йцу (?), 09:11 , 08-Янв-15, (63) Если бы разрабы вики имели мозги, они сам проект никогда не начали бы на похапэх, Kodir (ok), 15:28 , 09-Янв-15, (96) Эээ Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах, Dzmitry (??), 04:47 , 08-Янв-15, (57) –3 // Верно ли я понимаю, что у вашего приложения также не меньше 20 миллиардов просмо, gaga (ok), 12:07 , 08-Янв-15, (69) +1 бывает, да ну ничего, со стороны это незаметно обычно если будешь молчать, окр, arisu (ok), 18:35 , 08-Янв-15, (82) +1 1 Запрос дольше 1 секунды - это уже дикость Тем более, что у вики структура з, Kodir (ok), 15:30 , 09-Янв-15, (97) –1 Понимаете, запросы бывают разные, совсем разные я займу у Вас 5 мин вот бы у, edwin3d (ok), 17:51 , 09-Янв-15, (99) –1 древний движок википедии не тормозил на 64киб,а щас гамно на андроиде в фирефок, Аноним (-), 06:02 , 08-Янв-15, (58) –1 форкать надо ето дело , Аноним (-), 06:03 , 08-Янв-15, (59) // ДАВНО УЖЕ Лурк - наше всё , Kodir (ok), 15:31 , 09-Янв-15, (98) –2 Долго читаю здесь подобные разговоры Насколько я понял, от качества языка зависи, Аноним (-), 10:27 , 08-Янв-15, (64) –3 // Дополню свое сообщение От качества языка зависит, конечно же, не только скорость, Аноним (-), 10:42 , 08-Янв-15, (65) –2 // Шире, причем сильно И соседство PowerPC и x86 серверов вполне реальная картина , edwin3d (ok), 10:58 , 08-Янв-15, (67) // И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем случ, Аноним (-), 12:10 , 08-Янв-15, (70) –1 С точки зрения энергосбережения это было бы О-ГО-ГО, Аноним (-), 12:17 , 08-Янв-15, (71) потому что бутылочное горлышко у серверов уже давно не процессоры, а ПЗУ и сет, Аноним (-), 17:45 , 08-Янв-15, (81) Жесть Стоило раз в позитивном ключе заикнуться про жабу , Ящ (ok), 21:14 , 09-Янв-15, (102) –1 Давно пора ее переписать на ноде-дж-с, Аноним (-), 21:21 , 09-Янв-15, (104) –1 // Шило на мыло , Ящ (ok), 08:12 , 10-Янв-15, (107) Мне вот интересно, а когда уже напишут граматику MediaWiki на C и вкопилят в Си , Vitold S (?), 03:38 , 10-Янв-15, (106) 1,2,4,8,11,14,17,23,30,32,35,57,58,59,64,102,104,106

Сообщения

[Сортировка по времени | RSS]

	48. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 07-Янв-15, 20:24
	а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать на java заменяя одни простые решения на другие.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok), 07-Янв-15, 21:41
	> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать > на java заменяя одни простые решения на другие. Ваше словоблудие не имеет ничего общего с реальным положением дел. К примеру принятый как стандарт разработки в стартапах и засунутый во все дыры ORM (увеличение скорости разработки - что поделаешь) назвать простой вещью может только человек, который не понимает, какая прослойка стоит за ним. Равно как и не понимающий, что начиная с определенного уровня нагрузки в ряде участков он должен быть выкинут. Реальные архитектуры не умерших приложений не имеют ничего общего с "простыми решениями". Так и так все сложно. или очень сложно. А на сложные проекты приходят команды, уровень квалификации которых куда выше, чем кажется Вам. И берутся разгребать. И делается это очень успешно, вопреки Вашим сказкам. Примеров - тьма, как к примеру в Twitter, где после анализа ряд крит. участков переписали на Java, что решило ряд проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 08-Янв-15, 17:24
	Знал бы типичную аудиторию пыхеров и ява гогнокодеров, то не писал бы такой херни. Во-первых, пыхеры слишком тупы чтобы пользоваться какими-то там ORMами, типичный их упровень это портянки из SQL шаблонов. А прослойки между всем типичен как раз для ява кодеров, благо в ява стеке они есть практически для всего и характерный ява кодер вообще почти ничего не знает за пределами API всех этих прослоек - сырой SQL видел только в википедии, протоколы для них это какая-то загадка и тому подобное. Грубо говоря, пыхеры и ява кодеры это две противоположности дилетанства, одни любят обвешиваться ненужными прослойками, а другие не в состоянии пользоваться даже простым абстрагирующим API. > А на сложные проекты приходят команды, уровень квалификации которых куда выше это сильно зависит от бюджетов и области деяетельности. Реально таких специалистов могут себе позволить только крупные компании завязанные на инет бизнес. Даже у них не всегда с кадрами всё так хорошо и в принципе ява кодеров подпускают фрагментально к сложным задачам. А уже в высокобюджетном энтерпрайз классе работают дилетанты немногим выше уровня пыха.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok), 07-Янв-15, 21:59
	> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать > на java заменяя одни простые решения на другие. Да, в дополнении: Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются Вот Вам самый простой пример: у Вас есть задача периодической обработки большого количества входящих запросов, пусть http, без блокирования основных потоков AS, без выноса этих задач куда-то в 3-е штуки. в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. Статусы, синхронизации, блокировки - все работает, если руки не из ж.. Теперь возьмем Ruby и любимый RoR ... мало вспоминать про GIL И других вещах, которые буквально ограничивают нас всех при решении задач такого класса. Могу ли я сделать тоже самое ? С костылем - да, потратив больше времени. Будет ли оно работает - будет. Только с большими проблемами в плане производительности, из-за нюансов блокировок, невозможности сделать то или иное нормально и т.д. Именно потому, такие вещи как Cassandra на Java, а MongoDB - C++, а Redis - на C
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	75. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Crazy Alex (ok), 08-Янв-15, 14:05
	Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. Раньше - для этого был (и есть) erlang/OTP. Обратите внимание - абсолютно разные подходы к построению языка и рантайма, что намекает - не в "особенности" явы или JVM дело, а в том, что всяким рубистам оно не слишком-то надо. Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Очереди (которые *MQ), опять же, тоже не вчера придумали. То, что жаба распрстранена - никто не спорит. Но язык убогий, каковым, он,  вобщем-то, и планировался.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от edwin3d (ok), 08-Янв-15, 14:53
	> Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. С Go не работал проф., комментировать не имею права.   Про Node... У Вас недопонимание разницы между понимание асинхронной обработки с псевдо потоками и полноценной многопоточной архитектурой. Вы пытаетесь мне доказать, что Node.js который по фактически не имеет нормальной многопоточности и инструментов работы с ней будет сопоставим с нормальной многопоточностью в Java при решении одинаковой задачи. Про то, что в Node.js просто не способен реализовать ряд решений, Вы забываете ? > Раньше - для этого был (и есть) erlang/OTP. Знаете, Erlang - решение крайне нишевое, но почему Вы его в раньше поставили - ума не приложу. Он весьма активно используется в соот. кругах и теперь, более того - активность его использования растет, причем на глазах. Erlang - это д-но шедевр для HL. К примеру RabbitMQ - это очень яркий пример. А вот ставить его в один ряд с Node.js не стоило - это платформы разных уровней, т очень большое оскорбление для детища Ericsson >  Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Мы не может реализовать нормальную многопоточность и потому будем искать аргументы почему она не нужна, позиция удобная аж жуть берет ... Теперь про нагрузку - на ЦПУ относительно да. А вот по памяти ... извините, но fork и послед. события дают такой расход, что. Даже такие фишки как copy on write не всегда кардинально меняют ситуацию, да и платформенно зависимые они. Ед. здравый аргумент - многопроц. приложение и сделать проще и работать с процессами отдельными также проще, это факт.   > Очереди (которые *MQ), опять же, тоже не вчера придумали. Ну вот, опять встраиваете костыли которые делают решение оригинальной задачи иным. Технологически иным, при это добавляя сложность и т.д. Забавно выходит ... сперва мы ставим некий Node, привязываем еще вагон внешних систем,  которые компенсируют ублюдочность самой платформы приложений. Давайте честными будем перед самим собой - на сегодня для большей части новых проектов ед. критерий - скорость разработки независимо от степени ублюдочности результат. Но это не повод обзывать более корректно реализованные тех. решения ... каждому -свое.   > Но язык убогий, каковым, он,  вобщем-то, и планировался. Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Crazy Alex (ok), 08-Янв-15, 19:31
	Я намекал, что есть масса способой обработать большой поток запросов. И "нормальные потоки" - только один из них. Там, где вычислений мало, а I/O много - нода вполне на месте. Где летает мало данных, но у них тяжелая обработка - хороши MQ и независимые узлы, что почти автоматом даёт масштабируемость, в отличие от тупой потоковой модели. А можно всё это скомбинировать, достаточно дешево добавив решения, оптимальные для той или иной задачи. Собственно, я ещё не видел больших проектов, где было бы меньше трёх языков задействовано. Бывало, что это были очевидные костыли - пришел кто-то и добавил скрипт на питоне в проект на PHP, а потом его тащат три года. А бывает осознанный выбор решений с учётом их сильных сторон - где-то хорош демон на сях, который предельно экономно расходует память, где-то веб-морда на рубях, для которых разрабатывать удобно, где-то бизнес-логика - хоть и на той же джаве, хоть на Go, хоть на чём. Эрланг "был" - потому что, во-первых, он был первым индустриальным решением, умеющим хорошо работать с подобными задачами, а, во-вторых, он всё же несколько архаичен в синтаксисе и сейчас, когда есть больше альтернатив, можно выбрать что-нибудь более распространённое. С другой стороны - в плане "индустриальности" - то есть надёжности и наличия инструментов деплоя, мониторинга, обновлений и т.п. - он спокойно поспорит с J2EE в любой инкарнации. Если говорить про оверхед по памяти - не согласен, сорри. Сейчас, по факту, всё больше дело идёт к тому, что каждый поток держит свою копию практически всех данных. Банально потому, что иначе имеем лишнюю связность и рано или позно - проблемы с синхронизацией. Конечно, если форкать JVM или ещё что-то подобное - то оверхед велик. А если нечто, что не тащит такой здоровеный рантайм и без необходимости память не забирает - тут получше ситуация. А что до платформозависимости - по факту сейчас есть только одна мейнстримная платформа, если речь идёт о джаве, пхп или альтернативах - Linux/Intel. И на ней форк крайне дёшев. > Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ? А вот тут и кроется непонимание. Экосистема - велика и хорошо проработана. J2EE и тому подобное. Отлаженные фреймворки. туча специалистов и документации. И, собственно, этой проработанностью и берёт - даже там, где можно сделать красивее, часто разумнее и выгоднее пойти по хорошо накатанной дороге и нагородить стандартный тяжелый стек - со спрингом каким-нибудь и тому подобным. А как язык джава по сравнению с тем же C#, C++, Rust, D - примитивна и многословна. И по сравнению с Ruby примитивна. Одно время была надежда, что Scala будет лучше в этом плане, но, насколько я понимаю, на практике всё оказалось не так красиво, как хотелось.  Эта примитивность и выливается в монструозные фреймворки с полутора десятками уровней иерархии, которые плохо понимаемы и плохо оптимизируемы. А JS с нодой - он на отдельную экосистему, как мне кажется, пока не тянет, и как язык лично мне не нравится, но здесь многие не согласятся. Зато на её элемент - вполне. У него есть свои жирные плюсы - то, что один и тот же код умеет работать на клиенте и сервере - иногда очень удобно. Что можно легко перебрасывать людей между фронтэндом и бэкэндом в зависимости от загрузки - тоже. В общем, выбирать надо разумно, а не упираться в одну технологию.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok), 09-Янв-15, 10:26
	Теперь я понял, что Вы изначально имели ввиду ... жаль, что нам понадобилось так много времени и жаль, что я не понял Вас с самого начала. Если говорить о Scala, то там как мне кажется основная корень проблемы лежит в том, что многие разработчики пытаются на ней разрабатывать в привычном стиле, не используя плюшки. Т.е. по сути переходя на нее, они остаются на фактически чистой Java. Это накладывает отпечаток, причем серьезный ... у нас на работе была одна подсистема, которую решили перевести как раз на Scala, Так вот вместо 3-х месяцев понадобилось почти 6. Чтобы люди начали писать именно на ней. И люди не дураки были К слову обратите внимание на Groovy, он также весьма привлекателен в плане возможностей и  по моему мнению более прост в изучении и восприятии. то касается нашей дискуссии о fork, То если поставить граничные условия: - одна платформа, главное - где работает copy on write - минимум общих данных То в рамках таких допущений можно принять что выгода от скорости разработки позволяет пренебречь некоторыми моментами. Но в других случаях - не могу согласиться
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 08-Янв-15, 22:30
	> Вас есть задача периодической обработки большого количества входящих запросов... > Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются > в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Для "большого количества входящих запросов" (tm) тупая схема из начала 90 давно уже не работает. Причём даже для всех скриптовых ЯП делают сложнее обвязки, за исключением быть может пыха.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	90. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok), 09-Янв-15, 10:13
	>> Вас есть задача периодической обработки большого количества входящих запросов... >> Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются >> в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. > Для "большого количества входящих запросов" (tm) тупая схема из начала > 90 давно уже не работает. Вообще-то в 90-е самым продвинум откровением был prefork. Та модель в которой говорю я стала по настоящему массово работоспособной в первой половине 2000-х и до сих пор применяется и будет применятся в приложениях. Безотносительно того, как каком ЯП написано решение. > Причём даже для всех скриптовых ЯП > делают сложнее обвязки Потому что сами платформы не способны обеспечить элементарные инструменты. Решение задачи передается внешней подсистеме, которая обладает необходимым качеством. Еще раз разберитесь, что представляют собой технически сегодня многие популярные вещи, разберитесь что такое GIL B т.д. Т.е. дело как раз в коренной ущербности, где для простоты выкидывается множество функционала. Это оправданно в ряде случаев, но технологически это порождает схемы, при которых в роли стержня выступает убогая обвязка на которую нанизываются внешние системы, которые решают эти задачи. Но не надо делать вид, что убогость - это мол благо. Надо просто и честно говорить, что к примеру разработчики способные работать с такими вещами стоят денег и их не так много, а типовой конструктор покрывает 99% стартаперских задач > Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности, при этом делая вид, что технологически так лучше. Но Вы делаете вид, что объявляете основу ряда систем "приветом из 90-х" И вообще конечно, пулы потоков, выносы в отдельный потоки Slow запросов и т.д.  - это не для Вас. Пользуясь Cassandra написанной на Java в роли NoSQL БД Вы конечно будете продолжать орать какая Java плохая и какие там кодеры плохие Или пользуясь Pum'ой (как по мне - самый лучший Web для Ruby приложений при высокой нагрузке), где применены похожие принципы
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 09-Янв-15, 22:15
	Сколько же словестного поноса, ужас... > Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности Всё верно, только писать нужно правильно, вот так: > Это степень иллюстрации грамотности лиц, которые используют подходящую архитектуру сервиса вместо применения единственного известного одному гогнокодеру "стандартного" решения
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема