Comments 99
В целом, каждый новый релиз активно поддерживается в течение двух лет и получает ещё один год «исправлений безопасности». Цель состоит в том, чтобы мотивировать разработчиков на PHP поддерживать актуальность версии: применить небольшие обновления каждый год намного проще, чем, например, перейти с 5.4 на 7.0.
Большинство пользуется ровно тем, что есть в дистрибутивах и, без достаточных на то оснований, предпочитает LTS-дистрибутивы. Без борьбы с LTS-ами этот мотивационный шаг не имеет смысла.
2) Вам не нужна банда рулителей, на небольших объемах рулением может заниматься и один человек (два для резервирования на случай отпусков/болезней/увольнений), причем разделяя эти обязанности с непосредственной разработкой, например. Или с администрированием.
А вот когда работал в РФ PHP-разработчиком в среднего пошиба аутсорсе (НЕ Москва, 150-200 человек всего, включая все сорта мобильных разработчиков, джавистов, сишников и прочих тестировщиков с менеджерами. PHP-команда человек 20 разработчиков, самый крупный отдел, если мне память не изменяет, таких компаний в СНГ должно быть очень много), делал полуавтоматизированную платформу быстрого деплоя PHP проектов для внутренних нужд — Q/A, демонстрация клиентам, проверка на не-девелоперском энвайроменте, обкатывание миграций при передеплое и прочее, естественно с поддержкой разных версий php. Делал руками, поверх виртуальных машин и LTS-убунты, потому что ни докера ни кубернетеса тогда еще не было (2011-й, 2012-й годы), были бы — наша жизнь была бы сильно проще.
БольшАя часть проектов, кстати, была на Drupal (не вордпресс, да, но лучше бы уж вордпресс).
Я к тому что вот это был вполне обыденный аутсорс и там эти технологии были бы применимы и полезны.
И кастомерам можно было бы отдавать готовые к работе контейнеры (сначала мы отдавали просто сорцы, потом какие-то рукодельные скрипты-инсталляторы, потом были chef/ansible/puppet/vagrant, потом я ушел, не знаю как там сейчас.
Пара слов в защиту WordPress: существует божественный Bedrock, который как раз реализует экосистему для CMS, и существует WordPress Packagist, который является репозитарием плагинов и тем для CMS. Все ставится композером, существует прозрачная система настройки окружения, манифесты для плагинов, опять же, под разные окружения. Кароче, мир WordPress разработки уже далеко ушел от того, что представляет сам WordPress из себя, теперь это ядро системы, которое обрастает удобным интерфейсом. К слову WordPress это уже давно просто админка для нормальных парней.
Я категорически не согласен с
php изначально обрекает себя быть в «догоняющих»На бэкенде у него свои давно завоеванные огромные территории. Он изначально рожден вместе с вебом. Да он слабо применим и практически не используется как универсальный язык. С этим не буду спорить. Но в своей нише он далеко не новичок и общий посыл автора о том что РНР точно не собирается на покой я полностью поддерживаю.
Если вам нужна кроссплатформенность наверное Java. Если вы увлеклись embeded то извольте С и С++. Если вы хотите ML и AI то Python рулит сегодня. И далее по списку. Существуют вполне нишевые языки Ruby, Rust, Haskel, Go на которых написано мало (по количеству проектов), но они решают определенный тип задач лучше всего. PHP тоже нишевой язык.
Мне довелось работать в Lazada и на бэке жил php, мы отдельные куски переносили в go, но все равно доля php была 80-85%. И оно жило под нагрузкой. А миграция с 5.5 на 7.0 дала почти двухкратный рост производительности и более чем двухкратное падение потребления памяти.
Как мне кажется, объяснение простое: экономически целесообразно для типовых решений иметь один язык на бэке.
Умирающие воркеры это не часть языка, а часть менеджера запросов. Архитектурных ограничений языка нет.
Я бы еще добавил, что разработка в целом тяготеет к веб-разработке, где именно php имеет значимый вес.
В моём представлении, сейчас можно:
— писать под веб
— писать консольные линукс-приложения
— писать графические линукс-приложения
— писать под винду
— писать под ведроид и ios.
С первыми двумя кейсами php справляется вполне успешно. Ну да, питон тоже. Касательно графических приложений под линукс — это какая-то очень узкая и странная ниша. Писать на питоне и на пхп под винду и мобилки — проще выстрелить себе в ногу. Те средства, что есть, настолько костыльны, что лучше бы их не было, наверное.
Единственный реально универсальные язык, который я знаю — это Java. Но он изначально таким и задумывался, кроссплатформенным и переносимым.
Чем питон универсальнее и «общЕе» пхп? Ну вот чем?
Несмотря на то, что при работе с PHP всё ещё можно написать очень плохой код, я бы сказал, что это отличный выбор для веб-разработки, если его использовать правильно.
Капитан на палубе.
Потом побаловались с флэшем и случайно пришли в веб на пхп. Это был еще то ли пхп2 то ли пхп3. Чем язык понравился? Простотой, возможностями в том числе стрелять себе в ногу. Чем не понравился? Малым количеством функционала и тормозами после с/асма.
Пхп4 оставил простоту и возможности стрелять в ногу, сильно расширил набор функций из коробки и сохранил совместимость. Это было круто, мы подсели на него сильно и даже сдали зендовский экзамен по приколу.
Пхп5 стал отнимать возможность стрельбы себе в ногу, откромсал часть совместимости и стал сложнее. Функционала он почти не добавил, но зато неплохо увеличилась скорость. Стали появляться яваподобные фреймворки.
Пхп7 еще больше отнял возможность стрельбы себе в ногу, откромсал уже солидную часть совместимости и стал существенно сложнее. Функционал почти не добавился, скорость увеличилась кардинально.
С одной стороны нас радует то, что скорость у пхп7 такая, что можно не смотреть на другие языки.
С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется установить композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсы и так далее, иначе ты не модный. Вместо простого языка получилось нечто явоподобное. При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях. Уже не первый раз ловим себя на том, что проект неплохо бы завернуть в докер, что бы не думать на какой из подверсий пхп у заказчика сервер, опять же лишний наворот.
Отсюда испытываем смешанные чувства, видим скорее не движение вперед, а скорее дрейф куда-то в бок с сильными и плюсами и минусами, но главное — с изменением идеологии. Не эволюция, а революция. Может быть это хорошо и мы просто жуткие консерваторы, в конце концов 20 лет с пхп это много. Но со времен пхп4 первый раз сильно хочется сменить язык.
p.s.: Це личное мнение, не обязательно правильное:)
использовать интерфейсы и так далее, иначе ты не модный
Разве код нужно писать по моде? Интерфейсы нужны для связи частей программы. Если Вам нужны контракты — используете интерфейсы, не нужны — не используйте.
При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях.
По моему опыту ломаются какие-то неочевидные или неоднозначные выражения (которые вообще по-хорошему не надо было писать, типа $foo->$bar['baz']). Язык идет к строгости и это круто.
Разве код нужно писать по моде?Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода.
По моему опыту ломаются какие-то неочевидные или неоднозначные выраженияВ пхп5 это было в бОльшей части верно, хотя уже были нюансы.
А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.
Это кажется мелочью если ведешь только свои недавно рожденные проекты и/или проекты на последних версиях современных фрейворков, при этом контроллируешь серверное окружение и никто не делает ошибок.
Язык идет к строгости и это круто.php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.
А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.
Незадолго до релиза php7 появился репозиторий (или даже несколько), с помощью которого можно было проверить совместимость с ним. У меня в нескольких проектах было только в одном месте выражение вида $foo->$bar['baz']), которое я исправил и успешно забыл о серьёзных различиях.
Не вижу ничего сложного. Если проект дикий легаси седых годов, то с ним в любом случае будут проблемы, даже без обновления. Тем более мажорного релиза php. Тут дело не в php:)
при этом контроллируешь серверное окружение и никто не делает ошибок
а если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.
если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.Может и странная, но мы ее не высказывали.
У меня в нескольких проектах… Не вижу ничего сложного.Так потому что это у Вас в своих нескольких проектах. В своих проектах у нас тоже никаких особых проблем нет, более того, изрядная их часть спокойно работает на любых 5.х-7.х версиях без поправок.
Просто мы как правило работаем с чужими проектами в том или ином виде. И если выход пхп5 не напряг почти никак, то вот после выхода пхп7 40% времени уходит на проблемы версионности.
Тут дело не в php:)Невозможно написать код так, что бы он гарантированно не поимел проблем с новой версией, просто потому что неизвестно что она поломает. И если новая версия что-то ломает, при чем без необходимости, то достаточно странно говорить «пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©
Странная претензия.
Может и странная, но мы ее не высказывали.
Цитирую место, из которого я сделал вывод про претензию (убрал лишние рассуждения, думаю, смысл не поменялся):
А вот в пхп7 уже достаточно… изменений
Это кажется мелочью если… контроллируешь серверное окружение и никто не делает ошибок.
Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимы. Если проблема в сторонних решениях — либо заменить, либо забить на обновление, либо контрибьютить совместимось — решения на любой вкус.
«пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©
теперь моя очередь:) «Может и странная, но мы ее не высказывали»© Я писал о том, что переход с одной мажорной версии на другую — однозначно требует проверки и доработки. Если на них нет времени/денег — значит не надо надеяться на авось.
Просто мы как правило работаем с чужими проектами в том или ином виде
если речь про аусорс и на переход с одной версии на другую не выделялось время, то проблемы версионности — проблемы того, кто изменил версию php на сервере.
если речь про сторониие библиотеки, то я встречал только 1 библиотеку не совместимую с php7.2 phpword. Конечно, это не показатель, но как я писал выше — есть скрипты для проверки совместимости 5. -> 7. если есть какие-то проблемы, то либо пофиксить, либо забить на обновление, если проект не предполагает бюджет на это.
Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимыЕсли велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого? А если второе обновление на 50% состоит из того, что дорожку адаптировали к стандартам трэкинговых, а не прогулочных дорожек (как было раньше) и именно из-за этого получилось 80%, а не скажем 20%?
Если велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого
Вы забыли упомянуть что этот велосипедист смотрит не куда едет а на небо.
php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.
Можете возразить, но я считаю что строгость в текущем контексте — с любой стороны хорошо(тем более она опциональна). Потому тут скорее «купить пользованую шестерку, а в ходе модификации получить приору какую-нибудь», до Феррари пока далеко )
Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода
Нутк вы ж не школьник, я надеюсь, чтобы следовать слепо за модой, своя же голова есть на плечах. Просто нужно возможностями языка пользоваться в соответствующих местах. Если вам нужно новую страничку или эндпоинт добавить в проект, который написан, скажем, на Symfony 4 — то да, нужно писать всё в том же стиле, что и весь остальной проект, а если нужно сделать
echo 'hello world' на голом пхп
то так и пишите.
То, что сейчас появилась куча стандартов и все стараются писать в соответствии с SOLID, то что есть прекрасный пакетный менеджер и развивающиеся фреймворки с большим комьюнити — это прекрасно. Просто нужно адекватно использовать все эти возможности и не тащить тяжёлую артиллерию туда, где она не нужна.
С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется
Совершенно ничего не требуется. Все работает ровно так же.
echo 'hello world'; Поменялось и стало более строгим именно там где люди пытались «городить огород» и делали это разнообразными костылями. И им постепенно сказали какими костылями можно пользоваться, а какими нельзя. А потом поотбирали костыли совсем.
Про
композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсывам уже написали. Это новые фишки, которые вы можете игнорировать и если ваш код не требует зависимостей и вы не путаетесь в наименовании классов или вообще не используете классы, все будет работать ровно также как работало.
Конечно, PHP-фреймворки не будут превосходить C и Rust, но они намного лучше, чем Rails или Django
Очень спорное заявление. Если судить по исходникам тестов, то правильно было бы написать: "Nginx + php_fpm намного лучше чем Gunicorn на чистом Python".
Замени Gunicorn на Nginx + uWSGI или на bjoern и результаты поменяются кардинально.
P.S. Но картинка шикарная. Стиль рисунка напомнил одну, в свое время популярную игру.
«Из зоопарка города Бердичева, похищен слон, необычной, полосатой породы...»
Прямо вспоминается реклама Internet Explorer sucks less.
Серьезные программные продукты никто не станет писать на PHP.
Зачем делать из PHP вторую Java, если уже есть Java? Которая с нормальной типизацией, с «настоящими» аннотациями, а не мимикрирующими под них комментариями, многопоточностью, асинхронностью. Она более логична и не раздражает программиста. Я не хочу умалять заслуги PHP в роли языка для веб-разработки, но если вы хотите иметь возможности для роста, а не застрять в «нише», для которой PHP был придуман, берите другой язык.
Ну а если хотите играть в низшей программисткой лиге и постоянно быть в роли догоняющих, выбирайте PHP.
Примерно затем же, зачем делать из телефона-звонилки современный смартфон, когда уже был компьютер. Новые фичи PHP не мешают старым задачам, а вполне себе даже помогают. То что они есть в других языках только доказывает их полезность.
По-моему, главное что мешает перебраться пхп в боле высшую лигу, это люди с таким вот мнением, как у вас.
Т.е. проблема более идеологическая, нежели техническая.
Она более логична и не раздражает программиста.
Ага, совсем не раздражает.
Заходит джавист в столовую и говорит «Паблик статик файнал Борщ борщ нью Борщ, пожалуйста.»
Но если вы хотите знать, как выглядит современная PHP-разработка, хорошим выбором будет познакомиться с одним из двух крупнейших.
Можно также упомянуть, что Symfony очень похож на Spring Framework из java со своей ORM Doctrine, которая является аналогом Hibernate.
А Laravel аналог Ruby On Rails с Active Record для работы с бд.
Очень люблю PHP, даже несмотря на все проблемы и косяки, но после 12 лет плотной работы перешел на Go, перевел основные проекты и сейчас понимаю, насколько все было сложно и тяжеловесно. После перехода на микросервисы как-то пропал драйв писать новое на PHP. Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP? А если еще на Laravel или Zend? На Go это происходит без малейшего напряга, сохраняя объектную декомпозицию и слабую связность.
На чем вообще поднялся PHP? В 2001, задолго до эпохи VDS, были ровно две альтернативы: perl и с/с++. Причем доступен только shared-хостинг для средней компании. Допустим, если хостинг с perl еще можно было найти, то со своими экзешничками мало где можно было захоститься, если у вас нет своего сервера. И тут возникает нечто, похожее по синтаксису на C, да еще и классы/объекты какие-никакие и можно недорого "скриптик в интернете" сделать. Причем я сразу начинал на ООП писать, а народ крутил пальцем у виска, типа выпендривайся в своем С++ с объектами. Со временем как-то дозрела отрасль и до объектов :)
Сейчас ситуация принципиально иная. Есть недорого хостинг с шелом и возможностью компиляции. Казалось бы, можно и на С/С++, но есть специальный вариант компилируемого С для веба, с интерфейсами/инкапсуляцией и огромным набором библиотек (Golang). Причем понятие фреймворка в принципе чужеродно и не приветствуется. Пакеты(библиотеки) с юниксовым подходом "одну функцию делать хорошо" и возможностью совмещать несовместимое, лишь бы набор методов/аргументов совпал. В PHP, к сожалению, нужно чтобы об интерфейсах имели представление все клиенты библиотек.
Делаешь в проекте россыпь пакетов, в одном из которых сервер, отдельно cli-утилиты, отдельно общие части для повторного использования. И все это со скоростью нативного кода, как будто модуль для nginx написал.
Куча кода PHP на поддержке осталась и если ничего не делать, через пару лет это перестанет работать после обновлений (приходится следить за языком, за нюансами конфига, за поддерживаемыми модулями), в то время как экзешнику без зависимостей пофиг. У меня есть микросервис-долгожитель, написанный на Go за два дня, кропает картинки, работает полтора года без перезапуска, сколько аптайм сервера. И память пока не сожрал.
Изучать ли PHP, инвестировать ли время, писать ли новый проект — гораздо сложнее ответить на этот вопрос сейчас, чем в нулевых. Вроде и ништяков много в языке, но и альтернативы интересные появились.
И у меня нет особого опыта на Go, но просто мне кажется вы чуть-чуть передергиваете.
приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс
Такая производительность обычно близка к производительности самого вебсервера (Nginx, Apache) при использовании локалки. Вот только что на своей машине проверил.
Далее вопрос, раз уж вы называете производительность для одного языка, то желательно привести производительность и второго рядом. Но прочитав вам коммент до конца, закрадывается впечатление что вы не соизмеряли одно с другим на одинаковых задачах. А просто написали пару микросервисов на Go и вам понравилось. И возможно у вас были какие-то проекты на РНР где вас не устраивала производительность. Но это никак не отражает какие-то особые преимущества Go vs PHP.
У меня на PHP не получилось преодолеть порог 50-70 мс отклика при минимальной нагрузке или на тестах показать больше 500-600 rps. Если речь идет не о пустом скрипте. Причем обычно счастье, если удалось утрамбовать отклик в 100 миллисекунд. От безысходности начал уже модули писать на С. На моей практике с php, если идет склейка каких-то выборок из sql/redis и очередей, плюс какая-то объектная логика, в среднем по больнице получается около 150-200 мс на среднем восьмиядерном сервере. Сверху еще передача по сети и, как правило, очень заметный по времени коннект к базе, если отдельно с этим не заморачиваться.
На Go пишу всерьез уже примерно два года и сравниваю одну и ту же бизнес-логику, переписанную без оптимизаций. Реально уровень производительности веб-сервера. Приложение на go и представляет собой веб-сервер в виде самодостаточного экзешника, который сам плодит легковесные треды и загружает все ядра. Можно сделать сборку сайта, с навигацией, пользовательской сессией, выборкой контента из базы, развесистой маршрутизацией, до кучи закатать туда веб-сокеты и время генерации html будет около 5мс. Естественно, что это при умеренной нагрузке и примерно 95 перцентиль, причем будут изредка выбросы до 15-20мс и большая нагрузка может дать удвоение-утроение. Но даже 50мс при 2-3тыс. rps выглядят очень привлекательно (это тупо VDS за цену в пределах тысячи, на которой php не сможет участвовать в сравнении, потому что умрет раньше при меньшей нагрузке). Nginx можно не ставить, но обычно остается из за удобства подключения сертификатов и привычного конфигурирования, чтобы не нервировать админа.
За советскую власть не буду агитировать, т.к. с PHP еще жить долго, людей нанимать не перестанут и можно в принципе не заморачиваться, но присмотреться осторожно к другим технологиям не помешает, вдруг понравится ;) Смысла сравнивать или/или совершенно нет, т.к. современный веб можно собирать из нескольких технологий, особенно с микросервисами. Больше свободы в выборе инструментов для разных задач. Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.
Простой РНР скрипт «Hello world» похоже не сильно отличается по скорости отдачи.
Хорошая отсылка к соединениям к соседям (ака Redis, MySQL). Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать `SELECT * FROM users WHER id=1` и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.
Я понимаю что концептуально бинарник всегда быстрее. Просто если поднят php-fpm и уже сидит в памяти. То на простых скриптах разница не будет в 10. раз как вы пытаетесь представить. Да при больших нагрузках в теории более «правильная» архитектура Go покажет свои преимущества. Просто, вынужден повториться, надо сравнивать одинаковые задачи. Порой проблема не в языке.
В ваших примерах (просто пытаюсь угадать) проблема может быть во фреймворках как ни странно. Например та же Doctrine от Symfony может очень сильно влиять на производительность и длину отклика если сравнивать с кодом написанным на том же PHP, но вызывающим MySQL напрямую без ORM. Есть очень серьезные проекты которые работают на PHP и имеют персентиль ниже 50 мс на проде с очень сложной логикой под капотом.
Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.Можете дать ссылочку на MVC framework для Go? какой-то аналог Symfony или Laravel?
Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать SELECT * FROM users WHER id=1 и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.Как раз наоборот. Все тормоза в скорости работы PHP как раз из-за блокирующих операций.
Т.е. при сравнении "hello world" на Go и PHP скорость будет ± идентичная (благо на дворе 2019ый и PHP на синтетике не уступает gcc -o2), а вот когда появляются "блокирующие" операции, то:
1) В Go самым логичным вариантом является не писать такой код, т.к. он зафризит вообще всё. Ну и плюс горутины (которые вообще в другом треде висят) никто не отменял.
2) А для PHP в большинстве случаев это вообще не является проблемой, т.к. в современном мире он масштабируется процессами, а не тредами. Т.е. удобство использования и лаконичность было изначально в приоритете, нежели скорость. И любая операция в PHP, которая обращается к внешним ресурсам "под капотом" содержит что-то вроде: while (!result) { usleep.. }
А какая разница пользователю блокирующе будет исполняться SELECT или нет, если ему нужен ответ?
Пользователь как раз не особо увидит разницу между 5мс и 15мс.
А в противном случае никто не мешает работать в эвентлупе, а в БД ходить не через PDO, а через, например, mysqli (там есть асинхронные запросы). И в результате получим всё то же самое, что и в Go:
Только этим никто особо не занимается, т.к. подобные копейки редко кому нужны на практике.
А отсыл к PDO и mysqli опять же только подтверждает мое утверждение что проблема не в PHP как языке, а конкретных библиотеках и фрэймворках для него написанных.
Я как и Volch так и не понял откуда возьмется разница при выполнении запроса, если так или иначе мне нужно дождаться получения данных.
Эээ… Ну так fcgi каждый раз стартует и интерпретирует php, а работая в эвентлупе этого не потребуется. Более того, можно один раз весь стейт инициализировать, а запросы обрабатывать мелкими хендлерами. Получаем то, что 80-90% кода на PHP просто выполнится один единственный раз за всю жизнь сервера, а не каждый раз.
А отсыл к PDO и mysqli опять же только подтверждает мое утверждение что проблема не в PHP как языке, а конкретных библиотеках и фрэймворках для него написанных.
Отсыл к PDO как раз и касается того, что в таком режиме работы проблема блокирующих операций — единственная остающаяся.
На счёт библиотек и фреймов… И да и нет. Всё же функции работы с файловой системой, например, являются частью stdlib языка. А они блокирующие.
Неблокирующий ввод-вывод и обработка запросов без убийства стейта — разные вещи, друг от друга особо не зависящие. И неблокирующие сокеты в PHP есть, емнип, со времён PHP3 из коробки. А значит все или почти все операции с ФС доступны в неблокирующие режиме. Обёрток удобных нет, но сами операции есть.
Неблокирующий ввод-вывод и обработка запросов без убийства стейта — разные вещи, друг от друга особо не зависящие.
Почему? Работа без убийства стейта практически бессмысленна при наличии блокирующих операций, иначе 2+ запрос будет спотыкаться об них и в результате получится ещё хуже.
… ну если только не форкаться или не стартовать в несколько параллельных процессов с разгребанием по ним запросов балансером.
И неблокирующие сокеты в PHP есть, емнип, со времён PHP3 из коробки. А значит все или почти все операции с ФС доступны в неблокирующие режиме. Обёрток удобных нет, но сами операции есть.
Хм, через file:///?
Работа без убийства стейта практически бессмысленна при наличии блокирующих операций, иначе 2+ запрос будет спотыкаться об них и в результате получится ещё хуже.
Бессмысленна она только если у нас однопоточная однопроцессная модель исполнения. В fpm точно не такая, в mod_php вроде тоже. Внешний диспетчер организует очередь запросов и передаёт их хэндлерам по мере обработки. Если надо, то форкает-убивает процессы. На уровне языка навскидку никакой поддержки не надо и только минимальная поддержка на уровне приложения (если оно грамотно написано, конечно), только на уровне диспетчера типа fpm значимые изменения.
Хм, через file:///?
Да :) Только тупанул, не проснулся ещё, не сокеты, а потоки, стримы. Через stream_select организуем наблюдение за пулом неблокирующих операций.
На простых тестах и единичных запросах все хорошо работает. Под бенчмарками с минимальной параллельностью съезжает до неприличных значений. К сожалению, в php очень дорогой вызов функции. Иногда прямо ломает лишний метод выносить, хотя было бы красиво. Я как раз приводил примеры реальной логики из реального проекта, специализированного поисковика, где нет текстовой шаблонизации и основная задача — выборка из быстрого хранилища и манипуляции хеш-массивами. По сути молотилка по формулам, которую уже некуда дальше оптимизировать. Просто описал свой опыт портирования практически один к одному. Это был первый реальный проект, который люди в теме еще и раскритиковали справедливо за расточительность в аллокациях памяти. Можно было взять железо помощнее, вынести что-то в модули, как сделал Фалкон. Или вот так вот тупо переписать. Дальше уже потихоньку втянулся, параллельно разрабатывая на php.
По поводу MVC вопрос дискуссионный. Фреймворки есть, но это немного не в стиле Go. Самый известный ORM — это, имхо https://gorm.io Лично мне такой подход к базе не нравится, но ORM таки есть. Для маршрутизации запросов хорошо зашел аскетичный https://github.com/gin-gonic/gin
Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы. Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу. Это дает просто немыслимую свободу в проектировании отдельных кирпичей с низкой связностью. Смысла нет создавать комбайн для всего в одном флаконе — для этого есть целый гитхаб пакетов на любой вкус, зачастую взаимозаменяемых. https://github.com/avelino/awesome-go
К сожалению, в php очень дорогой вызов функции.
Моя точка зрения состоит в том, что эти потери никак не влияют на время отклика, а если влияют то они измеряются в десятках процентов, а не в сотнях и не в разах, как вы пытаетесь представить. Именно это я называю передергиванием.
Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы.Именно. И именно это я и имею в виду, когда прошу вас предоставить какие-то тесты и доказательства, когда вы взяли голый РНР и голый Go, написали на них простую или немного непростую вещь, и получили результате отклик на Go 5ms vs PHP 50ms через тот же вебсервер.
Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу.Мне кажется это один из принципов в любом языке поддерживающим ООП. И РНР один из них. Никаких проблем с использованием интерфейсов я не замечаю. Или вы не пытаетесь сказать что это есть в Go но нет в PHP?
С интерфейсами интересная ситуация. В PHP интерфейс — это некая декларация с полным неймспейсом. Я не могу в неймспейсе потребителя интерфейса описать интерфейс локально, а подставить посторонний объект, который ничего не знает об этом объекте/интерфейсе. Интерфейсы должны быть описаны "глобально" и видимы всем, кто реализует и использует. Не уверен, давно не проверял, можно ли подсунуть объект под интерфейс, если он в цепочке наследования не заявляет implements. Кажется нет. Поправьте пожалуйста, если это не так.
В Go я могу локально объявить "методу нужен интерфейс publisher, который состоит из одного метода Publish()". Далее абсолютно любые объекты с методом Publish() могут быть переданы как аргумент и пролезут сквозь проверку типов. Автор объекта даже не знает, что реализовал интерфейс publisher, потому что для меня это требуемая зависимость, а для автора часть какого-то другого набора методов. В PHP для этого надо интерфейс сделать глобальным и заставить всех причастных сослаться на один и тот же неймспейс. Поэтому в PHP и слипаются во фреймворки наборы полезных объектов, из за необходимости поддержания единой иерархии зависимостей.
У меня вот сложилось впечатление, что Go хорошо подходит для инфраструктурных вещей, а вот для серьёзной бизнес-логики, именно для моделирования бизнес-процессов, сложных флоу, часто описанных в BPM нотациях или UML, с активной работой с БД на уровнебизнес-терминов. а не строк/записей, системі уровня ERP/CRM он как-то не очень, не хватает полноценного ООП, хотя бы как в PHP4 :) Есть основания так считать?
Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP?
Можно, постоянно так делаем :) Как раз с помощью Go.
P.S. в fasthttp на 1 заголовок больше приходит, не совсем честно. Могу согласится, что пхп всего ненамного медленнее
У меня есть сервис на основе этой библиотеки, скоро отмечу 8 месяцев без перезапуска. Редко когда отвечает более чем за 3мс. Да, не использует базу, но активно юзает винт. Память не утекает
Могу согласится, что пхп всего ненамного медленнее
Эээ… Либо я слепой и в тестах, кажется, всё чуть-чуть наоборот? Или я просто сарказма не понял?
P.S. Ходят слухи, что uv побыстрее libevent будет. Но это только слухи.
По факту, libevent наравне с go. Но латенси приятно радует
Про uv. Слухи лично подтвердить не могу, у меня получилось медленнее. В ближайшее время планирую использовать эту библиотеку на личном проекте. В этой библиотеке столько всего вкусного…
зачем писать два символа "->", когда в других языках пишут один "."Потому что "." занята конкатенацией строк, которая не может быть "+", потому что "+" — это арифметическая операция.
Зачам писать доллар перед переменными0) Улучшает читаемость кода — попробуйте на досуге разгадать длинную строку с большим количеством конкатенаций переменных без знака доллара.
1) Потому что с долларом их можно потом вывести в строке/шаблоне без ухищрений вроде String.format или %, а PHP изначально в основном использовался именно для вывода переменных в строку/шаблон.
2) Потому что можно экспандить через $$ (хотя и не нужно, это почти eval).
3) Потому что как и в perl это наследие организации работы с переменными в unix shell.
PHP очень древний язык и в общем и целом наверное имеет право на какое-то легаси.
И даже если не брать в расчет легаси, я бы сказал что это достаточно обоснованные технические решения, а перфекционизм, который не принимает обоснованные технические решения — это не здоровый перфекционизм.
PHP в 2019: лучше, чем вы о нём думаете