Комментарии 38
Редко что комментурю, но ваша итоговая таблица, прям просит это сделать.
Типизация - 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 уже не пишу, но приведенные аргументы прямо просят им оппонировать.
Спасибо за развернутый комментарий — многие ваши тезисы справедливы, но мы, пожалуй, немного по-разному смотрим на контекст.
Наша статья не про то, что «PHP плох», а про то, что в определенных классах задач Java объективно дает больше преимуществ — особенно когда речь о долгоживущих, масштабируемых системах с высокой нагрузкой и требованиями к надежности и поддерживаемости.
Типизация и масштабируемость кода
Да, PHP давно имеет строгую типизацию и линтеры, но язык изначально проектировался как динамический. Это сказывается на архитектуре и инструментах. В Java типовая строгость встроена в саму модель платформы — с полноценной системой generic-ов, строгими контрактами и compile-time проверками. Это не просто про синтаксис, а про возможность контролировать сложность в больших командах и кодовых базах на сотни тысяч строк.Производительность и предсказуемость исполнения
JIT в PHP 8 действительно улучшил ситуацию, но модель выполнения всё ещё однопоточная и request-based. Java-виртуальная машина (JVM) — это другой уровень: адаптивная оптимизация, профилирование, hot-swap, параллельная сборка мусора и стабильная работа под нагрузкой. Для сервисов, работающих 24/7 с постоянным state, это критично.Архитектура и многопоточность
Да, можно строить микросервисы и на PHP, но платформа Java предоставляет это «из коробки»: concurrency API, async I/O, thread pools, reactive-фреймворки. PHP-экосистема только приближается к этому уровню зрелости. Поэтому масштабирование вширь и вглубь (нагрузка, количество инстансов, межсервисные взаимодействия) в Java проще и надежнее.Экосистема и стандарты
PSR — это хорошо, но они не сопоставимы по охвату и глубине с Java EE / Jakarta EE, Spring-экосистемой или стандартами интеграции, безопасности и мониторинга JVM-мира. Для enterprise-интеграций Java-экосистема более полная и проверенная десятилетиями в банках, телекомах и госсекторе.Поддержка и развитие
На Java-проект можно безболезненно нанимать разработчиков из любой страны, с любым уровнем специализации. На PHP хорошие специалисты есть, но их меньше, и они чаще ориентированы на веб-сайты, а не на распределенные системы с бизнес-логикой и интеграцией с внешними сервисами.
Итог
PHP — отличное решение для классического веба, сайтов, CMS и легких API.
Java — инструмент для долгосрочных систем, где важны производительность, поддерживаемость и архитектурная предсказуемость.
Так что вопрос не в том, что «на PHP нельзя» — а в том, что на Java проще, надежнее и стратегически оправданнее для выбранного класса задач.
Думаю вы перешли потому что ваши потенциальные клиенты ("Java-экосистема более полная и проверенная десятилетиями в банках, телекомах и госсекторе") другое серьезно не воспринимают, а все остальное уже притянуто за уши.
Частично согласен — восприятие технологий клиентами действительно играет роль, особенно в крупных и консервативных отраслях. Но переход был не из-за имиджа Java, а из-за практических ограничений старого стека.
На определённом масштабе PHP-проекту стало сложно поддерживать нужный уровень асинхронности, фоновой обработки и интеграций. Java просто дала больше возможностей “из коробки” и стабильнее показала себя под нагрузкой.
Так что да, клиентам комфортно слышать “Java”, но решение было прежде всего инженерным, а не маркетинговым.
Расскажите что было с сотрудниками?
А вот об этом мы напишем в следующей статье!
А вот и рассказ что было с сотрудниками - https://habr.com/ru/companies/compo/articles/956106/
Ходят слухи, что на определённом масштабе можно взять язык Х и там нельзя будет поддерживать определённый уровень чего-либо (Y). Мы берём и переписываем этот код на что угодно, и вуаля, все проблемы решаются!
Можно взять PHP и переписать на Java, можно взять Go и переписать на PHP, можно взять Python... Ну вы поняли.
Смысл не в языке, а в том, что переписывают люди, уже столкнувшиеся с проблемой Y и изначально закладывающие обходные пути решения этой проблемы Y.
В том же самом PHP никто не мешает взять асинхронные коннекторы для работы с IO (amp/swoole/etc), а файберы из коробки уже дадут 100500 очков к удобству, когда для асинка не надо красить функции, как в каком-нибудь JS. А в Java... Как там, кстати, Project Loom поживает? Ну вот то-то и оно ;) Но это абсолютно не значит, что где-то не возникнет проблем на которые изначально никто не рассчитывал (не было опыта).
Да вроде нормально все с Loom. Не весь пока включен, но виртуальные потоки вошли в JDK 21 и вполне живут в проде
Получается я отстал от жизни. Его, если не путаю, пытались лет 5 как втащить и всё никак. Очень круто, раз наконец дошли руки
да, долго его готовили. постоянно откладывали выпуск. но затащили часть в итоге.
Там было достаточно много причин, почему "никак". Али-Баба, идейные вдохновители, у себя в продакшене запустили очень много лет назад и в ус не дули. Но их подход добавлял оверхед для других сценариев. Всё это время шла работа над устранением краевых случаев, и уже несколько лет как всё готово к использованию с разными оговорками. Сейчас уже скорее без оговорок.
Поясните, пожалуйста, во-первых, что не так с Loom, и, дополнительно, если можно, что у вас за проект, что вам действительно нужны корутины и не хватает обычных потоков? Тем более, при этом почему-то хватает 1:N реализации кооперативной многозадачности.
если вопрос к compo. то мы на 17 java пока. у нас нет виртуальных потоков. обычных нам хватает. ну и тут в целом речь о том, что у java из коробки куча инструментов и абстракций для работы в многопоточной среде. в PHP надо добавлять расширения на c++. типа скачиваешь, в конфиг добавляешь расширение и там все оно дальше работает такое.
Какая версия пхп у вас была? В 2025 году как-то уже не комильфо говорить про слабую типизацию. Она конечно до java не дотягивает, но не драматично.
Что случилось с разработчиками пхп?
Микросервисы на java? Почему не go? Что-то подсказывает мне, что это было бы быстро и не так дорого как java. Потому что сейчас есть некоторое количество разработчиков пхп, которые так же могут и в Golang. Либо быстро переучиться. У нас в компании и так и сяк например.
Во, нормальные вопросы по делу.
1. Мы закончили работать на 7ке, на 8ку были некоторые надежды и проводились эксперименты но жава выиграла в этом.
2. Это как раз материал для отдельной статьи - скоро выпустим. Вкратце - довольно тяжело, но успешно. Кто хотел - того мы переучили с помощью курсов, тренингов и т.д. Ну почти вся команда мигрировала собственно. В дурку никто не уехал )
3. Go — норм вариант, и мы его рассматривали. Он действительно быстрее стартует, проще по синтаксису и хорошо подходит для микросервисов с высоким уровнем параллельности.
Но у нас проект не только про микросервисы, а про большую экосистему: интеграции, очереди, транзакции, сложную бизнес-логику и долгоживущие процессы.
Здесь Java даёт больше зрелых инструментов “из коробки” — Spring Boot, Spring Cloud, Spring-batch, Spring-whatever ), средства тестирования, мониторинга и оркестрации.
Go в этих областях требует больше ручной сборки и собственных решений, а мы как раз шли в сторону унификации и стандартизации.
Типизация и масштабируемость кода
В PHP из коробки более мощная система типов. В PHP null - это null, а не псевдо-object. Никаких ошибок NPE в принципе нет и использовать NULL не только можно, но и нужно. В PHP есть алгебраические типы данных, есть юнионы и интерсекшены. И это всё из коробки.
А прикручивая линтер получаешь и дженерики, и коваринтантные/инвариантные и прочие параметры и даже call-site variance для дженериков (чего даже в котлине нет).
Плюс, не стоит забывать о таких типах в PHP как int<0, 42> или non-empty-string, когда даже в Scala подобное что-то не припомню что возможно.
Производительность и предсказуемость исполнения
А что мешает взять свул и использовать и многопоток, и воркеры и вот это вот всё?
Да что угодно можно конечно сделать. Взять это, это и вот это и дело в шляпе) Но так не работает в долгосрочном плане, мы убедились в этом.
PHP серьёзно прокачался — типы, юнионы, интерсекшены, даже алгебраические конструкции через стат-анализаторы. Но важно понимать: это всё надстройки, а не часть самого языка и рантайма. В Java строгая типизация встроена изначально, и на ней держится весь экосистемный фундамент.
То же и со Swoole — мощная штука, но отдельный движок со своей инфраструктурой и зависимостями. В enterprise-реальности это значит: поддержка, обновления, CI/CD, совместимость — всё на вашей совести.
Ну и например коллекции — отдельная история: хочешь нормальные типизированные структуры данных — ставь стороннюю библиотеку, следи за обновлениями и совместимостью.
В Java это всё идёт из коробки и живёт десятилетиями без боли.
Товарищи просто свой непрофессионализм свалили на пхп) есть отличные решения типа porto+apiato+swoole. Да и без Porto + Apiato многое можно было решить "руками" Если включить голову. Ну и Ларавель они не знали естественно, иначе не писали бы про крон и проблемы с бэкграунд задачами, для многих они ушли в 2013-м. В целом я сижу на архитектуре PHP с 2020 года которая решает 90 процентов указанных проблем и просто превосходно масштабируема, имеет атомарный слабо связанный код и прекрасную 100 процентную надёжную возможность покрытия тестами, плюсом - низкий порог входа для джунов в проект и высокую базовую безопасность. DDD в PHP была ограничено популярно еще в 2012-м, А классический MVC в Java spring я встречал в проектах и намного позже и сейчас уверен многие кодят через классический MVC.
Но в целом автор затронул действительно важную и интересную тему, до сих пор многие компании не понимают что такое "архитектура" И лепят как "на душу положат" А потом вырастают монстры
Поддержка многопоточности - тут не спорю, в PHP это либо форки, либо танцы с бубном.
new Swoole\Thread();
;)
Не спорю. И pthreads есть еще и много всего. Но ZTS и еще одно расширение. Но - главным образом - ZTS. Это я и назвал "танцы с бубном" :) Может быть я и не прав.
Согласен. ZTS - в принципе набор костылей, по-моему. Например она начинает эмулировать getenv/putenv, используя локальный массивчик, вместо реальных энв переменных, что аффектит энвы во внешних dll/so либах. Ну и т.д.
Так что да, ZTS сборка - вполне себе "танцы с бубном", это да.
И pthreads есть еще и много всего.
Pthreads вроде как мёртвое нынче, не? В районе 7ки умерло, поэтому про свул и написал.
На определённом этапе PHP-стек (пусть и с современными фреймворками) перестал закрывать наши требования по масштабируемости, фоновой обработке и долгоживущим процессам. Swoole, Porto и подобные решения действительно многое умеют, но требуют отдельной инфраструктуры и компетенций, тогда как в Java эти механизмы доступны “из коробки”. Да, можно конечно было зарефакторить старую платформу, улучшить архитектуру, но новый стек дал нам гораздо больше преимуществ.
В поисках идеального стека для интерпрайза <в нашем конкретном случае>.
;)
Идеального стека не существует конечно — просто в нашем случае “идеальный” оказался подозрительно похож на тот, на котором половина enterprise-планеты (если не больше), уже лет двадцать работает (если не больше) )))
В курсе).
Могу только добавить, что пожалуй, самые главные «виновные» (можно и без кавычек) по проблемам поиска идеального стека — это пожалуй бизнес и маркетинг (со своими дедлайнами и хотелками), а потом уже все остальные)
Добавлю "5 копеек". Вот совсем недавно обсуждал с товарищем поиск баланса между исследовательской и коммерческой деятельностью! Бывают ситуации, когда нужно чувствовать на что сделать больший упор в решении задачи или создании продукта. Самое обидное, когда заложено время на некий ресёрч в проекте, но приходит бизнес и начинает всё сдвигать в угоду заказчиков!
Как бывший пыхер, создалось впечатление что статья про PHP 7 без Композера. На 7ке делалось много магазинов с ElasticSearch и хранилищем файлов с GridFS. API и SSR средствами кодогенерации фреймворка делается раза в два быстрее за счёт отсутствия перекомпиляции. Да, многопоточность, общая память и расписания это вещь. Но за нее придется платить циклами GC и занимательным дебагом утечек памяти на проде.
Итого? По срокам, по балансу: старое, новое? Получается что в мире цифровизации, трансформации кроме Java нет альтернативы? Всё на Котлин, всё под Оракл и гугл? А если брать легаси типа кобола, где в банках софт с триллионными $ оборотами? Упор на ресурсоемкий кросплатформенный Java, вскоре в следствии ИИ, тоже окажется недостаточно масштабируем. Многие автоматизаторы говорят что переход на Java увеличивает дистрибутивы и кодовые реализации на несколько порядков. Если конечно бюджеты при переходе на Java на порядок возростают наверное стоит, главное итог что с вами будет скажем лет через 5-10.
Мы как раз не считаем, что “кроме Java нет альтернатив”. Просто на нашем этапе Java оказалась компромиссом между зрелостью, инструментарием и предсказуемостью развития.
Да, экосистема тяжеловесная, но в обмен получаешь стабильность, совместимость и массу готовых решений для enterprise-масштаба.
Kotlin, Go, Rust, .NET — все достойные варианты, и если бы мы стартовали проект с нуля сегодня, возможно, смотрели бы шире.
А что будет через 5–10 лет — покажет практика. Скорее всего, Java не исчезнет, а просто станет ещё одной “основой под капотом” множества технологий, как сейчас JVM используется в большом количестве инструментов.
Так что переход для нас — не культ Java, а шаг к более устойчивой и управляемой архитектуре.
Для тех кто ещё выбирает куда с PHP слезать. Есть компании, которые с микросервисами прыгнули в Go ибо целевая система это всегда контейнер, и ява машина просто трата ресурсов.
Знаю, видел это своими глазами. Go — классный выбор. Для лёгких микросервисов и быстрых контейнеров — вообще топ. Мы посчитали Go недостаточно подходящим под наши задачи. Но кстати, миф о «тяжёлой Java» уже давно неактуален: современные JDK и фреймворки отлично дружат с контейнерами. На Go кстати хайп несколько спал, насколько я вижу, по сравнению с прошлыми годами.
В поисках идеального стека для Enterprise проектов: почему Java плюс MACH