Одно из мнений о будущем PHP

Что значит «не рассчитанные»? Ну так используйте те что рассчитаны. На самом деле что синхронная модель в php, что псевдо-асинхронная в node.js, разница не так уж важна. В node.js довольно легко написать так, что асинхронный он, или нет, но тоже может залочиться весь процесс на какое-то время. + как уже упоминалось ниже — callback-hell (да, промисы минимально это дело разруливают но все же).

Словом, я считаю что в своей нише php нормально себе живет и будет жить. А вот попытки переместить php куда-либо дальше web я считаю странными.

А не могли бы Вы уточнить, о каких вещах в отдаче статики Вы говорите? Для расширения кругозора, так сказать…

Я занимался немного разработкой на node.js и async модуль хорош, но это все равно не позволяет писать код в классическом стиле, лучше смотреть в сторону yield и подобных вещей. Еще я встречал фаната erlang, который рассказывал про ассинхронность у языка в крови и вообще что нет callback-hella и есть более продвинутая система распараллеливания на несколько ядер.

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

«Всё есть объект» в виде кода — не значит, что «всё есть объект» в виде внутреннего представления. Вполне достаточно использовать те же самые операции при обращениям к методам скаляра (с помощью функций) или проверять на скаляр и заменять на аналогичную функцию:

— $string->length на strlen($string);
— $string->toLower() на strtolower($string);
— $string->toLower()->toUpper(); на strtoupper(strtolower($string));

То что внутри рубей это реализовано по другому до такой степени, что пришлось изобретать два разных типа строк (константная — :string и объект — «string») — это проблемы реализации рубей. Если в пыхе требуется поддержка скаляров, как объектов, то помимо возможностей препроцессора внутри самого языка (через кастомные фильтры) есть ещё целое расширение — уже давно nikic это реализовал: github.com/nikic/scalar_objects но почему-то никто особо (особо — это значит как другими пекловскими расширениями, вроде runkit, apc, mcrypt, libevent, intl) этим не пользуется =) Даже hhvm пользуется большей популярностью, имхо.

При этом, сознавая всю красоту ОО подхода к скалярам я придерживаюсь мнения автора поста — это плохо, если разделять методы или свойства к каждому скаляру по отдельности — получим тысячи ошибок вызова методов, просто потому что в переменной в этот момент времени был другой тип переменной. А если делать общие методы для всех типов, то получим ещё большую мешанину, сейчас хотя бы префиксы есть, не везде, но зачастую. Что должно делать "->replace()"? Это аналог array_replace или str_replace? Или может preg_replace? Или суперпопулярная функция substr_replace?

Т.е. если подытожить, то максимум что стоит сделать — это:

— Вынести функции в подпространства, по ходу написав соглашение именования аргументов:

str\replace("string", "s", "a"); // atring
// или, на крайний случай
str::replace("string", "s", "a"); // atring

— Добавить множественный импорт из пространств имён:

use str/*;
use array/*;
use str/substr/*;

— Добавить возможность разрешения конфликтов имён классов внутри конечного кода:

use Std\Some\Any;
use Any\Some\Ololo\Any;

new Any; // первый use
new Ololo\Any; // второй use

Остальные модные тенденции превращать всё в объект — фтопку. Опять же, имхо.

Хорошо, перефразирую. Скорость руби + рельс. В случае каких-нибудь нитро или синатры — результат будет конечно намного отличаться.