Поддержка сложных проектов еще обусловлена отсутствием статической типизации в ПХП, и, как уже говорил, - слабая типизация. Ты можешь быть хоть каким крутым специалистом, но на яве тебе будет проще (имхо).
Что касается производительности: дай яве нужное количество памяти, и все будет хорошо https://medium.com/@mihaigeorge.c/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3

Благо с памятью сейчас проблем нет, хоть терабайтами в сервера пихай.

полудух https://www.google.com/search?q=на чем написан фейсбук
HHVM там был заюзан ДО появления опкешера, так то он и не нужен вроде как.


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

SimpliestПодключений выдержит нормально. Основная сложность при больших нагрузках в умении горизонтально масштабировать "кирпичики".
В пхп это приходит проще, потому что базовая механика работы сама к этому подталкивает.
Но и на Java отлично можно держать нагрузку.


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

SimpliestКлючевой момент в скорости разработки и прототипировании. На пхп это быстрее и дешевле.
Потому и наблюдаем мы "ошибку выжившего" в виде топ-нагруженных проектов на пхп.


Да ну ясно-понятно, если горе-программист я ЯП не знаком (в данном случае с явой), то скорость разработки будет очень низкая. Я ведь так понимаю ваши утверждения на личном опыте основаны?

В общем и целом: быстрее и дешевле - это до определенного момента времени только. Потом будет обратный эффект. Прототипирование/конструирование - это достаточно важный аспект разработки, которым не стоит пренебрегать.

полудухя таки никак не могу взять в толк, что вам та типизация )
я пишу CRM/ERP системы на ПХП (куда ещё сложнее?)
сколько раз мне мешало отсутствие типизации? 0.

Наличие статической типизации мешать не может, скорее наоборот, статическая типизация вам будет мешать :)
как плохом танцору, сами знаете что :)
Чем ЯП со статической типизацией лучше/хуже, - можете почитать в интернете. Если кратко - то лучше ошибки получать на стадии компиляции, а не в рантайме.

полудухну во1, тесты показывают, что узким местом остаётся всё-равно БД, как я и говорил;

Где там в тестах вы БД увидели?

полудухво2, в тестах смешали коней и людей. Зачем там Laravel, он бы ещё битрикс потестил ))

Наверное потому, что эти фреймворки написаны на соответствующих (тестируемых) ЯП, что дает некоторую "нагрузку", не просто так же подключаться и отключаться, правильно? Все таки в ЯП это далеко не единственный показатель производительности.
А битрикс там лишний, просто взяли аналогичные инструменты в разных ЯП. Между прочим ларавель еще относительно быстрым ФВ считается.

полудухПХП в качестве демона с libevent держит 50k+/сек. Причём и с гигом памяти.

И? Клиент же не просто подключается/отключается.

полудухлучше всего ситуацию объясняет вот этот коммент:
авторI love Node, but you’re being totally unfair here. Laravel is an entire framework which loads tons of libraries and dependencies before even reaching your code, while in your Node code you pretty much just wrote to the compiler itself. Have you tried using Loopback or Sails or some full-stack framework? There actually aren’t many around, you pretty much have to program everything yourself over Express, which makes the code harder to maintain and secure than having a full framework doing it for you with regular security patches.

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

ShSergeHettДа как бы ява считается более быстрой, нежели пхп. А вы там себе дальше представляйте как фейсбук работает на пхп (ага, конечно ) и обабатывает миллиард пользователей одним инстансом.
Я не уверен, что ява быстрее.Там самая проблема - передача данных по сети, а не язык программированич.
А в чем проблема?

полудух
и, кстати, если вы уж тут в дискуссии участвуете и задаете вопросы мне, будьте добры тоже на вопросы отвечать,
все еще жду ответа:

Hettполудух https://www.google.com/search?q=на чем написан фейсбук
HHVM там был заюзан ДО появления опкешера, так то он и не нужен вроде как.


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

ваша компетенция ясна :)

SimpliestТам не нужно уметь из коробки. Обработал - умер. Намного проще масштабировать.
Именно такая реализация и упрощает горизонтальное масштабирование. Поскольку оно отдано на откуп сторонним решениям.
У тебя просто нет другого выбора.

Что-то я не понял. Как связано время скрипта с возможностью его масштабирования? Не могли бы хоть пример привести какого-то популярного решения?

SimpliestЕстественно проще списать на то, что "какой-то" программист чего-то там не знает.
Ведь у вас-то несомненно все иначе. И вы ровно все знаете...

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


SimpliestНо я правильно ведь понимаю, что ваш личный опыт эту область знаний не покрывает?
Какую "эту"?

авторПотом сравните с собственным "дело имел" и помолчите.
Это типа много?

Честно говоря я не понял, хабр - один из твоих личных проектов?

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