Не спорю. И pthreads есть еще и много всего. Но ZTS и еще одно расширение. Но - главным образом - ZTS. Это я и назвал "танцы с бубном" :) Может быть я и не прав.
Редко что комментурю, но ваша итоговая таблица, прям просит это сделать.
Типизация - PHP, конечно, динамически типизированный, но статическую типизацию туда завозят очень давно. И, при некоторых условиях, она работает очень хорошо. Особенно в паре с линтерами.
Производительность - в PHP 8 завезли JIT. Внезапно. А у вас, простите, CPU-Bound задачи, чтобы указывать именно на производительность языка?
Масштабируемость - напилить микросервисов на Symfony конечно же нельзя, да? Не понимаю какое тут может быть архитектурное ограничение, кроме как в голове архитектора.
Поддержка многопоточности - тут не спорю, в PHP это либо форки, либо танцы с бубном. Пока движуха ограничилась файберами
Зрелость и стандарты - экосистема PHP - вполне зрелая. Набор PSR - это стандарты. Всё там нормально с этим.
Инстурменты и фреймворки - PHP-экосистема очень даже зрелая. А Symfony - по сути фреймворк Enterprise уровня. Может не стоило переходить в свое время на Laravel, а надо был смотреть в сторону более сложного фреймворка? Документация к Symfony отличная, да и по остальным важным инструментам - всё отлично.
Документация и best practices - ну я уже всё написал. На энтерпрайз решения - всё документировано. На поделки - ну тут как автор поделки захочет.
Безопасность - в PHP нет поддержки JWT? OAuth? Ну вы сейчас не серьезно же, да?
Обучение и комьнити - противопоставление странное. И там и там полно возможностей.
Экосистема и интеграции - покажите примеры, чего вам не хватало и пришлось писать руками? BigData? А что именно?
Сама таблица ограничений проекта на PHP : Монолитная MVC‑архитектура - ну так распилите :)
Устаревший фронтенд (AngularJS, jQuery) - причем тут PHP?
SQL‑поиск по базе данных - причем тут PHP?
Обмен через FTP и файлы - причем тут PHP?
Отсутствие DAM‑системы - причем тут PHP?
Ручная фоновая обработка (CLI) - причем тут PHP?
Нет многопоточности и асинхронности - если с многопточностью я еще худо-бедно соглашусь, она не тривиальна, то асинхронность - ну вы просто не умеете ее готовить в PHP, так и скажите.
Зависимость от нестабильных библиотек - используйте стабильные, такие как Symfony, например, и ее компоненты.
Итог: вы просто хотели переехать на java. Хотели бы поддержать решение на PHP - поддержали бы и всё отлично могло работать. Ну или можно было критические части системы сделать на более производительных технологиях, оставляя те, что IO-Bound на более дешевых.
P.S. Хотя сам на PHP уже не пишу, но приведенные аргументы прямо просят им оппонировать.
Именно так я и делал. А потом копипастил url пакета в go get. И именно этот процесс хотелось ускорить. Мнемонические альясы оказались достаточно удобны. Касательно лезть в конфиг - помощь по команде выдает полный конфиг, по которому можно поискать. Пример: gost mod --help | grep mongo
Видимо весьма зря я статью начал с использования именно для старта нового проекта. Вобщем-то основная проблема была в другом. Вот мне посреди разработки проекта понадобился lru. Я помню, что у меня где-то используется его достойная реализация. Ок, поискав, я найду что это github.com/hashicorp/golang-lru
Но я совершенно не могу помнить как он пишется (или как пишется, например, github.com/valyala/fastjson). Мне нужен был инструмент - указал имя библиотеки -> она появилась в проекте (gost mod lru или go get github.com/hashicorp/golang-lru). Я сделал себе такой инструмент и, спустя время его использования, решил поделиться с сообществом. А запуск на основе его проекта - это уже побочный эффект, оно ничего не стоило.
Не спорю. И pthreads есть еще и много всего. Но ZTS и еще одно расширение. Но - главным образом - ZTS. Это я и назвал "танцы с бубном" :) Может быть я и не прав.
Редко что комментурю, но ваша итоговая таблица, прям просит это сделать.
Типизация - PHP, конечно, динамически типизированный, но статическую типизацию туда завозят очень давно. И, при некоторых условиях, она работает очень хорошо. Особенно в паре с линтерами.
Производительность - в PHP 8 завезли JIT. Внезапно. А у вас, простите, CPU-Bound задачи, чтобы указывать именно на производительность языка?
Масштабируемость - напилить микросервисов на Symfony конечно же нельзя, да? Не понимаю какое тут может быть архитектурное ограничение, кроме как в голове архитектора.
Поддержка многопоточности - тут не спорю, в PHP это либо форки, либо танцы с бубном. Пока движуха ограничилась файберами
Зрелость и стандарты - экосистема PHP - вполне зрелая. Набор PSR - это стандарты. Всё там нормально с этим.
Инстурменты и фреймворки - PHP-экосистема очень даже зрелая. А Symfony - по сути фреймворк Enterprise уровня. Может не стоило переходить в свое время на Laravel, а надо был смотреть в сторону более сложного фреймворка? Документация к Symfony отличная, да и по остальным важным инструментам - всё отлично.
Документация и best practices - ну я уже всё написал. На энтерпрайз решения - всё документировано. На поделки - ну тут как автор поделки захочет.
Безопасность - в PHP нет поддержки JWT? OAuth? Ну вы сейчас не серьезно же, да?
Обучение и комьнити - противопоставление странное. И там и там полно возможностей.
Экосистема и интеграции - покажите примеры, чего вам не хватало и пришлось писать руками? BigData? А что именно?
Сама таблица ограничений проекта на PHP :
Монолитная MVC‑архитектура - ну так распилите :)
Устаревший фронтенд (AngularJS, jQuery) - причем тут PHP?
SQL‑поиск по базе данных - причем тут PHP?
Обмен через FTP и файлы - причем тут PHP?
Отсутствие DAM‑системы - причем тут PHP?
Ручная фоновая обработка (CLI) - причем тут PHP?
Нет многопоточности и асинхронности - если с многопточностью я еще худо-бедно соглашусь, она не тривиальна, то асинхронность - ну вы просто не умеете ее готовить в PHP, так и скажите.
Динамическая типизация PHP - делайте статическую + линтеры
Зависимость от нестабильных библиотек - используйте стабильные, такие как Symfony, например, и ее компоненты.
Итог: вы просто хотели переехать на java. Хотели бы поддержать решение на PHP - поддержали бы и всё отлично могло работать. Ну или можно было критические части системы сделать на более производительных технологиях, оставляя те, что IO-Bound на более дешевых.
P.S. Хотя сам на PHP уже не пишу, но приведенные аргументы прямо просят им оппонировать.
Эк сразу. Начинать надо с машины Тьюринга :-)
Возможно стоило бы еще использовать DS\Map - это тоже может дать буст производительности. Особенно если сначала выделить всю нужную память.
Именно так я и делал. А потом копипастил url пакета в go get. И именно этот процесс хотелось ускорить. Мнемонические альясы оказались достаточно удобны. Касательно лезть в конфиг - помощь по команде выдает полный конфиг, по которому можно поискать. Пример:
gost mod --help | grep mongoВидимо весьма зря я статью начал с использования именно для старта нового проекта. Вобщем-то основная проблема была в другом. Вот мне посреди разработки проекта понадобился lru. Я помню, что у меня где-то используется его достойная реализация. Ок, поискав, я найду что это github.com/hashicorp/golang-lru
Но я совершенно не могу помнить как он пишется (или как пишется, например, github.com/valyala/fastjson). Мне нужен был инструмент - указал имя библиотеки -> она появилась в проекте (gost mod lru или go get github.com/hashicorp/golang-lru). Я сделал себе такой инструмент и, спустя время его использования, решил поделиться с сообществом.
А запуск на основе его проекта - это уже побочный эффект, оно ничего не стоило.