Comments 65
В защиту PHP скажу, что он стал более выразительным для развитой бизнес логики чем Go
Бегство PHP программистов на Go за монетой плохо закончится для них. Бегство без смены компетенции. С учётом, что гоферов берут на работы, где нужен быстрый вход.
Ну вот ты представь себе типичного пхп программиста с опытом 5+ лет, но без опыта на c++, Java, c# и ушедшего на Go. Кем он станет и сможет ли удержаться когда потребность в инфраструктуре сократится с взрывного роста до нормального?
Что он уносит с собой из PHP: скриптовое мышление, процедурный стиль со структурами вместо модели, привычку к "запрос-ответ-умер", слабое представление о памяти, конкурентности, стоимости аллокаций. Go это не лечит, а легализует: язык сам по себе процедурный с минимумом абстракций, поэтому такой человек пишет на Go как на PHP, только без исключений и с go func(){} в случайных местах. И код проходит ревью, потому что идиоматичный Go от плохого Go отличить труднее, чем идиоматичный C# от плохого C#. Компилятор не мешает, ошибки возвращаются, всё "просто".
Пик (судя по tiobe, он уже прошёл) спроса на Go совпал с миграцией всего подряд в k8s и микросервисы. Когда этот цикл закрывается, остаются две категории работы: эксплуатация написанного и новая разработка в узких местах (сети, observability, embedded-сервисы). Туда берут людей, которые понимают планировщик, профилирование, backpressure, сетевой стек. Наш гипотетический перебежчик этим не владеет (если не было опыта с более энтерпрайными языками) , он владеет "написать handler и задеплоить через готовый чарт". В нормальном (не взрывном) рынке он конкурирует с системщиками и проигрывает.
Хотя, лично я предпочитаю C#, Rust
низкий порог входа в нишу означает быстрое обесценивание опыта в ней, и это касается любого языка с таким профилем
Доводы у вас отличные, я согласен.
C другой стороны, кто сказал что нельзя использовать go с дешевой ассинхронщиной как замену php, разве что отсутствие полноценного фреймворка, но как будто он и не нужен, например есть ogen и его достаточно если писать API+SPA
Зато мы получаем строгую типизацию, компиляцию, огромное количество линтеров (они позволяют писать код который легко сможет прочитать любой гофер), дешевую и простую ассинхронщину
Если слегка подпрыгнуть, то типизация есть и в пхп, а дженерики в пхп даже лучше, выразительней чем в го ;)
Только дженерики придётся через PHPDocs лепить и Psalm / PHPStan или хотя бы на сообщения IDE посматривать
<?php
final class User
{
public function __construct(
public readonly int $id,
public readonly string $name,
) {}
}
final class Order
{
public function __construct(
public readonly int $id,
public readonly float $total,
) {}
}
interface EntityRepository
{
/**
* @template T of object
* @param class-string<T> $class
* @return T|null
*/
public function find(string $class, int $id): ?object;
/**
* @template T of object
* @param class-string<T> $class
* @return list<T>
*/
public function findAll(string $class): array;
}
final class InMemoryRepository implements EntityRepository
{
public function find(string $class, int $id): ?object
{
return match ($class) {
User::class => new User($id, 'Ivan'),
Order::class => new Order($id, 99.50),
default => null,
};
}
public function findAll(string $class): array
{
return match ($class) {
User::class => [new User(1, 'Ivan'), new User(2, 'Petr')],
Order::class => [new Order(1, 99.50)],
default => [],
};
}
}
$repo = new InMemoryRepository();
$user = $repo->find(User::class, 1);
// Psalm выводит тип: User|null
if ($user !== null) {
echo $user->name; // анализатор знает, что свойство name существует
}
$orders = $repo->findAll(Order::class);
// Psalm выводит тип: list<Order>
foreach ($orders as $order) {
echo $order->total; // type-safe для анализатора
}
Такое в го невыразимо
PHP подтянулся в выразительности, но ценой переноса гарантий из языка в тулинг и дисциплину.
PHP подтянулся в выразительности, но ценой переноса гарантий из языка в тулинг и дисциплину.
Язык-то не изменился, он о дженериках и тем более о типах ничего не знает - в рантайме матчатся строки.
Было голосование
https://wiki.php.net/rfc/bound_erased_generic_types
тут тип выглядит настоящим, но не проверяется. Gina Banyard прямо пишет, что большинство разработчиков, увидев Collection<User> в сигнатуре, ожидают рантайм-проверку, и узнав, что её нет, реагируют с недоумением
Предлагают полноценные вместо стёртых в пхп 9 через год
https://daily.dev/posts/vote-rfc-bound-erased-generic-types-19ahl5hl7
Но пока можно и через тулинг
Опять же, это будет лучше сравнивая с стёртыми типами TS, которых уже нет в рантайме
Array<User> в рантайме TS это просто массив, положить туда Order вместо User можно через любую щель (any, as, внешний JSON), и движок не пикнет.
большинство разработчиков, увидев Collection в сигнатуре, ожидают рантайм-проверку, и узнав, что её нет, реагируют с недоумением
PHP осознанно выбирает консервативный путь неинвазивного навешивания тулинга, не обещая никаких гарантий на уровне языка. Обходится без трансляции, цена тому - DX, неуклюжий синтаксис, логика типов в комментариях.
TS, тем временем, отвязан от целевой платформы компилятором и может добавлять синтаксические конструкции по вкусу.
any, as, внешний JSON
Для этого программисту придется осознанно прицелиться в ногу и спустить курок.
движок не пикнет.
JS-движок обвалится уже на этапе попытки запустить “сырой” TS код с типами. А PHP комменты игнорирует и с радостью пойдет куролесить.
ну если это вы называете выразительно, то тогда лучше действительно оставаться в php и никуда больше не смотреть.
Каждый инструмент хорош под свои задачи. На пыхе быстрее накидать сложный функционал для заказчика, на Go - упаковать это в легкий сервис и отдавать миллион rps
в чем то вы правы, но php уже давно не торт и по запутанности и возможности налепить костылей он уже давно где-то на уровне Java
Go по крайней мере бьет по рукам за слишком уж широкую самодеятельность, а для всего остального есть кодестайлинг и прочие правила в проекте
щарп и раст как раз плохи своей "широтой". на долгой поддержке чем проще тем лучше, собсвенно на этом php изначально и держался
Java сложна не языком, а экосистемой: Spring, Hibernate, XML-конфиги, аннотационная магия, пул потоков, GC-тюнинг. PHP 8.x с readonly, enums, named args и атрибутами проще по конструкции. Запутанность PHP-кода обычно от легаси без типов, не от самого языка.
Не понял за что там бьёт Go. Наличие компилятора ещё не признак ума© Это только у Rust есть поговорка "если компилируется, значит работает правильно". У Go такой поговорки нет. Вам рассказать, почему так?
Так что статическая компиляция в Go это скорее про скорость, а не про гарантии.
Можно писать простой C# без событий, без reflection, без LINQ-чудес. Но когда домен требует discriminated union, pattern matching, immutable record, readonly struct, то инструменты для них там есть. В Go их нет, и вы вынуждены изобретать велосипеды или писать лапшу. "Широта" плоха только если вы ее используете без нужды. Это лечится упрощённым кодстайлом в конкретной группе, проекте. Отсутствие широты плохо, когда нужда есть.
упрошенный кодестайлинг чего-то стоит
прибитая гвоздями широта позволяет контролировать руками, когда как простота языка имеет множество подводных, в том числе и не очевидных
с Го ты не ставишь турбину от самолета когда тебе нужен только удобный интерфейс к вентилятору. Даже если в проект затягивается гигантский "швейцарский нож" (пакеты которых как раз насоздавали "мигранты" с php и прочих "удобных" языков) то все равно точка соприкосновения только там где используется и это все можно отследить, посмотреть по коду и отттраисировать без танцев с бубном
Вон не так давно в Го дженерики добавили как раз из-за подобных воплей про "удобство". В итоге вместо использования явного генератора и контроля над сгенерированым кодом появилась точка отказа, так как "проще" использовать any а потом ловить проблемы на этом поприще или просадку латенси и-за гиганского if-else дерева для "безопасного" обслуживания этого дженерика
А за Раст посмеялся) Завтра еще коллегам на созвоне расскажу, вместе посмеемся)
Сколько же я по работе видел откровенного Г на расте не передать. Язык не спасет если пользователь идиот и/или не понимает что и как делать. Зато вместе с Растои идет эльфийский синтаксис который просто больно читать, зависимость от dll и прочего (из-за чего кроссплатформа для чего-то реально боевого, а не просто сайтики становится веселым квестом) а так же мое любимое это ручной контроль над памятью (80% кривизны как раз в этом, просто тому что среднестатический "вкатун" в Раст вообще понятия не имеет что это за зверь такой ваша память и в чем проблема что все ОК работает только на его последнем маке)
Сколько картинок мемных не вставляя. а к PHP-шникам сейчас отношение рынка - их дохера и они дешевые и всегда можно уволить. Да и дальше админки на yii/laravel редко что-то уходит. Удачи.
Вангую, что PHP жив потому, что живы люди, которые его используют. То есть PHPшники выйдут на пенсию, и на этом языку всё. Но до этого момента он так и будет активно развиваться. Не вижу вообще ни одной причины начинать что-то новое на PHP.
Не вижу вообще ни одной причины начинать что-то новое на PHP.
А на чëм видите?
Go + templ + htmx
Благодаря горутинам новые сессии дают ничтожное потребление RAM.
Htmx даёт крутой опыт SPA приложения.
Templ даёт дикую скорость генерации страницы.
Реальная многопоточность и космическая скорость (доска объявлений с 4 запросами в бд отдает HTML за 5мс).
Можно даже приложение для винды через wails сделать.
Кто-то развивается, а кто-то защищает PHP, так как "на его век ещё хватит". Да и лень мозг напрягать на что-то новое. Проще мемасов накидать.
Развивается - использует удобные инструменты в нужную ситуацию, чтобы сделать продукт, а не тыкает всем газонокосилкой, что он может косить траву
Изобрели серверный рендеринг заново и радуются. Поздравляю, вы открыли для себя PHP образца 2005 года, только с компиляцией в бинарник и модным баззвордом htmx
так куча ж CMS, просто сайтов, да и фреймворков на пыхе. Куда он денется
Заводишь сайт, в панели управления (ISP)- база пых. Но можно еще питон
программисты на Cobol грустно улыбнулись.
Не вижу вообще ни одной причины начинать что-то новое на PHP.
Не соглашусь. Стоит отдать должное, но PHP лучшее решение для CRUD панелей и админок.
Сам гофер, когда-то давно свичнулся с php, но все еще тепло вспоминаю его.
Я вообще ничего не понимаю в PHP, но я радостью прочел статью и теперь что то знаю! Котики и другие мемы сработали :D
Пожалуй самый главный миф - "PHP медленный". Но если глянуть бенчмарки, из "большой тройки" скриптовых языков для веба (PHP, Python, Ruby) именно PHP является самым быстрым. Благодаря оптимизациям движка Zend и JIT‑компилятору в PHP 8, в сырых вычислениях и пропускной способности HTTP‑запросов PHP стабильно обгоняет стандартный CPython и Ruby.
Уважаемый@MountainGoat, причин накидать прототип чего‑то нового на PHP и сегодня достаточно. А некоторые такие "прототипы" потом вырастают в весьма значимые проекты: Nextcloud, Tumblr, Badoo, BlaBlaCar, видеохостинг Dailymotion, Trivago.. И да, при росте масштаба вокруг PHP вполне могут появляться Java, Go, Node.js, Kafka, Elasticsearch и так далее - но это уже вопрос архитектуры.
По поводу CMS. В нынешнее время особенно ЕС массово использует в своих правительственных и институциональных порталах Drupal. И, что интересно, это уже далеко не просто "старая CMS", а одна из самых активно развивающихся платформ. По данным из доклада на Пых.конф’25, за предыдущий год у Drupal было около 124 000 коммитов в ядро, 6 400 открытых PR и около 1 млн активных контрибьюторов, участвующих в ядре и связанных проектах.
А ещё Drupal довольно интересно подошёл к AI. Причём речь не просто про "давайте прикрутим chatGPT" или очередной вайб‑кодинг. AI глубоко интегрируется в саму модель Drupal: агенты работают с контентом и конфигурацией, конфигурации представлены в YAML и могут проходить обычный Git/CI/CD workflow, а права агента можно ограничивать на уровне ролей и permission'ов самого Drupal. То есть AI может генерировать и изменять конфигурацию, но результат остаётся контролируемым, проходит ревью и деплоится обычным способом.
В Drupal CMS 2.0, вышедшем в январе 2026 года, AI уже встроен в саму платформу, а не существует просто в виде внешнего чат‑бота.
И есть совсем интересные проекты вроде Boson - runtime/toolkit, который позволяет писать кроссплатформенные desktop‑приложения на PHP с привычным HTML/CSS/JS, но без Electron и Node.js. PHP runtime, код приложения и необходимые компоненты собираются в единый исполняемый файл, который можно распространять без отдельной установки PHP. Есть интеграции с Symfony и Laravel.
Интересный факт) А вы знали, что основа "той самой" Pornhub - это проверенная временем связка: Nginx, PHP, MySQL, Memcached и Redis? Вот интервью (от 2019 года) с разработчиком. Позже по мере роста нагрузки к этому стеку добавили ElasticSearch, Node.js, Go и Vertica.
И это далеко не застой: PHP продолжает развиваться - улучшается производительность, типизация, обсуждаются generics, data classes, async и новые возможности рантайма. Так что хоронить его, похоже, ещё рановато.
PHP продолжает развиваться
Это сильно зависит от того, что считать развитием. Мы начинали в 90-тых с ассемблера, потом паскаль, с, с++, ява. Потом подзанесло на пхп и на нем очень надолго застряли, т.к. веб, а потом старые проекты, легаси, сарафанное радио, в общем с этой иглы уже не слезть было. А игла была прикольная, т.к. то за что вечно ругали пхп - типа отсутствия строгих правил и типизации и прочего - позволяло писать лаконичнее там, где на альтернативных языках нужна была простыня.
И таки вот что мы имеем сказать. Пхп3 был первой версией которую можно было серьезно использовать. Пхп4 расширил язык до очень многих нужных вещей не потеряв идеологии. Пхп5 стала версией в которой исправили много недостатков и добавили много важных вещей не изменяя сути и...
.... тут язык стал сильно популярен и в него пришли профи "из взрослых языков", чьи языки для задач что решал пхп не очень подходили, но это не мешало профи критиковать пхп за то, что он "не их взрослый язык" (по типу прийти в чужой монастырь и удивляться недостатку в видео отсутствия телека с порноканалами).
Вследствие чего 7-ка и 8-ка хотя и имеют ряд интересных и полезных нововведений, но в большей степени это уже не развитие пхп, а дрифт в сторону в попытке сделать из него нечто типа явы в упрощенном и убогом варианте.
Изменилась сама идеология и как следствие и сам пхп как таковой смысл теряет, т.к. а на фига писать на "упрощенной яве", если есть нормальная?
Так что таки да, формально пхп еще существует и существовать еще видимо какое-то время будет, но сейчас он действительно шагает к смерти через ассимиляцию, ибо переняв чужую культуру - он потерял свою.
Для Java пойди найди программиста за разумные деньги. Плюсом память жрёт. С точки зрения бизнеса PHP выгоднее. Всегда найдёт человека на поддержку за адекватную з/п.
Нуууу, спорно.
С точки зрения бизнеса вход в пхп действительно ниже, но прогера на серьезный проект на пхп найти сложнее чем прогера на серьезный проект на яве, т.к. как только речь идет о серьезности - все мигрируют с пхп. Поэтому тут надо разделять аудитории.
Что касается пожирания памяти, то это опять же ситуационный вопрос. Базовый инстанс пхп запустить дешевле, но если речь об обработке больших данных нативно (без хаков, трюков, ручной работы и специальных либ), то у пхп такой большой оверхед, что как только заходит речь о big data то ява явно смотрится выгоднее по памяти чисто из-за меньшего оверхеда на хранение.
То есть ситуация опять же сводится к тому, что если речь про простой проект (что было изначальной фишкой пхп) то пхп все еще бьет и яву и всякие питоны - потому что у него все еще есть в активе изначальное наследие, но в серьезных проектах он все же сливает (несмотря на все попытки дрифтовать в сторону явы), что по цене исполнителя, что по цене железа.
Без движения в сторону строгости PHP просто вымер бы под натиском TypeScript и других языков. Команды выросли, проекты стали огромными, и без строгих контрактов поддерживать код стало невозможно
Это как говорить, что матиз умер бы, если бы таксопарки начавшие с него перешли бы на мерседес, вместо попытки модифицировать матиз.
Но по факту и таксопарки проигрывают (т.к. до Е-шки не дотягивают) и матиз потерял идентичность (т.к. стал дороже и сложнее).
По нашему кругу - большинство мигрирует с пхп именно потому, что он стал избыточно переусложненным и зарегулированным, при чем мигрируют как раз на менее строгие языки.
Вследствие чего 7-ка и 8-ка хотя и имеют ряд интересных и полезных нововведений, но в большей степени это уже не развитие пхп, а дрифт в сторону в попытке сделать из него нечто типа явы в упрощенном и убогом варианте.
Ровно тоже самое думаю и я. Они реально хотят сделать интерпретируемую яву, при этом сохраняя обратную совместимость! Зачем это все? Не проще тогда взять Java с её зоопарком JIT?
Главная сильная черта PHP - можно взять коробочное решение и за пять минут развернуть на хостинге (даже не VDS). Форум (еще помните что это?), сайт, интернет магазин, админка с backend api... Как платные так и opensource. На любой вкус и цвет.
Нет решения? Берем yii3, симфони, ларавел - один день и готово. Дальше напильником.
дрифт в сторону в попытке сделать из него нечто типа явы в упрощенном и убогом варианте
В нормальном варианте, но die fast
PHP взял из Java статическую проверяемость и модель данных, но не взял её главную цену: долгоживущее состояние, пул потоков с разделяемой памятью. Модель "запрос-ответ-умер" осталась, и это не пережиток, а архитектурное свойство: нет утечек состояния между запросами, любой запрос поднимается в чистой среде, падение одного не роняет соседей, деплой это замена файлов, а не перезапуск JVM с прогревом.
не взял её главную цену: долгоживущее состояние, пул потоков с разделяемой памятью.
Это зависит от реализации, тот же PHP-FPM работает на пуле процессов и после запроса воркеры у него не обязаны умирать, так что утечки всё еще возможны.
Но нет, быстрый in-process кэш за это не получишь - будь добр какой-нибудь редис рядом затащить там, где Java обойдется ConcurrentHashMap.
любой запрос поднимается в чистой среде, падение одного не роняет соседей
Падение отдельных потоков не роняет соседей и хостовой процесс.
деплой это замена файлов, а не перезапуск JVM с прогревом.
Зато получили неочевидную проблему разъезда старого опкеша и новых файлов при деплое копированием.
В простых проектах - да.
Но хоть сколько-нибудь в сложных проектах начинается вопрос о постоянных соединениях в БД, об опкеше, о запуске пхп-фпм, о постоянном процессе пхп для обработки текущих данных в очереди и в результате "дай фаст" идеология вырождается в скрипты, которые лишь обрабатывают входящий запрос от пользователя, с которым потом разбирается большой жирный бакэнд. И самое смешное, что даже мы, фанаты пхп с 20+ летним стажем, этот бакэнд предпочитаем обрабатывать на чем-то отличном от пхп. И не потому что пхп был изначально плох для этого, а потому что текущий пхп превратился в урезанную версию более навороченных языков.
Последний наш проект это пхп на фрондэнде и банальный c# на бакэнде. Где роль пхп сводится к CRUD, а сложная обработка данных вся делается на C#.. Лет 10 назад нам бы такое и в голову не пришло. А сейчас это реализуется прямо таки сходу, т.к. банально php на бэке для нас ощущается как язык такой же сложный и ограниченный как C#, но при этом без функционала, либо и возможностей последнего.
т.к. а на фига писать на "упрощенной яве", если есть нормальная?
Хотя бы потому, что нормальная ява не живет на виртуальном копеечном хостинге.
Сейчас полноценный VPS можно до ста рублей взять, а по цене чашки кофе уже предложат 4 Гб RAM. Туда небольшой проектик в докере влезет, не то, что джава. Копеечнее только бесплатно.
Не согласимся.
Если у Вас посещаемый проект на пхп, то вирт. копеечный хостинг это в любом случае не для Вас. А если Вы купили хостинг подходящий для посещаемого проекта на пхп, то и ява там отлично заведется и будет чувствовать себя неплохо.
PHP продолжает развиваться
типизация, обсуждаются generics, data classes, async
Язык догоняет мейнстрим с добрым лагом в 10-20 лет по фичам, при том не предлагает ничего нового и уникального.
"PHP медленный"
Где то видел, что PHP в 10 раз быстрее Python.
ну, питон сам по себе достаточно медленный
Пхп начиная с 7-ки реально очень быстрый.
Пожалуй самый быстрый среди интерпретируемых, а за счет по сути реалтайм компиляции - вполне конкурент и компилируемым языкам.
Единственное что ему портит эту скорость, это манера некоторых либ и цмс встраивать исполняемые куски кода на ходу, компиляцию которых эакэшировать невозможно. Но это встречается все реже и реже.
У PHP столько врождённых пороков, что убрав их получим совершенно другой язык. Дело не в скорости php или в развитии php, это был хороший язык для своей эпохи, а уже несколько лет как всё закончилось.
PHP хорошо применять там, где нужно данные записать в базу и считать из базы и это всё. Если нужны вычисления - а в php строгая динамическая типизация - мучаемся с отладкой, если нужны машинное обучение или нейронки - вообще сложно, неразвитые фреймворки и библиотеки.
То что там есть cms - на них язык и выехал. Плюс поддержка на любом хостинге, самые дешёвые цены, простота установки, готовое окружение - только это уже не имеет того значения, поскольку все подошли к ИИ.
В php типизация не строгая.
У PHP столько врождённых пороков, что убрав их получим совершенно другой язык
Вооот, типичная точка зрения яваиста, которая и привела текущий пхп к его проблемам.
То что многие называют пороками пхп - является его плюсами и особенностями, попытка в 7 и 8 версии от них избавится - убивает сейчас сам пхп делая из него жалкое подобие явы. Это как взять хаски, посадить его в квартиру и заявить что большое количество его энергии это недостаток:)
То что там есть cms - на них язык и выехал.
Вот только тут другая причина следствие. Именно благодаря особенностям пхп (которые Вы называете пороками) и стало возможно большое количество (в т.ч. качественных) цмс на нем. ЦМС на яве не не появлялись не потому что "так сложились звезды", а потому что ява был язык не особо для этого годный.
Язык пхп выехал не за счет цмс, цмс появились за счет особенностей пхп.
Основная причина жизни пыха Лара и вордпресс, пока они не сдохнут, трухлявый слоник будет жить. headless cms и nodejs могли бы заменить, но везде принцип "Не трогай, если работает"
1) Что мешает делать headless cms на php? Read only классы удобны для DTO, сериализуй в Json и отдавай их в асинхронный JS.
2) Медианная посещаемость среднестатистического сайта(не запаркованный домен) - ~10 хитов в час. Не в секунду. На такой нагрузке не будет никакой разницы между веб-ресурсом, работающем на Go и на PHP c OPcache и Redis. Совсем никакой с учетом сети(десятки мс) и БД(дестяки мс).
И напомните, сколько там папка node_modules весит?
Делать SPA, конечно, стильно-модно-молодежно, но зачастую - это стрельба из пушки по воробьям, учитывая реальные нагрузки веб-ресурсов.
Потому что куча легаси кода...кому то ж его надо поддерживать
Большинство хейтеров пыхи последний раз видели ее на версии 5.3 в виде самописной админки. На современном Symfony или Laravel писать сейчас приятнее, чем на половине модного js-стека, где зависимости ломаются каждую пятницу)
Не соглашусь. Есть ещё те, кого, видимо, задевает, что бизнес не очень хочет платить за разработку 100500 денег просто потому, что она ведётся на Java/Go/etc. А также есть те, кто почему-то отталкивается от инструмента, а не от задачи.
Большинство фанов повторяют мантру о том, что PHP уже не то говно, что было раньше. Но если объективно: что уникального может предложить PHP в 2к27?
Языковые возможности? Так PHP едва догоняющий.
Убийственную производительность? Нет, определенно: тут уже Go. Если логика сложная - Spring Boot или ASP.NET Core.
Невероятный DX? Fullstack-фреймворки на JS зарулят.
Ошеломляющее количество специалистов на рынке? Джаваскриптизёров всё равно больше.
Единственная суперспособность - программирование в стиле “Как раньше”: кастомизация готовых CMS, правка скриптов на проде голыми руками.
Тулинг он может предложить
Смотри выше
Если вы про этот коммент, то это ж буквально мимикрия под JSDoc. Мой вопрос был про киллер-фичи, которых (еще) нет у мейнстримовых технологий, что заставило бы выбрать именно PHP.
Не обязательно бежать быстрее медведя, достаточно бежать быстрее второго охотника.
Я уже потыкал в недостатки Go, которых нет в PHP. Могу потыкать в другие языки.
И, да, с нуля я бы PHP не выбрал. Но бежать переписать старые 15 летние системы я не собираюсь. Среди них имеются и денежные, с нормальными стабильными бюджетами
Назовите чего в пхп нет?
Скорость? Есть, берете не умирающий родранер или вообще свуль.
Количество инструментов - больше чем где либо.
Количество специалистов, полно.
DX и рядом не стоял с пхп решениями.
Так в чем пхп догоняющий?
Сколько раз перед новым проектом я смотрел другие стеки и языки и каждый раз возвращаюсь к пхп, даже с LLM конда не надо учить сидеть что-то.
Так что попипшите на пхп потом вернитесь на свой стек и тогда поговорим
По моему мнению, живучесть и популярность PHP объясняется очень просто. Это единственный язык, который работает из коробки с web'ом.
Этот язык точно знает "кто он" и "для чего будет использоваться". Сразу после установки программисту доступны: dev сервер, интерфейсы для работы с HTTP, шаблонизатор для HTML, плагины для СУБД и т.п. И всё это интегрировано в язык, и поддерживается языком на уровне синтаксиса.
Вам не нужны никакие дополнительные библиотеки или фреймворки, чтобы начать писать web-приложение. И на такой крепкой основе сделать обёртку, по типу Laravel или Symfony, намного легче, чем для языков общего назначения.
То же самое было и с языком C, пока не появился Rust. C тоже знал "кто он" и "для чего он". Его используют как замену ассемблера, для доступа к железу, но со структурной парадигмой. Он популярен по той же причине, что и PHP. И смещает его сейчас язык, который позиционирует себя точно так же.
Исходя из этого мой прогноз: PHP продолжит жить, пока не появится новый улучшенный язык, заточенный под web
Это единственный язык, который работает из коробки с web'ом.
Ну вообще-то нет. Го, питон и ноде достаточно спокойно работают из коробки с вебом. При чем питон/джанго сейчас больше продвигается в массы (в том числе в школах/колледжах), а ноде/яваскрипт имеет бОльшую "совместимость" с фрондэндом, поэтому пхп сейчас для веба выбор уже отнюдь не однозначный.
Как PHP превратился в героя мемов и пережил все свои «похороны»