12.2
Karma
0.5
Rating
Несмеянов Кирилл @SerafimArts

Backend Developer at Rambler&Co

PHP в 2019: лучше, чем вы о нём думаете

0
Неблокирующий ввод-вывод и обработка запросов без убийства стейта — разные вещи, друг от друга особо не зависящие.

Почему? Работа без убийства стейта практически бессмысленна при наличии блокирующих операций, иначе 2+ запрос будет спотыкаться об них и в результате получится ещё хуже.


… ну если только не форкаться или не стартовать в несколько параллельных процессов с разгребанием по ним запросов балансером.


И неблокирующие сокеты в PHP есть, емнип, со времён PHP3 из коробки. А значит все или почти все операции с ФС доступны в неблокирующие режиме. Обёрток удобных нет, но сами операции есть.

Хм, через file:///?

PHP в 2019: лучше, чем вы о нём думаете

0
Я как и Volch так и не понял откуда возьмется разница при выполнении запроса, если так или иначе мне нужно дождаться получения данных.

Эээ… Ну так fcgi каждый раз стартует и интерпретирует php, а работая в эвентлупе этого не потребуется. Более того, можно один раз весь стейт инициализировать, а запросы обрабатывать мелкими хендлерами. Получаем то, что 80-90% кода на PHP просто выполнится один единственный раз за всю жизнь сервера, а не каждый раз.


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

Отсыл к PDO как раз и касается того, что в таком режиме работы проблема блокирующих операций — единственная остающаяся.


На счёт библиотек и фреймов… И да и нет. Всё же функции работы с файловой системой, например, являются частью stdlib языка. А они блокирующие.

PHP в 2019: лучше, чем вы о нём думаете

0

Пользователь как раз не особо увидит разницу между 5мс и 15мс.


А в противном случае никто не мешает работать в эвентлупе, а в БД ходить не через PDO, а через, например, mysqli (там есть асинхронные запросы). И в результате получим всё то же самое, что и в Go:


Заголовок спойлера

image


Только этим никто особо не занимается, т.к. подобные копейки редко кому нужны на практике.

PHP в 2019: лучше, чем вы о нём думаете

0
Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать SELECT * FROM users WHER id=1 и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.

Как раз наоборот. Все тормоза в скорости работы PHP как раз из-за блокирующих операций.


Т.е. при сравнении "hello world" на Go и PHP скорость будет ± идентичная (благо на дворе 2019ый и PHP на синтетике не уступает gcc -o2), а вот когда появляются "блокирующие" операции, то:


1) В Go самым логичным вариантом является не писать такой код, т.к. он зафризит вообще всё. Ну и плюс горутины (которые вообще в другом треде висят) никто не отменял.


2) А для PHP в большинстве случаев это вообще не является проблемой, т.к. в современном мире он масштабируется процессами, а не тредами. Т.е. удобство использования и лаконичность было изначально в приоритете, нежели скорость. И любая операция в PHP, которая обращается к внешним ресурсам "под капотом" содержит что-то вроде: while (!result) { usleep.. }

PHP в 2019: лучше, чем вы о нём думаете

Сравнение производительности: JavaScript vs компилируемые языки

-3

Я может покажусь странным, но где PHP? Всё же с JIT он будет местами на уровне gcc -o2.


У меня даже пруфы будут:


Заголовок спойлера

Новое в PHP 7.4

+3
Подскажите какой именно функционал недоступен в PDO, но доступен в php_mysqli?

Асинхронные и неблокирующие запросы

Новое в PHP 7.4

0
Начерта мне шаблонизаторы, если похапэ сам по себе — отличный шаблонизатор?

Ну, скажем так, современные шаблонизаторы — это не только вывод с экранированием. И там нативному PHP до них как до луны.


Но я допускаю, что возможно из-за того, что вообще не помню когда последний раз писал echo не совсем объективен в этом плане.


поломка обратной совместимости в минорной версии

Мы все прекрасно знаем какие у PHP "минорные версии"))) Такой же php 5.2 -> 5.3, например, вообще полностью изменил язык в своё время.


джависты вон дженерики поломали

Джависты себе давно язык сломали (пользуясь случаем) =)


Тем более, когда это ломает 12 из топовых 1000 пакетов, причём ломает не на уровне "в такой ситуации возникнет баг", а на уровне "вообще не запускается"

Ну вообще это ССЗБ. Смотря на такой код: https://github.com/symfony/messenger/blob/4.1/DependencyInjection/MessengerPass.php#L118 Мне рыдать хочется. Блин, неужели так сложно разрабам скобки расставить было? А ещё пишут что в симфони норм код...


У меня нет, короче, контраргументов =) Ну убили совместимость, да, но как раз в тех местах за которые надо писателей на костёр отправлять.

Новое в PHP 7.4

0
Что идёт дальше — я не понял умора. Зачем-то выпилили <?, хотя это очень даже удобно

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


Для шаблонов удобно и красиво. Было.

Для шаблонов есть шаблонизаторы.


Менять приоритет операторов — это гениальный ход. Народ-то думал, что синтаксические косяки придётся тащить во имя обратной совместимости, но разрабы PHP были полны решимости.

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


а повсеместно нужный тернарный оператор запретили

Тоже самое что и выше: "Не читал, но осуждаю". Никто не запрещал тернарных операторов. Запретили говнокод в тернарниках.

Новое в PHP 7.4

Новое в PHP 7.4

Новое в PHP 7.4

Новое в PHP 7.4

Новое в PHP 7.4

+2

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

Новое в PHP 7.4

+1

Настраивать целый интерпретатор под один единственный проект и каждый раз мучать админов для перенастройки, если что пойдёт не так — это само по себе извращение.

Новое в PHP 7.4

+1

Потому что он настраивается на уровне php.ini и как следствие — глобален на все проекты на сервере сразу (давайте временно забудем про докер и прочие штуки и возьмём в качестве примера типичный VPS прод или шаред).


Так что либо придётся прописывать opcache.preload=/home/username/site.org/vendor/preload.php
под один единственный проект. И при появлении site-2.org уже ничего с этим не сделать.


Либо делать тоже самое на уровне fpm конфигов в виде php_flag[opcache.preload]=xxx. Что примерно тоже самое, но получше, т.к. можно отдельно воркеры под каждый ресурс запилить.

Новое в PHP 7.4

0
Насчет интерфейса внешних функций например на C я не понял этот код будет налету компилироваться всякий раз или только при первом запуске или еще как?

Зависит от настроек в php.ini. По умолчанию FFI доступен только в файлах, которые загружаются с помощью preload функционала (файлы для которого, напоминаю, тоже указываются в ini конфигах).


Пруфы:
1) ffi https://github.com/php/php-src/blob/master/php.ini-production#L1892
2) preload https://github.com/php/php-src/blob/master/php.ini-production#L1854


UPD: Персональное ИМХО по этому всему: Функционал с прелоадом и ffi будет очень слабо востребован в связи с тем, что его почти невозможно нормально использовать.

Как быстро попробовать CQRS/ES в Laravel или пишем банк на PHP

PHP-Дайджест № 156 (6 – 20 мая 2019)

+3

К сожалению, слоников надо было заказывать за несколько месяцев до начала конфы. Мы там по срокам просто не успевали сделать всё в таком количестве. На следующей уже будет, теперь опытные =)

Краткий и бодрый обзор архитектуры компиляторов

0
На PHP я реализовал токенайзер на генераторах и два прохода по сути идут параллельно :)

Тут есть несколько проблем:


  1. Нормальный (по скорости) лексер на пыхе возможен только с использованием preg_match_all/preg_replace_callback, т.е. с полным анализом всего и сразу.
  2. Даже если написать вручную это дело или используя preg_match, то нужен буфер для всяких lookahead в парсере.

А ещё я бы попросил ссылочкой на гитхаб в меня покидаться, не отказался бы посмотреть на это дело, можно?)

Асинхронный PHP и история одного велосипеда

+3

Мне удобнее писать:


$user = yield $account->findUserByEmail($email);

try {
    yield $this->validateUserDoesNotExist($user);
    yield $this->createUser($email, $password);
    yield $this->sendRegistrationEmail($email, $password);
    yield $this->sendAckSuccess(true, $callback);
} catch (\Throwable $e) {
    // ...
}

И автокомлит будет, и статический анализ, и меньше лишних then/otherwise

Асинхронный PHP и история одного велосипеда

+2
А в чем проблема?

В этом примере? Огромное количество лишнего и ненужного кода, например =)

PSR-14 — главное событие в PHP

0

В случае psr-3 берётся LoggerInterface и без каких-либо изменений всовывается в любой фреймворк. Это как раз публичный интерфейс, который можно запросто дёргать и напрямую без всяких обвязок и подмена реализации на другую ничего не изменит. Миддлвари имеют примерно такую же цель. Про этот интерфейс разработчик знает и активно может использовать.


А вот EventDispatcherInterface — это внутренняя и частная реализация диспатчера, которая никуда не торчит. Что мы потеряем если вообще удалим этот интерфейс? Какую переносимость потеряем и что не сможем сделать?

PSR-14 — главное событие в PHP

0

Совместимость компонентов фреймворков? Это чтобы использовать ListenerProviderInterface из зенда и подсовывать его в EventDispatcherInterface из ларки? Именно для таких задач этот провайдер существует?


Ну… Это не то что странно… Это вряд ли вообще кому-то вообще нужно, скажем так.

PSR-14 — главное событие в PHP

0
Основные училия сейчас направленны на ФФИ. Лично меня они радуют. Должы и Вас. Потому что можно будет писать свой новый ПХП по верх стандартного.

Это вы про бесподобный пост от ircmaxell?

PSR-14 — главное событие в PHP

0

Когда буду алгебраические типы, тогда можно будет. Мои попытки написать RFC на эту тему закончились тем, что их внедрение потребует дохрена всего. Очевидно, что подобные вещи надо внедрять постепенно и ковариантные тайпхинты вполне себе первый шажок в этом направлении.

Чудеса упаковки от Microsoft: ядро Linux в Windows 10 и движок IE внутри Chromium Edge

0

Так иксы вроде уже закопали (ну или пытаются), а на замену идёт wayland.

PSR-14 — главное событие в PHP

PSR-14 — главное событие в PHP

0

С таким же успехом, перефразируя, можно спросить про то, зачем ему знать об объекте, ведь событием может быть и массив, и строка… Не правда ли? Zend и Laravel тому в пример.


P.S. Но с другой стороны понятна причина добавления тайпхинта, т.к. есть вот такой RFC: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters Позволяющий сузить область при наследовании и указать конкретный тип. Но… Но мы возвращаемся к первому моему примеру с EventInterface, чем он в таком случае не угодил? Пусть даже с пустой реализацией, но мы сразу же выкинем из под категории "событие" весь stdlib php и все вендорные классы, которые не являются потомками EventInterface

PSR-14 — главное событие в PHP

0

Да, я вижу что в dispatch можно передать что угодно, хоть stdClass… Но если это допустимо, то почему нельзя передать строчку? Или массив? Если не делать ограничений на типы объекта, то почему нужно ограничивать объектом? Ну ладно, опустим этот момент.


А теперь главный вопрос: Вот вы совершенно правильно говорите, что идентификатор должен детектить провайдер, который используется внутри диспетчера. А нахрена в PSR нужен интерфейс провайдера, который является частным случаем реализации диспатчера, должен использоваться только внутри него и совершенно не пригоден для использования вне? PSR как бы про публичные интерфейс, которые дёргаются внутри пользовательских приложений.

PSR-14 — главное событие в PHP

0
Видимо решили так сделать, чтобы диспатчер и/или листенеры могли отличать экземпляры событий одного класса, по event type или event source еще как-то, хз, в зависимости уже от конкретной реализации.

Для этого и у Zend, и у Laravel, и у Symfony и, наверняка, ещё у кучи других есть имя события. Так что можно было бы сделать запросто вот так:


interface EventInterface
{
    public function getName(): string;
}

interface EventDispatcherInterface
{
    public function dispatch(EventInterface $event);
}

interface ListenerProviderInterface
{
    public function getListeners(string $name): iterable;
}

Microsoft Build 2019 — прямая трансляция на русском

Microsoft Build 2019 — прямая трансляция на русском

Microsoft Build 2019 — прямая трансляция на русском

Microsoft Build 2019 — прямая трансляция на русском

0
msgeek подскажите пожалуйста, а есть нормальная запись на ютубе? А то VK не позволяет нормально развернуть видео на пол экрана, плюс лагает неимоверно.

PSR-14 — главное событие в PHP

0
Фреймворки подтянут минимальную версию php до 7.2. Это же хорошо.

Лишь в следующих мажорных релизах и то вряд ли. И это не плюс, а скорее минус: Мы получаем уменьшение количества поддерживаемых версий PHP из-за одного единственного интерфейса, т.к. объективно 7.2 (как и 7.3) проходные версии, которые ничего особо нового не добавляют и следующий инкремент с 7.1 оправдано делать лишь на 7.4, т.к. там огромное количество киллерфич добавляется.


Но с другой стороны, а какой интерфейс должен быть о Event? И чтобы всем подошло. Я думаю это тема будущих дискуссий.

С другой стороны а нужен ли вообще этот PSR-14? У разных фреймворков разные реализации. У Symfony, например, события именованные и внедрение PSR-14 ломает вообще всю обратную совместимость. У Laravel и Zend вообще события содержат обычный массив и тут ситуация ещё хуже.


А если уж делать PSR полностью, то где вообще addListener, removeListener, и прочее?


Хорошо, вот ещё пример проблем PSR-14: Почему вообще getListenersForEvent должен содержать объект?


// Метод из диспатчера Symfony в качестве примера добавления листнера
$dispatcher->addListener(SomeEvent::class, function () { ... });

// Получение листнеров из Symfony
$dispatcher->getListeners(SomeEvent::class);

// А это уже PSR
$dispatcher->getListenersForEvent(new SomeEvent()); // Нахрена тут объект?

PSR-14 — главное событие в PHP

+9
А теперь о реализации, а точнее про тайпхинт «object»:

1) Тайпхинт object доступен начиная с PHP 7.2, однако почти все фреймворки используют в минималках 7.1
2) object не доступен для перегрузки, а значит вот такое просто невозможно:
class Dispatcher implements EventDispatcherInterface
{
    public function dispatch(EventInterface $event) { ... }
    // Fatal error:  Declaration of Dispatcher::dispatch(EventInterface $event) must be compatible with EventDispatcherInterface::dispatch(object $event)
}

Как следствие — куча оверхеда и минус консистентность.

Выводы, думаю, очевидны: PSR-14 — в текущем виде печален и не удивительно, что Фабьен ушёл из PSR после принятия 14го.

PHP-Дайджест № 155 (22 апреля – 6 мая 2019)

+1
Компилятор PHP, также известный как кроличья нора FFI — Интересный пост о типах компиляторов, принципах их устройства, и собственно о реализации ahead-of-time (AOT) компилятора PHP с использованием LLVM и самого PHP.


Это самое безумное и охренительное, что я когда-либо видел! А FFI биндинги под llvm с примерами использования вообще бесподобны.

PHP-Дайджест № 155 (22 апреля – 6 мая 2019)

0
Вообще, можно было сделать просто fn алиасом на function, получилось бы более консистентно, имхо:
class X 
{
    public fn a() { ... }
    public function b() { ... }

    public fn c() => ...;
    public function d() => ...;
}

$a = function ($x) use ($z) { ... };
$b = fn($x) use ($z) { ... };

$c = function ($x) => ...;
$d = fn($x) => ...;


А отличия были бы только в "=>" vs "{}", в первом случае только одно выражение + захват контекста, а во втором много выражений + контекст через use.

В PHP 7.4 войдут стрелочные функции (сокращенная запись анонимных функций)

+3
так сделано в языке Hack; но слишком сложно для текущего парсера


Вообще-то нет, LALR всё это позволяет. Аргументация была другой, что это дополнительные нагрузки на lookahead парсинг (т.е. неоднозначность грамматики), тогда как PHP чувствителен к скорости парсинга, а значит профитнее добавлять префикс, вместо суффикса.
1 There