<![CDATA[Комментарии / Профиль hack3p]]> https://habr.com/ru/users/hack3p/comments/ ru editor@habr.com habr.com Sat, 02 May 2026 01:01:43 GMT https://habr.com/ru/ https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png Хабр 12.04.2023 08:42:15 https://habr.com/ru/articles/665766/#comment_25436232 https://habr.com/ru/articles/665766/#comment_25436232 Здравствуйте,
Подскажите, как по-итогу ощущается после года эксплуатации? Есть какие-то существенные проблемы/минусы/неудобства в пользовании и в администрировании?

]]> Wed, 12 Apr 2023 08:42:15 GMT 27.09.2021 20:12:57 https://habr.com/ru/companies/otus/articles/580264/#comment_23527700 https://habr.com/ru/companies/otus/articles/580264/#comment_23527700 Если вы уперлись в ресурсы при использовании FPM, и при этом у вас требования как у высоконагруженного приложения с возможностью асинхронной обработки огромного кол-ва запросов и асинхронной передачи их в дальнейшие сервисы.. То почему просто не сменить инструмент на "нормальный" (в рамках необходимых требований), например тот же GO?

Считаю, что переучивать разработчиков которые годами росли в контексте "PHP рождён, чтобы умереть" с синхронным исполнением кода, на асинхронщину на том же PHP - это дорога в никуда. На рынке очень мало востребованных позиций с асинхронным PHP, и на рынке будет очень сложно найти квалифированного PHP разработчика имеющего опыта %костыль% и умеющего в асинхронщину (удачи).

А вот если говорим про тот же Go (или другой подобный инструмент), то тут сразу понятно, что такой разработчик умеет в асинхронщину, во всякие mutex, потоки, и прочее.. И в таком случае, эффективность решения будет в разы выше, чем костыли (swoole, gorunner и прочее) на PHP. Потому-что на "нормальном" инструменте (опять-таки Go), сможете намного лучше утилизировать доступные ресурсы.

Поэтому, если так сложилось, что в компании только PHP разработчики.., считаю перспективным решением найти пару разработчиков на "нормальном" инструменте в компанию, и вокруг них уже организовать процессы обучения php разработчиков в "нормальный" инструмент.

Лучше немного побуксовать на старте (смена стека), чем потом докупать пачками сервера под PHP, и каждого нового PHP разработчика обучать мертворождённым костылям.

]]> Mon, 27 Sep 2021 20:12:57 GMT 06.07.2021 08:05:22 https://habr.com/ru/articles/521594/#comment_23230096 https://habr.com/ru/articles/521594/#comment_23230096 Проще уж выбрать PHP, всё тоже самое, только нет проблем с нагрузкой и есть рынок кандидатов

]]> Tue, 06 Jul 2021 08:05:22 GMT 15.06.2020 11:56:18 https://habr.com/ru/companies/skyeng/articles/506704/#comment_21739556 https://habr.com/ru/companies/skyeng/articles/506704/#comment_21739556 Ответ на вопрос?)


Зачем писать на PHP в 2020?
]]> Mon, 15 Jun 2020 11:56:18 GMT 18.01.2018 10:47:30 https://habr.com/ru/articles/346914/#comment_10622956 https://habr.com/ru/articles/346914/#comment_10622956 Если PHP претендует на OOP с SOLID, тогда почему они немогут реализовать нормальное ковариантное наследование как в других языках. Вместо этого зачем-то делают костыли в виде нарушения принципа Лисков. Можно еще ознакомится с этим PR и отношением PHP сообщеситва к таким изменениям.

]]> Thu, 18 Jan 2018 10:47:30 GMT 15.12.2017 08:33:39 https://habr.com/ru/articles/344728/#comment_10568402 https://habr.com/ru/articles/344728/#comment_10568402 Используйте ORM для CRUD. А для всего остального QueryBuilder.

]]> Fri, 15 Dec 2017 08:33:39 GMT 07.10.2016 13:58:46 https://habr.com/ru/articles/312022/#comment_9847224 https://habr.com/ru/articles/312022/#comment_9847224 Fri, 07 Oct 2016 13:58:46 GMT 01.03.2016 10:03:37 https://habr.com/ru/companies/postgrespro/articles/278019/#comment_8788071 https://habr.com/ru/companies/postgrespro/articles/278019/#comment_8788071 Объясняя необъяснимое, Объясняя необъяснимое. Часть 2
]]> Tue, 01 Mar 2016 10:03:37 GMT