Есть ли техническая киллер-фича у PHP?  Публичный пост

Никогда не занимался PHP разработкой, имел дело с PHP только в конце нулевых, когда язык был на совсем другой стадии развития (и я тоже).

И вот намедни понадобилось написать пару скриптов именно на PHP, я что-то там быстренько состряпал, но суть не в этом.

Лирическое отступление
Есть ли что-то вроде гайда "PHP для опытных разработчиков Java/.NET/Python/etc"?
Если кто-то знает, напишите, было бы интересно.

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

Мне удалось выделить три основных плюса PHP:

  1. Большая кодовая база, написаны решения для большинства задач
  2. Большое количество и невысокая стоимость посредственных разработчиков на рынке (с хорошими разработчиками всё плохо и дорого, как и везде)
  3. Наличие PHP на любом хостинге за доллар

Я заметил, что все эти плюсы являются экономическими, а не техническими, т.е не касаются производительности языка, среды выполнения, удобства работы с разными СУБД, синтаксического сахара и т.д.

Отсюда вопрос к PHP-боярам - какие плюсы я упустил, и есть ли у современного PHP какая-нибудь чисто техническая киллер фича, заметно отличающая его в лучшую сторону от других технологий бэкенда?

44 комментария 👇

Есть, и это отсутствие необходимости рестартовать сервер при изменении файлов для подхватывания изменений.
Мало кто задумывается об этом, но это невероятно влияет на продуктивность. Когда ты поменял файл и он у тебя работает сразу без ничего то это невероятно ускоряет процесс работы. Ты как в репле, только без репла.

В java тебе нужно пересобирать проект (если не использовать тулзы типа хаченной jvm или JRebel). В python нужно рестартовать сервер и это может занимать минуты! Даже фронтенд уже скурвился и требует несколько секундной (а то и больше!) компиляции и сборки вебпаком! В PHP тебе ничего не нужно. Ты просто пишешь код и жмешь F5 в браузере.

То же самое с Rails.

Среди программистов никто не понимает важности скорости подхватывания изменений, а тот, кто работает на PHP/Rails не подозревает, что весь остальной мир страдает.

Я даже статью об этом написал.

Это преимущество работает только в контексте веб-разработки.

Если ты, например, пишешь код который вызывается по крону, выполняет какую-то работу и завершается, то все равно при разработке придется вызывать его руками.

По моему опыту, разработка большого бэкенда на PHP превращается в ад:

  • неэффективное представление данных в памяти приводит к большему чем у других языков потреблению памяти,
  • динамическая типизацая ведет к написанию подверженного ошибкам коду (писал на PHP до появления тайп хинтинга, но не уверен, что и он решает все проблемы связанные с типами).

Из своего опыта могу сказать, что когда перешел с PHP на языки со статической типизацией, то часто ловил себя на мысли: как же круто то, что я почти всегда точно знаю скомпилируется и запустится ли текущая версия моего кода или нет. И если не скомпилируется, то я обо всех (хорошо, почти обо всех) проблемах узнаю на этапе компиляции, а не в рантайме в проде. И если я знаю, что мой код еще в нерабочем состоянии, то и лишний раз тратить время на его запуск нет смысла.

Если писать бэкенд на статически типизированном языке, а PHP использовать на фронте, то описанных выше проблем не будет, но возникает другая. Если фронт писать на java-скрипте, то один и тот же фронтендер сможет писать на одном языке и в браузере, и на сервер сайде. Это эффективнее точки зрения человеческих ресурсов и перевешивает отсутствие необходимости рестартить сервер.

Короче говоря, на фоне всех минусов PHP вот этот один плюс, про отсутствие необходимости рестартить приложение, совсем не кажется той киллер-фичей из-за которой в 2020 следует начинать писать новый проект на PHP.

@romka, с типизацией всё стало нормально начиная с 7.4, когда появились typed properties у классов (я не скажу что стало хорошо, потому что 90% заимствованного кода на неё забивали и забивают, так что даже если начнёшь писать по уму и IDE тебя горячо поддерживает, то всё равно будешь имет проблемы от сторонних компонент).

На мой взгляд, основная и принципиальная беда дизайна PHP - это передача параметров:
myFunc (666, true, true, true, "text");

Конечно, продвинутое IDE тебе подскажет ху из ху, но никак не спасёт, если тебе нужно передать только myFunc (666, "text"), но кто-то подизайнил функцию вот так вот. Это сплошь и рядом даже в стандартной библиотеке: в версии Х решают добавить парамент, конечно же для обратной совместимости он идёт в конец списка и гуд лак тебе отрефакторить код для его использования: код станет только ещё хуже читаемым после такого рефакторинга.

Этому нашли решение в некоторых фреймворках в виде передачи параметров массивом, но такой подход убивает преимущества типизации. И всё, затык. Потому согласен - в 2020 для новых проектов, которые надо именно что кодить, а не разворачиватьиз полуфабрикатов, выбор PHP будет ну очень сомнительным (сказал я, у коготорого в 2019 начался проект на PHP).

@zahhar, в 8 версии исправили и это, теперь есть именованые параметры. Там не без своих косяков по обратной совместимости публичных API, но одной болью меньше.

@alroniks, да, я наконнец-то накатил себе 8й и ненарадуюсь!

@romka,

работает только в контексте веб-разработки

Но ведь пыха это и есть язык для веб-разработки :)

Автор спрашивал об одной киллер-фиче языка/экосистемы, я ему ответил. То что эта фича не перекрывает других недостатков это уже другой вопрос.

На Rails мне намного приятнее разрабатывать чем на чем угодно другом. Даже если не использовать Sorbet (местный костыль для статической типизации). В том числе и из-за zero-downtime reload. Developer experience для меня имеет очень большое значение, но как видим большинство не этого не понимает.

Взял и залип в ваш блог почти на день.

@lopar, )))) ставьте лайк жмите колокольчик :)))

Ну очень сомнительная фича. Прочитал Вашу статью. И она, наверное, справедлива для веб-студий и относительно небольших проектов.
Но гнаться за скоростью в ущерб качеству без тестов, статического анализа, ревью, и возможности отката изменений методом автоматического деплоя - просто погибель для больших проектов. Ибо простой даже в пару минут - большая потеря средств и репутации. А с FTP и прочим это будет именно так.
CD подменяют те же контейнеры незаметно для пользователя. И так же откатываются в случае чего.
В любом случае, если уйти от FTP и прочего rsync, то это уже не фича, так как перезапуск все равно потребуется.
P.S. - Насчет запуска бэкенда на питоне, который занимает минуты. Ни разу с таким не встречался. Хотя есть большие проекты на питоне (может кто-то меня поправит, если я не прав). Это больше справедливо для Java.

@SLRover, я и не говорил что в прод (или не в прод, неважно) нужно деплоить по FTP, не путайте.

Я лишь говорил о фиче языка/платформы, которой нет в других языках/платформах и о которой никто не задумывается потому что не понимает, насколько это важно.

Тесты и статический анализ (а он должен быть и для пыхи, у Ruby есть Rubocop например) никто не отменял.

Похоже что никто не понял моего посыла и начал сразу цепляться за то что "эта фича не перекрывает кучи других недостатков языка" хотя автор спрашивал про

есть ли у современного PHP какая-нибудь чисто техническая киллер фича, заметно отличающая его в лучшую сторону от других технологий бэкенда?

Логично, ведь возразить нечего, потому что код компилируется :)

@rozhok, Я в контекссте статьи отвечал. ) Но если брать именно как одну техфичу, то да. )

В облачных системах это преимущество исчезает, потому что такой подход не позволяет эффективно определить готовность и живость сервиса. Там приходится пилить асинхронные сервисы, которые приходится перезапускать для подтягивания изменений.

@EduardSurov, преимущество это в первую очередь для разработчика, а не для (дев)опса.

@rozhok, а разве еще сохранились конторы, где проблемы деплоя шерифа не волнуют?

Слушай, а на суровом производстве к чистому пыху разве не положено приладить миллион оптимизаторов, компайлеров, транспайлеров и AoT, так что сборка будет занимать столько же времени, как в джавочке?

@ganqqwerty, да как бы и нет. А главное - зачем?

Да хрен его знает, зачем, чтобы быстрее фурычило, например.

Похапе в последнее время движется в сторону этакой интерпретируемой джавы. В вебе основной конкурент - python, и пыха его уделывает по причине высокой скорости (кто бы мог подумать лет 10 назад) и какой-никакой типизации. Коммьюнити в последнее время порядочно очистилось: хипстеры, макаки и вкатывальщики свалили на golang, и начали появляться нормальные инструменты. Например, Infection - один из немногих в мире нормально работающих фреймворков для мутационного тестирования. Psalm по сути превращает пыху в этакий тайпскрипт с контролем чистоты и мутабельности.

Выше писали про выгоды от ограниченности файла - это постепенно отмирает, на дворе 2020, все в микросервисах и на асинхронных (да-да, с генераторами появилась и асинхронность) фреймворках (swoole, amphp). Вообще в основном похапе ругают те, кто за ним не следит и отвалились где-то в районе выхода 7.0; кто на нем работает - затаили дыхание, потому что сейчас что-то вроде момента истины: или феникс восстанет из пепла возрожденным за несколько лет, или оCOBOLится окончательно. Развитие сейчас идет очень быстро, но и проблем очень много.

А почему уходят в Go? Не знал что он так популярен среди бывших Php-разрабов, там же мозг сломать можно об взаимодействие рутин через каналы, да и такая мощная модель concurrency очень далеко не везде нужна, только на хайлоаде. Думал хайлоад не место для вкатывающихся хипстеров.

@TepMex, по своему опыту, на Go переписывают что-то ресурсоёмкое и высоконагруженное, но не требующее отдачи сложных html (в идеале вообще plaintext/json). А остальная часть продолжает пилиться на PHP.

@TepMex, go выбирают за простоту и затыкают им дыры, где не едет или нет возможности нормально сделать на PHP. Простота языка и большие потребности встретились, что называется.

@TepMex, он модный, на нем написаны модные докер и к8с, достаточно простой, довольно быстрый, сделан Гуглом и Гугл же вложился в ПР, все орут про зарплаты высокие. Плюсы и минусы самого языка тут имеют минимальное значение. Golang сейчас в каждой дырке, ты что, какой хайлоад.

@EduardSurov, а где тестики что php быстрее python?

Есть ли техническая киллер-фича у PHP?

Каждую переменную начинаешь со знака долор. Успешный успех неизбежен.

Попробую побыть адвокатом дьявола.

Киллер-фича (ну она как меч - обоюдоострая, то есть номально несоглашаться с тем, что она отличает прям-таки заметно в лучшую сторону), что в PHP-проекте каждый файл максимально обособлен, выполняется отдельным процессом, имеет своё окружение и т.п. То есть PHP-проект, простите за сравнение, как пачка лябмда-функций в AWS

Это позволяет:

  • упросить и ускорить деплоймент - даже самые дремучие конторы и новички в веб-разработке легко поднимают 2-3 среды разработки и тестирования и CI/CD пайплайн из гита на нужный ftp-сервер;
  • быстро добавлять всевозможные А/В-тесты и фичер-тоглы, то есть модифицировать кусочки приложения;
  • экономит время на компиляцию, запуск/перезапуск сервера приложения, при этом всё ещё сохраняя приемлимую производительность с неплохой скалируемостью (файлы независимы, то есть склировать можно условно только часть приложения, создающего бутылочное горлышко, даже если это монолит);
  • запускать PHP-код на любой платформе с любым веб-сервером (Apache, Nginx, Caddy, IIS, в облаке AWS/Azure, в докере/без докера, что там ещё бывает).

Конечно, прямо сегодня эти "киллер-фичи" не перевешивают минусов PHP, потому его применение для индустриальной и энтерпрайзной разаботки ну если не невозможна, то очень-очень затруднена. Особенно очевидным это стало в последние лет 5 на фоне распространения PaaS для других языков программирования (Python, Ruby те же), облаков, крутого тулинга и появления .NET Core, Go, и Node.js у каждого из которых есть сильные киллер-фичи.

PHP остаётся в нише для малого бизнеса, где важен экономический контекст прежде все (множество опен-сорс проектов и библиотек, множество фрилансеров по доступным ценам, хостинг по доллару - вот всё что вы перечислили). Это пожалуй реальная киллер-фича, но не для разработчиков вот только :)

Так-то ребята из порнхаба и мамбы на PHP пишут потому что он годен только для малого бизнеса...

@rozhok, так-то кто-то и микроскопом гвозди забивает.

В любом большом бизнесе множество причин может быть - начали на PHP когда были малым бизнесом, выросли с ним, так зачем переписывать то что работает? Наверняка какие-то другие языки программирования у них тоже используются, не PHP единым.

Или собрали дружную продуктивную команду, научились находить и нанимать толковых программистов на PHP, настроили удобное окружение для работы - так инет повода переключаться на другой стек, ведь это только увеличит риски где-то пофейлить. И так далее.

@rozhok, очень важно понимать какие конкретно задачи в этих сервисах решаются на PHP.

У меня на этот счет нет информации, но я готов поспорить, что область применения PHP ограничена фронтендом, а для инфраструктурных, аналитических и т.п. задач используется что-то другое.

@romka, так пыха это язык для веба :) Конечно тупо на нем писать деплоймент скрипты или спарк джобы для бигдаты, но ведь никто про это не говорит.

Кто-то приводит утверждение, что ентерпрайз/большой проект не написать на пыхе (а вы кстати видели энтерпрайз на джаве? я писал и видел, там ненамного лучше :)) Я в ответ привожу порнхаб, мамбу, вк, фейсбук и Slack (да-да, там тоже на пыхе все написано!). Мне говорят "сомневаюсь что там аналитика написана на пыхе". Ну ок, лол, пыха же для веба делалась.

@rozhok, воу-воу, вот так и начинаются холивары :) я не утверждал
"что ентерпрайз/большой проект не написать на пыхе" - это вы так интерпретировали мои слова, что сегодня "его применение для индустриальной и энтерпрайзной разаботки ну если не невозможна, то очень-очень затруднена." Есть разница?

Касательно Слака: продукт разрабатывался в 2011-2013 году. Тогда у них было меньше вариантов, на чём писать. Но кроме PHP у Слака под капотом ещё куча всего (https://wiredelta.com/how-was-slack-developed/).

С Мамбой такая же история - она активно развивалась в 2005-2010 годах. Там такое махровое легаси, что его просто нет смысла трогать уже.

И с ФБ тоже непросто: они не зря свой HHVM создали в итоге. Да, там много PHP, но он тоже туда пришёл из начала 2000х, когда закладывалась архитектура.

Это как говорить про Кобол какой-нибудь: да, на нём написано дохренаярдов строк кода, которые всё ещё разрастаются. Но покажите мне банки, которые пилят новые проекты на Коболе в последние 10 лет? Похожая история и с PHP.

А про телеграмм что скажете тогда? Да, там не php, а kphp, но все-же?)

Уже сказали:

его применение для индустриальной и энтерпрайзной разаботки ну если не невозможна, то очень-очень затруднена

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

@rozhok, что лишний раз доказывает, что если ты топ перец, то пофигу на чем писать.

Серверная часть Телеграма написана на PHP? А можно какие-то пруфы?

@Archivarius, сорри, не могу) Могу сказать, что там kphp)

Генераторы

У PHP есть приятная штука, которая так зовется.

Использовал правда один раз в жизни, мне надо было парсить очень жирный файлик и приводить его к другому формату - генератор спас мне огромное количество оперативки :)

Грубый пример

Пример без генератора:

$array = [];

function getData() {
    for ($i = 0; $i < 999999; $i++) {
        $array[] = $i;
    }

    return $array;
}

foreach (getData() as $data) {
    echo $data;
}

Пример с генератором:

function getData() {
    for ($i = 0; $i < 999999; $i++) {
        yield $i;
    }
}

foreach(getData() as $data) {
    echo $data;
}

Пример без генератора должен съесть в районе 33521784 байт, а с генератором - около нуля, а то и вообще обойтись без дополнительных аллокаций.

Почитать можно туть

Эта фича кстати много где есть, в питоне, js и руби например тоже.

@rozhok, нинал, спасибо. Это единственная фича у ПХП, которую я вспомнил)

Ну там про память что-то например. Что на каждый запрос запускается все и умирает тоже все, от этого понятное состояние и отсутствие утечек, не нужно какой-то сложной дрочи с перезапуском процессов, типа pm2

Есть ли техническая киллер-фича у PHP?

--тупить=)?

Не, эта эстафетная палочка уже перешла к python.

)) засчитано

😱 Комментарий удален его автором...

Сейчас вот задумался: если говорить именно про сам язык, то привлекает возможность явно переключаться между строгой и нестрогой типизацией в процесе разработки. Чаще всего нужна строгая, но в редких случаях, когда нужна нестрогая - это делается очень эффективно.

Самая интересная фича современного PHP - это скорость его развития. При этом все подобные языки начинали примерно в одинаковое время, но остальные в целом как-то стабильны с виду. Даже самый молодой Go наступил на собственные грабли, заявив, что они максимально просты и сейчас добавлять туда фичи и глупо и не по канонам, хотя и очень хочется. А в PHP говна в конюшнях еще не на один год расчистки хватит, делая всем "хорошо".

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб