Где-то в глубине инженерной мысли я с вами согласен. Однако правила диктует бизнес, PHP занимает огромную долю рынка разработки, и имеет конкретные преимущества как в скорости разработки, так и в затратах на разработку. Вот альтернативное мнение — stackoverflow.com/a/7902620 . Что позволит валидировать идею, от чего легче отказаться, если идея не работает, что даст быстрый time to market? Супер оптимизированная ракета на C++ за пол года и $XXX или самокат на PHP за 2 недели и $X ?

Не загружен, это канал на одиночный инстанс, а 800MB это пиковый пример. Тут скорее CPU на обработке закончится, чем канал.

а где написано про трансфер по сети за секунду, в слове «распарсить»? входящий канал у нас 40ГБит.

я не автор заголовка ;)

Не понял, но понравилось.

Slack тоже использует Hack, судя по посту их Chief Architect ) www.facebook.com/...​ermalink/856809177805810

С удовольствием бы так и сделали, но структура json не потоковая, и требует связей в разных нодах :\

Хороший вопрос, и про HHVM тоже правда. Пока нет единого мнения на этот счет. Скажем так, мысли такие регулярно приходят, но лучшего решения для текущего стэка, с точки зрения целесообразности миграции, пока не могу найти. Рано или поздно, всё мигрирует на микросервисы и server-less решения. А там уже без разницы, что на чем.

Не могу дать истинный ответ :) И да, и нет, и возможно не PHP вовсе.

ReactPHP в целом очень крутая штука. С Hacklang его можно совместить в режиме partial, и все работает в смешанном коде.

Абсолютно поддерживаю, мы делали через очереди (Gearman/RabbitMq), и дальше с помощью воркеров. Сейчас смотрим в сторону Kafka + Go. Но Hack мы выбрали не только из-за этой одной задачи, это лишь пример, люди любят истории) В целом, используя все возможности языка (strict режим, дженерики, коллекции и тд) сама организация кода становится ближе к C языках, и с ней реально приятнее работать.

Хорошо. По Spl я говорил в докладе, этого просто нет в статье.

По поводу потребления памяти в php пример с Hello world, к сожалению, не подходит. Представьте, что нужно в одном пользовательском поиске распарсить 500-800 мегабайт (это не опечатка) данных из полученных извне json в оптимальные коллекции данных, и потом где-то это закешировать. На все есть 1-3 секунды. Сколько потребуется памяти php на всю задачу (overhead к данным)?

Мы с вами обсуждаем разный pthreads (github.com/krakjoe/pthreads)

подскажите, вы теоретик или практик?

Multi Curl мы используем по полной программе, в Hack есть еще асинхронный curl_multi_await. Но задача не просто опросить параллельно список end-point-ов, а опросить их в цепочке, каждая из которых имеет свой набор и кол-во последовательных запросов, с передачей состояния от одного к другому. Представьте себе дерево запросов, где есть авторизация, инициализация поиска, опрос, расширенный опрос и т.д., а теперь добавьте несколько таких веток, у каждой из которых будет своя цепочка и логика (например отели одного провайдера, другого, и третьего). В php в один момент времени может выполняться работа только одного Multi Curl дескриптора, таким образом если вы будете в коллбек функциях создавать и выполнять последующие дочерние Multi Curl дескрипторы, то родительский дескриптор будет в это время проставить.