Comments 228
И пионеров, путающих асинхронность с поддержкой потоков на уровне языка — тем более переживём. Не первый раз.
Здоровья вам и долгих лет!
P.S. А самого Стогова слабо на подкаст позвать? И в глаза ему сказать, что он фигню делает?
А как же ReactPHP?
phppot.com/php/simple-php-chat-using-websocket
Первая ссылка в гугле — но вообще их тысячи.
Сам лично запускал вебчат на вебсокетах и чистом пхп лет 8 назад — работает до сих пор.
Ну и писал игру на вебсокетах и тп — всё работало. Проблем с вебсокетами небыло.
И это всё ещё на пхп 5.2.
Сейчас ещё проще стало.
Только фишка в том что вебсокет далеко не всегда нужен.
По сути — это вручную сделанный ивент луп. Тут есть ряд проблем. Представьте, что иногда у вас проскакивают долгие запросы в базу. В этот момент система не будет ничего принимать и отправлять, будет ждать ответа. PDO не умееет неблокирующие вызовы. Даже если извернуться и как-то сделать (вроде бы для amphp сделали вручную клиент для mysql), это все выглядит как нагромождение костылей, а не first class citizen
Если честно, то нагромождением костылей выглядят как раз нативные модули вроде того же mysqli.
Согласшусь. К сожалению, ассинхронность в php ещё сырая, могу судить по опыту использования amphp в продакшене, и будет требовать неоправданно больших усилий в поддержке, так как текущие библиотеки страдают нестабильностью (amphp/mysql, amphp/artax) и постоянно находятся какие-то ошибки, которых в нативных решениях будет сильно меньше.
Не то чтобы что-то реализовать нельзя на php, вопрос, что ряд задач сильно дешевле сделать другим способом.
Буду рад еслси кто проведет нагрузочное тестирование.
Вы рассылаете спам на сотню читателей с рекламой своего платного продукта, да еще и просите бесплатно оказать вам услуги по тестированию. Почему вас удивляет, что это кому-то не нравится?
как я могу еще доказать то что написал в комментарии, не дав линк на работающий проект?
Вы и дав ссылку на работающий проект доказать не сможете. Потому что кто его знает, PHP у вас там на сервере работает или что-то еще. Доказать можно только предоставив исходники.
А то что кто то видит только спам — не значит что я сказал что то не то и голосование идет за ответ, а не люблю или не люблю(нравиться или не нравиться).
Вы можете придерживаться того, что вы сами придумали, только окружающие не виноваты в том, что вы придумали.
Не "кто-то видит только спам", а "вы сказали что-то не то, поэтому в вашем ответе есть только спам", потому что вопрос о веб-сокетах в PHP тем, что вы написали, доказать нельзя.
То есть что получается. Вы сказали, что кто-то должен заплатить вам деньги, хотя это вы хотите что-то доказать; кто-то должен сделать какие-то действия, которые ничего не докажут; прорекламировали свой платный проект, хотя согласие на получение рекламы здесь вам никто не давал; и без обоснований обвинили широкий круг людей в низких моральных качествах. Далее вы задали вопрос "что не так", а когда получили честный ответ, что это из-за рекламы и некорректной логики, продолжаете говорить "нет, это неправда, вы всё врете".
Во-вторых я не обязан вам предоставлять исходный код. Я хочу что бы молодые ребята не велись на всякие манипуляции в комментариях о PHP и не проверив самостоятельно или посмотрев на проект(мой или чужой) сделали выводы, а также получали опыт.
Каждый сам решает платить или нет, почему вас это волнует. Может кто то посчитает что оплатив вход в проект он сам посмотрит как он работает, проверит работу чата и т.д. И я указал что вход платный потому что бы предупредить и не тратить время на регистрацию если она не пустит в проект без оплаты.
Вы ничего не сделали что бы опровергнуть или доказать что я "обманщик"
Где именно я сказал, что вы обманщик?
Во-вторых я не обязан вам предоставлять исходный код.
Где именно я вас просил предоставить исходный код?
Вы не обязаны его предоставлять, поэтому могли просто не пытаться что-то доказать или опровергнуть. По веб-интерфейсу сервиса доказать или опровергнуть его нельзя, это просто факт, следствие законов логики. Даже если у вас там действительно работает PHP.
не проверив самостоятельно или посмотрев на проект(мой или чужой)
"Посмотреть на проект" означает "посмотреть на исходники". Чьи-то слова "да там точно одно соединение, правда-правда" ничего не доказывают. Может вы просто думаете, что там одно соединение, а работает оно совсем по-другому.
Каждый сам решает платить или нет, почему вас это волнует.
Меня это не волнует. Вы спросили "почему минусы", я дал вам ответ. При этом сам я минус не ставил.
Может кто то посчитает что оплатив вход в проект он сам посмотрит как он работает, проверит работу чата и т.д.
А кто-то посчитает, что молодые ребята не должны тратить деньги на проверку исходного утверждения, потому что его можно проверить совершенно бесплатно. Минусы это и предупреждение для других, что к вашему комментарию стоит относиться с осторожностью.
Давайте я подробнее объясню. Вы написали комментарий как опровержение утверждения про веб-сокеты в PHP. Он его не опровергает, минусами люди выразили свое несогласие с вашей логикой. Также он содержит излишне необоснованные требования для проверки этого утверждения. Минусами люди выразили несогласие и с этим, проверить утверждение можно бесплатно. А также вы пытались это доказать рекламой своего платного сервиса, что вообще-то запрещено правилами. Вот за все это в совокупности каждый человек поставил один минус, и таких людей было несколько.
и за всех посетителей отвечаете
А как вы представляете ответ на вопрос "за что минусы" на сайте, где у каждого пользователя свой аккаунт? Ну можете считать, что у меня написано не "Люди поставили минус за то-то", а "Я бы поставил минус за то-то". Принципиально это ничего не меняет. Просто я вам объяснил, а остальные не хотят. Потому что никто не обязан вам что-то объяснять. Какие выводы сделать из этой информации, решайте сами.
Главная проблема PHP на мой взгляд, это почти нулевая стоимость входа, люди нахватаются, он им все прощает, делают ошибки и считают что в этом проблема языка, а не их и кидаются изучать другой язык.
Вторая проблема PHP — люди не хотят глубоко вникать в него, например недавно столкнулся с человеком который считает что yild есть в phyton и нет в php. А вы знаете, что генераторы появились еще в PHP5.5? Вот статья интересная — nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html
Но он не позволяет одной переменной стать сначало строкой, а потом массивом.С этим ошибок в тех ЯП, где такое возможно, у меня не было связано. Не то, чтобы это было хорошая фича, но вреда по факту тоже не несёт (если не писать божественные функции).
Он не позволяет ошибок проектирования.Забавно регулярно оду типизации Go читать. Видимо, всё от разработчиков, всю жизнь писавших на динамических ЯП. Попробуйте Rust. Или хотя бы Typescript. Go слишком примитивен для каких-то там гарантий компиляции. И он нарочно примитивен.
Можете даже попробовать PHP + Psalm со всеми ошибками.
А мне не очень хочется заниматься выделением/освобождением памятиДа, это убийство производительности в С, но в Rust это происходит полуавтоматически, и за соблюдением правил владения в коде следит анализатор компилятора. Условно говоря, вы можете использовать только умные ссылки и только правильно. Церемоний немного больше и обучения правилам намного больше, чем в Go.
В принципе да, немало низкого уровня у этого улучшенного С, в отличие от Haskell. Там вообще думаешь только о задаче, но в менее привычных условиях.
Поясните подробней?В Go ведь очень распространено приведение типов из-за невыразительности системы типов, она же там почти как в Pascal. По сути всё есть явно и однозначно типизированные переменные и структуры. И под капотом больше, чем даёт синтакис.
В Rust есть например параметризация типов, тип-сумма, перечисления, абстрактные типы.
Про ноду не соглашусь, вот она уж точно в мир иной направляется, с каждым годом встречаю ее все меньше и меньше.
Дотнетеры вот размножаться, уже не один десяток раз встречал предложение переписать на дотнет все.
Яву вот я люблю хоть давненько и не писал на ней. Как раз после явы испытваю страшную боль, что нельзя просто взять соединение из пула и кинуть туда данные, но последнее время боль стала нестерпимой. При этом спринг — хорошая конечно штука, но во первых дикий оверхед, во вторых магия аннотация меня лично просто убивает. JSP чтоль помучать)
Зы а мне нравится роутинг на файлах) я уже разок имел опыт разыскивания аннотаций везде и всюду, а уж какой кайф если кто перепишет поведение аннотации.
… во вторых магия аннотация меня лично просто убивает.
На самом деле, даже для не особо подготовленных спецов по java, это давно уже не магия. Очень много докладов и материалов на эту тематику (например Евгения Борисова, есть стрим где он, в формате лайфкодинга, создавал спринг «на коленке»), которые вдоль и поперек говорят об этой «магии». Было бы желание разобраться.
А вот хоронить php из-за «один процесс на один вызов», пожалуй, всё же не стоит. Демоны на php работают месяцами, если писать их грамотно и не аттачить кучу либ у которых память течет, в чем блин проблема?.. Сокет к демону прикрутить? Да хоть свой колхоз набросать не так уж сложно- нас в свое время эта habr.com/en/post/331462 статья на это сподвигла (спасибо morozovsk кстати ), хоть сторонние инструменты использоват — основной код-то всё равно останется тем же.
Да, go/nodejs более нативны в этом смысле, но у них свои нюансы есть.
Я благодарен php за быстрый вход в тему в 2003 году. Профессионалом на нем не стал — ушел в другие языки. Но того опыта хватило, чтобы сделать свою страницу. Если бы мне тогда попалась java, то я бы стороной обошел web-разработку.
Сейчас я понимаю, что php — отличный язык, который помогает кормить не одну семью. Долгих лет жизни. И, кстати, fb и vk были написаны изначально на php, насколько я помню)
Специально покопался чуть-чуть. Судя по всему, фб и вк сделали траслятор php-> cpp. Язык остался, а среда выполнения — уже иная.
Del
Интересно, рассматривают ли они возможность перехода на PHP8
Хорошие менеджеры обычно умеют вовремя фиксировать убытки и закрывать тупиковые проекты.
Есть, конечно, ReactPHP, Swoole, Amphp, но это по сути костыли, с помощью которых можно попытаться обойти ограничения PHP. Однако это не сам язык, а именно костыли.А что голая нода и го дают работать с вебсокетами из коробки, никаких сторонних пакетов для этого не надо?
Не надо путать реализацию вебсокетов с принципиальной поддержкой персистентных соединений и асинхронности.
или же вообще выбросить php полностью и написать ВЕСЬ проект на конкурирующей технологии
Вот такое обычно плохо заканчивается.
1) Единственная причина почему пхп развивается так, а не иначе — это желание бизнеса, который начинался в гараже и смог выжить — с минимальными усилиями поддерживать свою кодовую базу. Ибо гораздо проще переписать старый проект на php, на Symfony с новой версией php, чем полностью менять стек.
Поэтому, ребята из Symfony и Doctrine просто копируют основную функциональность Spring + Hibernate. Ибо бизнесу на php нужно то же самое, что бизнесу на Java, но на php. Откройте спонсоров Symfony и все станет понятно.
2) Если автор ничего в жизни на php не писал кроме адинок, то значит он херовый кодерок. Открываешь по Москве вакансии на php с ценником 140к и выше, везде хайлоад проекты на php. Естественно, там пайплайны выносят на go, очереди на реббите или кафте, кеши и мапы на редисе, логи на эластике и прочее. Но основная кодовая база на php. И знаешь, как-то работает все и приносит деньги. И даже новые разработчики приходят и продолжают развивать проект без боли.
3) Восьмерка php с её jit — это еще один шаг к тому, чтобы сделать из php java. Почему это хотят сделать? Читаем пункт номер 1.
И пришел к осознанному выводу, что php плох в этом. Гораздо проще заюзать другие технологии.
А вот там, где есть сложная однопоточная бизнес-логика без особой нагрузки — php рулит.
Если у тебя понимание, как у хлебушка, а язык это синтаксический сахар и «асинхронность ибо круто» — иди лучше в другую сферу, программирование не твое.
Дело в том, что добавить го для вебсокетов и других зтаких задач не так уж и сложно. Что собственно я и сделал в своей команде. И почему-то не пришлось никого увольнять. Или ждать.
Программисты с мозгами легко осваивают новые языки, тем более такие простые как go. Более того, каждый второй php-шник уже попробовал сделать helloworld на Go (сужу по своей команде и по опыту проведения собеседований)
Про nodejs я вообще молчу — js в каком-то виде знают все, примеров по вебсокетам в инете полно.
Ждать ничего не надо, попробуйте, это совсем просто.
Про криворукость, хлебушек и прочие неадекватные оскорбления — проигнорирую.
Просто задам один вопрос: если надо будет делать чат службы поддержки на PHP, как вы будете это делать?
Просто задам один вопрос: если надо будет делать чат службы поддержки на PHP, как вы будете это делать?
centrifugo
Сделаю бизнес-логику и API на PHP, сделаю чат-сервер демон на node.js/go/java, который при старте загрузит информацию через API (написанное на php) в контекст и будет гонять все через веб-сокеты, а по окончанию чата сбросит все в базу опять же через апи написанное на PHP.
___
У тебя, конечно, написано, что ты тим-лид и прочее. Но не позорься, удали пост и иди в яндекс-такси потаксуй лучше. Раз банальные бизнес-кейсы, которые уже решены десять раз не знаешь, как сделать.
О чем собственно и статья. Если бы в php встроили асинхронные штуки, то можно было бы обойтись без ноды и го.
В глазах программиста Java это выглядит как дикий костыль, тем более ко всему прочему усложняется поддержка и деплой. А в мире пхп такие уродливые решения — норма.
Просто задам один вопрос: если надо будет делать чат службы поддержки на PHP, как вы будете это делать?Ratchet может быть?
Т.е. по сути php должен был слушать сразу два места: NATS и Websocket и реагировать на них. Все что пришло через вебсокеты, отправлять в NATS, всё что пришло из NATS отпроавлять в вебсокеты. Попутно сохраняя в базе.
Мы нашли библиотеку для NATS, но она делала что-то вроде `$client->wait(1);` типа жди сообщений. Но как при этом еще и сообщения вебсокетов ждать — это вопрос.
Мы конечно придумали адову схему с очередями и кучей демонов. Но потом поняли, что на go это делается элементарно. И поддержка вебсокетов/nats там лучше. И контейнер с гошным демоном весит очень мало (только сам бинарь по сути). Одни плюсы для таких задач.
С тех пор наша команда стала PHP/GO
github.com/repejota/phpnats
$client->subscribe(
'sayhello',
function ($message) {
$message->reply('Reply: Hello, '.$message->getBody().' !!!');
}
);Так что может быть проблема в том что в вашей библиотеке не было нужного функционала или же вы его не нашли?
Но в любом случае, вы выбрали конкретный нишевый пример который у вас, в вашем проекте был. 99% программистов даже не слышали про NATS и он им не нужен
Э-э-э, нет, это так не работает. Даже я со своим нулевым опытом в PHP вижу, что без вызова wait никакой subscribe работать не будет.
Во-первых, общие соображения: кто-то все равно должен "крутить" цикл чтения, и если он внутри библиотеки — то он и окажется "точкой зависания".
Во-вторых, быстрый поиск по репозиторию показывает, что чтение сообщений из сокета в библиотеке именно в этом методе wait и находится.
и в этом случае он не будет блокировать выполнение.
Но даже если бы блокировал — это проблема ПХП или же проблема библиотеки?
Да нет, всё равно будет блокировать. Представьте, что из сокета пришло "MSG" и всё — тогда wait начнёт читать пришедшее сообщение и будет ждать пока придёт основная часть.
Плюс любая запись в сокет блокирующая.
Плюс не вполне понятно в какие моменты времени этот wait(0) нужно дергать, делать это в бесконечном цикле — тоже так себе затея.
Кстати, там на самом деле надо не wait(0) писать, а wait(-1), потому что 0 означает "читать до закрытия сокета". Да и wait(-1) тоже не так как хотелось бы работает...
Но да, это всего лишь одна неудачная библиотека.
\Nats\Connection::setStreamTimeout которая позволяет ставить таймаут на сокет, т.е. получается что receive вылетит по таймауту в этом случае.
Но задача-то заключается в реагировании на сообщения из веб-сокета сразу же, а не между тайм-аутами Nats
Потому что это не точка, а канал между двумя точками.
Почему надо страдать и делать двунаправленный канал. Когда можно поднять два однонаправленных канала?
Какие у нас ограничения на это?
Неблокирующему IO в PHP уже лет 20 минимум. Да, это всего лишь биндинг к select и ко. Можно биндинги к libevent прикрутить. В общем в таких постановках задачи на PHP решаются. Другое дело, что очень многие PHP-разработчики, без навыков, скажем так, разработки на C, за разумное время с приемлемым качеством не смогут разработать что-то вроде шлюза между, например, веб-сокетами, раббитом и попутным хождением в веб-сервис.
Куда бы биндинги не были прикручены, операция ожидания где-то должна быть — не дело скрипту жрать весь процессор без сетевой активности.
Эта операция может быть внутри прикладной библиотеки или снаружи. Если она внутри — то код будет на этом вызове зависать независимо от типа используемых сокетов. А если она снаружи — то API библиотеки неизбежно будет выглядеть сложнее чем у PHP NATS (ну или у библиотеки будет зависимость от какого-нибудь ReactPHP, что также не наблюдается).
Единственная причина почему пхп развивается так, а не иначе — это желание бизнеса
Дико плюсую: недавно был отличный доклад на эту тему на онлайн-митапе.
Восьмерка php с её jit — это еще один шаг к тому, чтобы сделать из php java. Почему это хотят сделать? Читаем пункт номер 1.
Сделать из PHP Java, только хуже. Java в свою очередь сейчас «собирается» из Scala и Kotlin (если смотреть JVM-мирок), только хуже, чем они.
Единственная причина почему пхп развивается так, а не иначе — это желание бизнеса, который начинался в гараже и смог выжить — с минимальными усилиями поддерживать свою кодовую базу.
И всего вышесказанного выходит, что PHP — лучший выбор для legacy проекта, который по «причинам бизнеса» не вариант рефакторить на что-то адекватное.
везде хайлоад проекты на php
Совсем очевидно, что новый проект с уклоном в хайлоад никто в здравом уме не будет делать на PHP. И не потому что язык плохой — а потому что конкурентный асинхронный код всегда будет эффективнее. Нормальная система типов всегда будет давать больше качественных абстракций и (что самое главное) гарантий работоспособности кода.
В других, более молодых, языках нынче тоже много фреймворков и библиотек. Да и нужно то не дофига, а несколько и хороших.
Я бы начал на Go. Многие пробуют Elixir или даже раст, но порог входа выше при неочевидных плюсах...
Дополнительный плюс статической типизации — сложнее накосячить и проще рефакторить.
Я бы начал на Go. Многие пробуют Elixir или даже раст, но порог входа выше при неочевидных плюсах...
В го кооперативная многозадачность, в эликсире — вытесняющая. Но даже не это главное, а отказоусточивость. Чтобы адекватно отреагировать на непредвиденный сбой, в го придется написать тонну кода, а в OTP это решено из коробки.
Плюсы статической типизации — это миф. Сейчас хайпово повторять эту мантру, но никаких доказательств этому нет, и быть не может.
Плюсы статической типизации — это миф. Сейчас хайпово повторять эту мантру, но никаких доказательств этому нет, и быть не может.
Вы должно быть шутите. Строгая статическая типизация — это и есть доказательство работоспособности. А еще оно подкрепляется доказательством корректности системы типов, которое ученые умы закладывают в основы компилятора.
Конечно, никто не дает вам 100% гарантий. Это реальный мир — тут всегда есть погрешности и трейдоффы. Но просто сравните строго типизированный язык с динамически типизированным — и там и там есть типы, просто во втором случае они в голове у автора кода… т.е. грубо говоря — эти знания разработчик не коммитит в проект, а уносит с собой по окончании рабочего дня. Не трудно догадаться, что с точки зрения работодателя это такая себе ситуация и ему хотелось бы, чтобы все знания оставались в проекте.
Нет, я не шучу. Я просто немного понимаю в разработке, а не повторяю за большинством средней руки тезисы.
Строгая статическая типизация — это и есть доказательство работоспособности.
Да-да. 2.0 * π * R как формула для вычисления площади круга сразу же будет завернута компилятором, как только вы укажете, что входной параметр — float.
во втором случае они в голове у автора кода
Да-да. Про типы все слышали, про документацию пока не все.
с точки зрения работодателя это такая себе ситуация
Мне не надо догадываться, я принимаю непосредственное участие в выборе стека.
Про типы все слышали, про документацию пока не все.
Пишем типы в комментах?) Великолепное решение (нет). Если код нельзя читать и понимать без доков, то у меня плохие новости. Я не имею ввиду какую-нибудь опенсорс библиотеку. Я про внутренний проект и документация\типизацию именно внутреннего проекта.
как формула для вычисления площади круга сразу же будет завернута компилятором
Не уверен, что понял вас.
Я просто немного понимаю в разработке, а не повторяю за большинством средней руки тезисы.
:)
Каким большинством? Имеется какая-то статистика? Как минимум не очевидно, что большинство (разработчиков я так понимаю?) пишет на статически типизированных языках. А про тезисы «да-да» лучше умолчать.
Пишем типы в комментах?
Нет.
Если код нельзя читать и понимать без доков, то у меня плохие новости.
В код докера загляните. Да просто в любую библиотеку чуть сложнее лефтпада.
Я не имею ввиду какую-нибудь опенсорс библиотеку. Я про внутренний проект и документация\типизацию именно внутреннего проекта.
Кажется, что у опен сорс проектов своя специфика и там действительно нужно более подробно все документировать. В корпоративной разработке зачастую просто нету столько ресуров. Но повторюсь: чем больше знаний закоммичено непосредственно в проект — тем лучше, и не важно что это: типы, доки.
В корпоративной разработке зачастую просто нету столько ресуров.
Я не пропущу код без внятной документации интерфейса на код ревью.
чем больше знаний закоммичено непосредственно в проект — тем лучше, и не важно что это: типы, доки
Ну а так-то да, с этим никто и не спорит. Просто это совсем не то же самое, с чем вы в эту ветку пришли.
Ну а так-то да, с этим никто и не спорит. Просто это совсем не то же самое, с чем вы в эту ветку пришли.
Эм, у меня там было пару тезисов. Уточните тогда с чем это не стыкуется
Я не пропущу код без внятной документации интерфейса на код ревью.
Ну, окей. Но это ваш личный опыт, применительно к проектам, в которых вы проводите код ревью.
А вот компилятор не пропустит в продакшен код с тайп-еррорами любого проекта, который его использует. И количество таких проектов, скажем так, значительно больше, чем то, что может проревьювить 1 человек.
что вы имеете в виду
Я, как всегда, имею в виду сарказм.
Чтобы компилятор его правильно завернул, нужны типы «длина» и «площадь», и правильное определение функции area (а не выведенный тип, который окажется для такой формулы длиной, и это можно и не заметить и пропустить, в принципе).
Но адепты максимы «типы — это панацея» часто ограничиваются флоатом, потому что флоат — это уже тип, а типы нас спасают от всего, кроме геморроя (ходят слухи, что скоро начнут спасать вообще от всего).
А ваш пример — это ошибка в правильном указании типов. Да, от таких ошибок статические ЯП не защищают…
Наверно это может проверить только вероятностная логика какой-нибудь нейронки: «что-то это не выглядит как платёжные шлюзы, с которыми у меня был опыт». Можно использовать бионейронки и называть это QA.
Плюсы статической типизации переоценены. В последнее время я вижу на хабре прям крестовый поход против динамической типизации причем даже в очень хамских статьях.
Видимо буду писать статью-ответ которая могла бы защитить динамическую типизацию.
Но сразу оговорюсь — я не говорю что одно лучше другого, просто у них своих плюсы и минусы которые раскрываются в разных контекстах и у разных людей.
причем даже в очень хамских статьях
Это скорее непрофессионализм и невежество отдельно взятых коллег. Это такое себе независимо от того, про какую технологию идет речь.
Плюсы статической типизации переоценены
Поделитесь ссылкой если у вас получится объективное сравнение, мне будет очень интересно почитать, особенно с точки зрения сложных (больших) проектов с длительным жизненным циклом (регулярные релизы\рефакторы) или проектов из области критических бизнес-процессов (важно чтобы работало корректно)
Вот тут подробнее: https://habr.com/ru/post/502506/
В общем, мой поинт остается в том, что если Вам реально нужна производительность, то асинхронщина + мультитрединг Вам в руки. А лучше всего они будут работать на тех языках, где это из коробки есть (а не приделано сбоку).
быстрее чем на golang
Ничего не могу комментировать про go, к сожалению.
Вам реально нужна производительность
Производительность бывает разная. Не так уж и редки задачи, где многопоточность её наоборот просадит.
Интересно наблюдать как из года в год всё хоронят PHP. А всё потому что нет его понимания.
Это кстати частая проблема "тим-лидов" приходящих из других ЯП: ожидание, что выработанная картина мира подойдёт везде..
PHP — это не про чаты или real time с gRPC. PHP про бизнес логику. На текущем уровне развития языка, real time лучше оставить для рассчитанных на это ЯП.
Также стоит упомянуть, что на обычном кейсе с множеством запросов в БД — PHP неплохо тягается с упомянутыми автором Go, Java и C#.
Например, по ссылке ниже, можно заметить, что Go идёт только за PHP.
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query&l=zijn99-1r
Исходники и описание окружения в описании.
Я вот только не пойму, почему на более чистом и простом (в смысле синтаксиса) Python эта бизнес логика будет хуже? Или ее будет сложнее написать? При том что в Python async/await отлично работают.
Например, по ссылке ниже, можно заметить, что Go идёт только за PHP.
Тут надо понимать что какой ценой был получен этот результат. И если говорить про БД то с PHP приходится использовать сторонние пулеры для Postgres.
На текущий момент в PHP с сахаром кажется всё хорошо. Но важно не перейти эту тонкую грань, когда сахара слишком много. По моим ощущениям — PHP как раз ходит на этой грани.
Нужна скорость, реальная скорость для обработки, ну скажем картинок, Rust или С в помощь, но при этом кодовая база остается на PHP.
хватит хоронить языки. учитесь их правильно выбирать под ваши задачи.
Да так и делаю часто, смесь технологий. О чем и написал в статье.
Но было бы круче, чтобы php сам умел решать типичные веб-задачи, сам умел общаться с вебсокетами и кафкой одновременно, причем из коробки.
да в других языках это делать удобнее, но нет еще ни одного универсального языка. всякий язык заточен под какие-то задачи. используйте несколько и будет вам счастье.
Если на других языках это делать удобнее, то зачем это делать на том, на котором неудобно? Вы мазохист?
Делать на них может и удобнее, но это надо:
- выбрать что-то конкретное: Node.js (с TypeScript или без?), Java, Kotlin, C#, Go, Python, Ruby, C, C++ — вот какой из них подходит лучше всех для таких задач я не знаю. Как выбрать?
- изучить самому, обучить минимум двух человек в команде и не факт, что они прямо рады будут, что не услышишь "я на PHP пришёл программировать!" или "тогда снимай с меня задачи остальные на месяц — я курсы будут проходить в рабочее время", а в дальнейшем при ротации или росте учитывать это в требованиях.
- время от времени переключаться между синтаксисами и семантиками, что может приводить к идиотским по меркам языка ошибкам. Вот в PHP пустой массив приводится к false, а в JS/TS к true. И у любого JSника возникнет, как минимум, недоумение при виде условия if (items) {},
Увы и ах, как ни ускоряй PHP, но под каждый HTTP-запрос выделяется отдельный процесс — это поведение прибито гвоздями
Это ложь. Удалите пожалуйста свою статью. Вы вводите в заблуждение молодые не окрепшие умы и их детскую психику.
Есть же не только php-fpm
Phpfpm обрабатывает каждый запрос отдельным процессом.
Попробуйте запустите php-fpm с pm.static где будет 1 дочерний процесс. И выполните 2-4 HTTP запроса одновременно. И вы увидите что всё ок и ваше утверждение ложь.
А еще вы можете написать свой веб-сервер на php который будет обрабатывать одновременно >= 2 rps. Можно сделать его на чистом exec и pipeах. И всё это будет работать одновременно. Если нужно покрасивей и побольше контроля, можно взять pcntl. Но если вам нужно шарить данные между http запросами, вы можете использовать pthreads.
Делаем вывод что ничего в php гвоздями не прибито. Кроме того вы можете написать extension как на PHP, так и на C. И это будет очень быстрое решение.
Пожалуйста удалите статью или исправьте недочеты.
Не вводите людей в заблуждение.
Возьмите скрипт, который делает sleep 5 сек, а потом записывает в лог время
$ mkdir tmp && cd tmp
$ echo "<?php exec('php '. __DIR__ . '/worker.php'.' > /dev/null 2>/dev/null &');" > ./server.php
$ echo '<?php sleep(5); file_put_contents(__DIR__."/test.log", date("H:i:s")." -> worker_id =".uniqid()."\n", FILE_APPEND);' > ./worker.php
$ php server.php
Через 5 секунд появится файлик test.log.
Можете запустить из >= 2 терминалов и увидите
$ cat test.log
15:41:27 -> worker_id =5ed648f71c829
15:41:27 -> worker_id =5ed648f71d05e
Код веб сервера будет чуть посложней, но смысл тот же.
UPD: можно использовать встроенный в php web сервер для демонстрации
$ php -S localhost:3111 server.php
И обратитесь одновременно через curl -v localhost:3111
Также увидите что worker_id будет разный.
Для большей очевидности «асинхронности» можно добавить в server.php ответ
$ echo "<?php exec('php '. __DIR__ . '/worker.php'.' > /dev/null 2>/dev/null &'); die('test\n');" > ./server.php
Но ведь ваш server.php создаёт по процессу на каждый запрос!
<?php
$socket = stream_socket_server("tcp://127.0.0.1:3111", $errno, $errstr);
if (!$socket) {
die("$errstr ($errno)\n");
}
$log = __DIR__ . '/test.log';
while ($connect = stream_socket_accept($socket, -1)) {
file_put_contents($log, date('d.m.Y H:i:s').' -> request_id = '.uniqid()."\n", FILE_APPEND);
fwrite($connect, "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\nHELLO");
fclose($connect);
}
fclose($socket);
Я еще раз повторюсь — этот код публикую для ответа на некорректную инфомрацию в статье о том что HTTP запросы можно обрабатывать 1 процессом. Некорректно сравнивать кол-во запросов на процесс, с кол-вом долгих процессов и асинхронностью в php.
А знает ли средний PHP-шник что-нибудь про ReactPHP? Нет!
Тем, кто захочет узнать, посоветую скринкасты, цикл блогпостов или книгу Сергея Жука из Skyeng про основы.
Сергей Жук на каком-то выступлении прямо сказал, что для таких целей зачастую лучше использовать другие языки
Если вы о докладе на митапе ростовского PHP-сообщества, то речь шла о выборе для новых проектов. Вот этот кусок выступления — youtu.be/2TBrGX1-mJY?t=12195
«Если говорить про выбор технологии, то… если у вас новый проект, и стоит вопрос, что выбрать, конечно, не ReactPHP, потому что это сбоку сделано. И даже, наверное, не ноду»
Ниша по сути — это админки со сложной бизнес-логикой (т.е. на Golang такое писать нецелесообразно) и не особо нагруженные сайты. Здесь PHP — лидер.
… и это 90% современного веба
Основная фишка ПХП — это всё же то что на нём достаточно просто программировать и достаточно легко его использовать для решения бизнеса. (мы же помним, что программист должен решать задачи бизнеса, а не программировать на работе ради развлечения? )
Давайте немного отойдем от синтаксиса языка и подумаем про экосистемы.
В данный момент (по моему мнению!), основные крупные экосистемы в ВЕБЕ это: PHP, Python, NodeJs, GO?, Java, .NET, Ruby.
.NET — он напрямую связан с виндовсом и сопутствующими проблемами и плюсами. Фактически полностью отдельный стек, который надо изучать отдельно. Из минусов — не на любой хостинг поставишь. Т.е. требует отдельных серверов. Насколько я знаю — в основном используется в крупных фирмах и корпорациях.
Java — корпорации только, писать с нуля небольшой проект на нём — надо быть очень фанатом.
Ruby — вроде бы его популярность идёт вниз последнее время, но, насколько я знаю, он никогда небыл сильно популярен, могу ошибатся.
GO — вроде бы хайп начинается на его тему, но даже на этом фоне, он нишевый язык, для определённых задач. На нём писать обычные сайты, а не микросервисы — насколько это легко вообще? Есть ли темплейты для хтмла, ORM, и тп из коробки (в любом крупном фреймворке). Язык создан в 2007 году, но за 13 лет он не набрал большого хайпа и я бы не заметил огромной экосистемы для него, в которой можно найти библиотеки для подключения ко всему чему угодно. Писать НЕ хайлоад на GO — насколько удобно?
Python — одновремя была волна хайпа что язык для всего, язык идеален, используйте его везде где только можно. Сейчас волна спала. Из минусов — не везде его можно поставить, насколько я знаю, нет строгой типизации (это даже считается фишкой языка). Из плюсов — есть много библиотек на все случае жизни, есть большое комьюнити, язык стабилен.
NodeJs — по своему язык хорош: Быстрый, есть многие вещи из коробки, много библиотек. Из минусов — слишком молодой, местами достаточно нестабилен, node_modules-hell (слишком много зависимостей), очень много разных библиотек сомнительного качества. Нет строгой типизации и соответствющие проблемы с этим. Промисы добавляют тоже достаточно много проблем — читать бактрейсы выполнение их — то ещё удовольствие.
Огромный плюс — интеграция с react & angular, в частности server side rendering.
Typescript — решает проблему строгой типизации nodejs, но добавляет кучу других проблем. В частности то что часть библиотек используют её, а часть нет. Очень много вариантов синтаксиса, в частности, при изменении конфига — возможно придётся менять все импорты. Вхождение в язык далеко не простое.
PHP — тут я предвзят конечно же .
Из плюсов — стабильность, много библиотек, много серьёзных фреймворков в которых все есть из коробки (Laravel, Yii, Symphony, десятки менее известных), много информации, производительность адекватная для больишнства случаев, относительно легко начинать и найти дешёвых разработчиков. Из минусов — нет промисов, асинхронности, невозможно использовать в других сферах.
Все плюсы и минус конечно субъективны, и я не хочу никого обидеть. Каждый язык которым пользуются — он чем то хорош. В этом месте стоит вспомнить что нет серебрянной пули… Микроскопом так же неудобно забивать гвозди, как и с помощью молотка рассматривать микробы.
.NET Core уже отвязан от Windows и неплохо так дружит с контейнерами.
И насколько это идеологически правильно?
Я не про запускать на сервере, а именно разрабатывать. Есть ли нативные средства разработки?
не пробовал, но предположу, что с использованием JetBrains Rider проблем быть не должно.
Насколько удобно разрабатывать под .NET чисто под маком и под линуксом?
…
Есть ли нативные средства разработки?
JetBrains Rider — вполне зрелая кроссплатформенная IDE для разработки под .NET.
Я не фанат C# но писал для него под маком в Visual Studio Code и тулзами от net core очень уверено и удобно. Т.е. к тулзам и окружению не было никаких претензий.
Что-то про .NET вы написали очень устаревшую информацию. У .NET Core уже третья версия вышла, и скоро выйдет пятая...
Ладно первую версию .NET Core можно было нестабильной считать, но сейчас-то...
Но вы писали что для .NET нужны серверы на винде.
Я писал про то что .NET связан с Микрософтом и сопутствующей экосистемой.
Насколько в нём легко делать вещи linux way? Разрабатывать под маком и линуксом, использовать не виндовс мир решения и тп?
Т.е. можете ли вы работать под .NET вообще никогда нигде не используя виндовс, его компоненты и тп?
Насколько это будет удобно?
Ну нет, вы написали вот так:
Из минусов — не на любой хостинг поставишь. Т.е. требует отдельных серверов.
Если вы писали не о винде, то о каких таких "любых" хостингах, на которые бинарник не скопируешь, в таком случае речь? Неужели вы имели в виду шаред-хостинги на Апаче? Но в таком случае тот же самый минус можно дописать к любому языку кроме PHP.
мы же про web-разработку? где в ней место windows, ее компонентам и т.п.? если подразумевался IIS, то .NET Core приложения прекрасно работают без него. соответственно, никаких выделенных серверов под них не требуется. про дружбу с контейнерами я уже писал выше.
Насколько в нём легко делать вещи linux way?
Что под этим подразумевается здесь?
Тут он, конечно, погорячился — но причина такого ответа вполне понятна. Если у него уже есть винда и настроенная среда разработки — ради чего вообще играться со сменой ОС и всех инструментов?
Но скомпилировать приложение для линукса это же никак не мешает. При желании можно даже, не слезая с винды, отлаживать линукс-версию в докере, говорят что студия это умеет.
А у меня перед глазами несколько команд, которые пишут микросервисы на .NET Core и деплоят их в линуксовых контейнерах в прод. Это они в игрушки играют?
ps: или речь именно про настройку рабочего окружения для разработки? если да, то что мешает для разработки использовать windows? разработчики на PHP же не ставят себе тот линукс, что будет на хостинге.
Delphi забыли!!!
def sign(x): return (x > 0) - (x < 0)not []Да, в Python меньше, чем в PHP, автоматических преобразований типов, но они есть. В остальном же контроль типов в Python отсутствует полностью: тип переданного в подпрограмму параметра можно проконтролировать только вручную; уровень даже не PHP, а JavaScript.
Что касается not, то в семантику языка изначально зашита автоматическая трактовка значений большинства (как минимум) типов как boolean. И такая семантика логических операций — не перегрузка, а ещё один пример типичной слабой типизации а-ля JavaScript (и дополнительный источник ошибок в коде).
Что интересно, и то, и другое присутствует и широко используется в C++. Теперь у C++ слабая типизация?
Показателем силы типизации можно считать как часто строки неявно приводятся к числам или наоборот. Так вот, в Python этого, кажется, вообще не происходит. В отличии от Javascript и PHP.
Слабость типизации определяется не числами и строками, а:
- наличием в языке механизмов автоматического неявного преобразования типов
- отсутствием контроля типов параметров
Так что Python немного выигрывает у PHP в первом пункте и безнадёжно проигрывает во втором.
P.S. Языком с действительно сильной типизацией является Go.
В Си и плюсах можно легко прибавить int8 к int16 и получить невесть что в итоге. От этого столько багов бывает что ужас.
Так что типизация слабая, да. В том же го нужно явно кастовать типы для этого что закрывает большой пласт ошибок.
строгость типизации — это про то, как легко вам как программисту гарантировать, что программа делает то, что надо, и не делает того, что не надо
Вы уже сами себя начинаете превосходить. Я почти уверен, что через пару месяцев наткнусь на ваш комментарий «строгость типизации — это про то, как легко вам как программисту писать код», а через годик — на «строгость типизации — это про то, как вы указываете типы, а кусок железа за вас пишет идеальный доказанно корректный код».
Я в курсе, что в академически-чистых примерах это возможно. Экстраполяция на все случаи жизни портит все впечатление.
Я-то и не воспринимаю. Восторженные неофиты воспринимают.
Я вчера как раз встрял в длинную дискуссию, не пойми зачем, про рекурсию (сейчас поясню, при чем тут это). Ну вот люди смотрят в JS, а потом сразу в хаскель. И пишут фибоначчи на условном эликсире без TCO. Ты им говоришь: чувак, у тебя тут все взорвется на сравнительно больших числах. А они в ответ: нет, вот смотри: [ссылка на то, что TCO не делает код быстрее] и [ссылка на то, что в хаскеле TCO чаще вредит].
Ты сначала офигеваешь, а потом мямлишь невпопад: так хаскель ленив, там в 99% случаев правильный выбор — guarded recursion, а в JS как ни выделывайся — все взорвется, но даже в хаскеле TCO нужен если вычисления жадные, и вот foldl, в отличие от guarded foldr… И тут внезапно выясняется, что твой оппонент даже не понимает, что такое стек и почему оно взрывается.
Зато у нас есть типы (везде есть, от тайпскрипта до аннотаций в питоне — сейчас же это надо, чтобы язык автоматически получил плюсик в карму) и это магическим образом делает наш код неуязвимым.
Просто на маршруте плюсы → хаскель вы уже прошли по подавляющему большинству грабель, от которых типы не спасают (а остальные вам могут никогда и не встретиться из-за сферы задач). И эти грабли, внезапно, гораздо больнее, чем рефакторинг без типов, или передача не того не туда.
Так и тут: мне не нужен помощник, чтобы не передать кортеж туда, где ждут список. Да, после плюсов — это все выглядит волшебной магией. Но не более. Нельзя сказать, что «легко вам как программисту гарантировать, что программа делает то, что надо, и не делает того, что не надо». Увеличивает этот показатель на проценты, пусть десятки процентов у вовсем новичка — да. Но «гарантировать» — это мимо. См. пример про TCO.
мне не нужен помощник, чтобы не передать кортеж туда, где ждут список.
Но он может понадобиться вашему преемнику, чтобы разобраться, кортеж туда передаётся или список.
А, типы в качестве документации? — Да, их ровно для этого и придумали. А документацию придумали, чтобы какой-нибудь записной остряк создал мем про самодокументированный код.
Мой преемник прочитает документацию, а не станет наобум слать абы что, и смотреть на ошибки компилятора.
В качестве гарантированно актуальной и понятной IDE документации в том числе. Не основная, но важная фича.
Ваш преемник зайдёт в вашу документацию, и будет долго гадать, где же тут описание вот этого, одного из тысячи, методов и что за десять параметров в него передаются
понятной IDE документации
Ясно, свидетели секты IDE. IDE нужен только тем, кто не умеет писать код, простите уж, ничего личного, просто опыт.
будет долго гадать, где же тут описание вот этого, одного из тысячи, методов и что за десять параметров в него передаются
Да-да. Я ровно так код и проектирую. Зато типы сразу превратят мою лапшу — в понятные хорошо изолированные три метода с одним параметром.
Ясно.
Те кто раньше писали на RoR, кажется что начинают переходить на Phoenix/Elixir.
Java — для маленьких проектов не плох. Сейчас все равно почти все упаковывается в контейнеры. А у Java в этом плане все отлично. Тотже проект Quarkus. Тулинг просто отличный. IDE поддержка радует. Материалов к изучению много. Много книг и best practices. Да и сама Java пошла семи мильными шагами.
А если обсудить насколько хорош язык с точки зрения бизнеса?
из плюсов:
- бесплатный, не требует лицензий
- не требует дорогих серверов — можно поставить на любой хостинг или виртуалку за 5 долларов в месяц.
- легко найти программистов любого уровня — от начинающих (для простого сайта), до серьёзных которые напишут что угодно.
- а можно вообще не искать программистов, попросить эникейщика поднять вордпресс и на нём сделать сайт. вордпресс поставить на любой хостинг за 20 долларов в год.
- Если брать бизнес покрупнее, то всё равно язык позволяет выполнять 99% задач бизнеса без особых проблем. Есть крупные, стабильные фреймворки на которые можно легко найти разработчиков.
- Обновление языка — достаточно легко, почти нет крупных несовместимых изменений (обновление пхп 5.х до 7.3 проходит почти без проблем)
- язык стабилен, нет страха что через 5 лет потребуется всё переписывать с нуля, так как язык больше не поддерживается.
- язык стабилен, нет страха что через 5 лет придётся искать новых программистов, или что зарплаты на программистов этого языка резко вырастут.
Что ещё бизнесу нужно?
Напомню что бизнес выбирает инструмент который решает его проблему наиболее выгодным для него путём. Сейчас в Европе и США тренд в том, чтобы не иметь свой сервер вообще, а использовать готовые решения с помесячной оплатой. Тот же wordpress.com — берёшь и используешь, даже не надо ставить на свой сервер. И таких сервисов всё больше и больше. И бизнесу уже не важно на чём там написано, главное чтобы сайт работал :)
обновление пхп 5.х до 7.3 проходит почти без проблем
О, это отдельная тема.
Знаю, кто до сих пор продакшн на 4ке держит, а 5.5-5.6 — пруд пруди.
а php 5.5+ легко мигрируется, так что больше вопрос что нужен взять и сделать.
Увы, решают когда пора не программисты, а бизнес.
А про миграцию — это у вас розовые очки.
Чего стоит одна только 5.5->5.6 миграция.
Больше проблем было с миграции на с 5.0 (когда куски были написаны ещё на 4.х даже местами) на 5.3 и выше, из за того что изменились конструкторы (конструктор должен быть всегда вида __construct ) и тп.
Возможно проблемы с миграцией не своего кода, а зависимостей, вот там да, больше проблем может быть.
В частности раньше если не использовался composer, psr и тп и надо обновить не только пхп, но и фактически все зависимости, которые перешли с до namespace версии на использование namespace-ов
habr.com/ru/post/501722
PHP где-то на равных, а где-то обгоняет Go в тестах Techempower.
Ждем PHP8 с JIT чтобы увеличить отрыв :)
PHP из коробки подходит для serverless стеков.
Асинхронность не так сильно развита в языке видимо потому что нет в ней прямой необходимости, все решается за счет асинхронных очередей rabbitmq/amqp/beanstalkd — к тому же это дает из коробки легкий способ добавлять сервера с воркерами. Большинство очередей, поддерживает ретраи из коробки (на go или nodejs, там где треды/корутины встроены в среду, вам придется это ручками писать) + персистентные очереди, если инстанс nodejs/go упадет, вся очередь что была внутри процесса — тоже испарится, а вдруг там была важная логика? Да на nodejs/go можно использовать очереди асинхронные, но тогда в чем отличие?
В последнее время все чаще начал слышать в круге PHP разработчиков о Event sourcing и CQRS (душа радуется), все это позволяет масштабироваться горизонтально, практически не испытывая проблем.
Утечек памяти тоже практически нет, для суппер производительных задач — теперь есть FFI, если что можно производительный код на C/C++/Rust подключить.
Из минусов PHP — он не компилируемый, был опыт написания на ocaml — там была сказка (в этом плане), если код скомпилировался, то ошибка только в логике, никаких опечаток 98% нет, в PHP для этого приходится обкладываться type hint'ами, но это не дает 100% надежности всеравно может прилететь…
Утечек памяти тоже практически нет, для суппер производительных задач — теперь есть FFI, если что можно производительный код на C/C++/Rust подключить.
Всегда несколько смешил подобный аргумент. Если этот подход даёт выигрыш в производительности, перекрывающий оверхед от FFI, то зачем, собственно, писать бизнес-логику на не нативном языке? Это я не только про PHP, но и про Python, и про Ruby, и про JS.
Когда в PHP появятся дженерики, PHP станет полноценной Java, ещё бы от $ избавиться.
Но вот если взглянуть на PHP с точки зрения простого потребителя, то все немного плохо.
У меня дома компьютер на windows и решил я как-то свой пет-проект начать и решил на знакомом мне стеке, на котором я работаю уже несколько лет. Думаю рассказывать про то что найти установочник php под win, то еще приключение, не стоит. К сожалению это не тривиальная задача, но это пол беды.
После установки привычно набираю composer init и composer мне радостно рассказывает про отсутствие ssh сертификатов. Серьезно? Отреагировал на это я довольно сдержанно переходом по ссылке nodejs.org, где есть надпись большими буквами «Download for Windows (x64)», где есть всего две больших зеленых кнопки, причем можно жать любую точно не прогадаешь, инсталятор сделает все сам, и директорию укажет и в PATH пропишется, жми только «Далее» и ставь галки. Да и ssh они как-то смогли решить вопрос. Вот и получается что мои домашние пет-проекты идут на ноде, потому что у PHP все не очень хорошо с инфраструктурой.
Повторюсь мне нужен был только PHP без всяких там (WAMP, MAMP, XAMP и т.д.) и эту проверку PHP не прошел.
После установки привычно набираю composer init и composer мне радостно рассказывает про отсутствие ssh сертификатов.
ssh сертификатов? Это не опечатка? Кажется, кому-то лень кнопку "y" в консоли нажать, а виноват почему-то PHP...
Думаю рассказывать про то что найти установочник php под win, то еще приключение, не стоит. К сожалению это не тривиальная задача
Расскажите. В чем там проблема?
Увы и ах, как ни ускоряй PHP, но под каждый HTTP-запрос выделяется отдельный процесс — это поведение прибито гвоздями.
Если используется подготовленный пул процессов, да еще и с предзагруженными библиотеками, то гвозди превращаются в хорошую архитектуру. В AWS Lambda так и сделано, к примеру. Firebase Functions тоже про «родился-умер». Один процесс, который отвечает за несвязанные друг с другом запросы — вот это прибито гвоздями к недостаткам старых технологий, а сейчас же успешно решается и контейнерами, которые разделяют общее пространство и в целмо микросервисами, когда общий environment лежит рядом, доступный по сокетам, сети или диску. По той же причине и вебсокеты мир не захватили, stateless рулит и REST API, многие раньше даже по вебсокету эмулировали HTTP-протокол ради этого. А теперь, с пришествием HTTP2 это и вовсе не нужно.
Спасибо! Мне как начинающему веб- разработчику очень интересно!
На мой взгляд, няшные phpdoc-аннотации лучше «бездушных уголков», т. к. заметнее на общем фоне кода. Хотя, IDE подсветит всё что угодно…
Одно дело, когда удаляешь синтаксическую конструкцию языка, другое когда комментарий. Некоторым сложно контролировать комментарии так же как полноценные языковые конструкции. Некоторые могут вообще не знать о том, что phpdoc аннотации не только для документирования используются.
А вот вам пример о том как бизнес решает какой язык ему нужен.
Был однажды проект, полностью написанный на язык X и нормально поддерживался, но пришел новый проект менеджен и убеждает директора, что нужно переписать проект с «X» на PHP, аргументировав это тем, что в РФ вышел закон о запрете использования иностранных технологий.
Проект переписали на PHP.
Одни ноют, что в PHP нет асинхронности, другие просто берут и делают https://twitter.com/marcelpociot/status/1268545217562640387
Если собрались в очередной раз хоронить PHP, то делайте это не искажая факты.
Кто поручится, что проект Swoole проживет еще лет 5?
Я бы на это поставил. На нём половина Китая работает. Одни Tencent и Alibaba чего стоят.
Разработчик под nodejs точно знает, что такое async/await и Promise. В деталях.
Ох, если бы...
Короче, писать микросервисы на PHP невыгодно.
Смотря как считать выгоду и какой микро-сервис. Если в микросервисе есть бизнес-логика, то писать её приятней на PHP, чем, например, на golang. Если один разработчик того же уровня на golang обходится вам как три на PHP, то тоже сомнительная выгода. Если у вас остальной код на PHP, тоже может быть не очень. Это не означает, конечно, что тот же golang плох для молотилок данных. Очень и очень хорош.
Ниша по сути — это админки со сложной бизнес-логикой (т.е. на Golang такое писать нецелесообразно) и не особо нагруженные сайты.
Да, такие не особо нагруженные как, например, Авито или Badoo.
PHP — какая ниша у языка и поможет ли PHP8 решить насущные проблемы (спойлер: имхо нет)