Комментарии 78
мне кажется, что минусы статье ставят те, кто прочитал исключительно заголовок
Мне кажется, минусы ставят те, кто уже раз 5 прочитал точно такую же статью в 2023 году.
И еще десяток в 2022.
К тому же, не стоит переживать за корпоративные блоги. Они вполне в состоянии о себе позаботиться.
Как по мановению волшебной палочки -2 вдруг за несколько минут превращается в +5.
Обычная динамика по плюсикам за 1000 просмотров. Никакие рычаги не дёргали.
Вижу ваше имя на хабре и поверьте на слово - обидеть никого точно не хотели. Очень долго думали, как можно перевести "who are the people still using php" не потеряв смысл, но и не добавляя лишней агрессии. Получилось - как получилось.
Да-да, я и говорю, обычная для корпоративного блога динамика. Резко подскакиваем из минуса, а потом снова начинаем плавное снижение.
Вижу ваше имя на хабре
Попробуйте смотреть не на имя, а на комментарий, на который отвечаете. У меня и близко ничего не было про какое-то "обидеть". А было про то, что статья — откровенная халтура. Вот если в программировании есть говнокодеры, то в копирайтинге, соответственно — говнопереводчики. И за такую халтуру им должно быть стыдно.
В этой статье плохо всё, начиная от бессмысленного заголовка. Авторка так и не смогла решить, какую статью она пишет. Как та рабочая лошадь, начав вроде бы про РНР, она сбивается на привычную дорожку, выдавая стандартный блогспам вида "X vs Y в 20хх". По классической же схеме, в которой пережевывается целое ведро воды и нет вообще никакой конкретики или новизны. Я посмотрел на другие ее работы — все в таком же стиле, плюс еще обязательное "10 вещей которые надо знать про Х". Текст ради текста.
Вот казалось бы, кто её за язык тянул, все время сравнивать с нодой? Причем не с позиции практикующего программиста — это было бы как раз понятно, и очень интересно — личные впечатления человека, который с ноды пересел на пхп.
Но ведь нет — у нее про это ни слова, а один копирайтерский бубнёж. Я, кстати, сейчас посмотрел ещё раз — и вот на 100% уверен, что у нее уже была заготовка, "РНР vs Node.JS". Но ее видимо, кто-то надоумил, что этот шлак уже не заходит даже индусам. И она, как Церетелли, быстренько прикрутила Колумбу голову Петра. Вот прямо видна эта склейка, как в фотошопе: все, что идет от первого мемасика — это совершенно другая статья, не имеющая никакого отношения к заявленной теме. Вы говорите, что вы редактор? И я вам должен объяснять все эти элементарные вещи?
Ну и собственно перевод, со всеми этими "свойствами конструктора" и "типами объединения".
Извините, но это очередной шлакоперевод.
Абы було.
но позднее в индустрии программирования акцент сместился в сторону JavaScript
My sweet summer child...
И как этот опыт можно сравнить с моим скромным миром серверных проектов на JS?
По-моему гораздо интереснее кто те люди, которые используют server-side js
Вы еще вот такого не видели :)
A modern, high performance, flexible SMTP server. Haraka is an open source SMTP server written in Node.js which provides extremely high performance
А что с ними? У них вроде все норм: большое развитое коммюнити, инструменты на все случаи жизни.
Как там в node.js с нормальной многопоточностью?
многопоточность определнно есть . что в вашем понимании означает "нормальная"?
Какие задачи, стоящие перед рядовым сервер-сайдом, вы хотите решать нормальной многопоточностью?
ждите от этого же автора через неделю "Кто до сих пор использует С?" и содержание будет в похожем ключе)
Как объясняется на RisingStack, главная причина в его неблокирующемся вводе-выводе и эффективной обработке параллельных подключений
Осталось понять откуда в PHP внезапно проблемы с блокирующим io, когда обычная функция stream_set_blocking превращает любой io в неблокирующий. Хоть чтение с файловой системы, хоть сокеты, хоть что угодно...
При этом наличие файберов в PHP делает не то что ненужным аналог в JS из async/await, но и вообще ставит под сомнение их существование в природе, т.к. JS-ный аналог становится просто неудобным.
Ну оно же так понимаю просто делает чтение из сокета не блокирующим, но тогда его надо руками опрашивать, это же не переход на epoll или просто господи на io_uring?
Ну можно вместо встроенного select просто проверить на eof и попытаться считать, если делать влоб.
С другой стороны в пыхе можно доустановить libev, libevent, ev или libuv, а там уже на выбор, хоть poll, хоть epoll, хоть kqueue, хоть devpoll, хоть evport, хоть ещё что. Накрайняк есть ffi и руками можно допилить нужное. Было бы желание.
Расскажите поподробнее, пожалуйста. Например, нужно отправить 2 http-запроса без блокировки, но не одновременно: сначала первый запрос, затем вернуться что-то повычислять, и отправить второй, а при получении ответов обработать их.
В JS это решается легко через async/await, в GO — тоже через горутины. Есть ли встренный аналог в PHP? Т.е. без установки swoole/amp/reactphp, без расширения parallel, без написания своего event loop на сокетах. Если такого нет, то дальше встает выбор во что вложить усилия: в изучение нового async-фреймворка на PHP, или в изучение нового языка, и по моим наблюдениям новый язык чаще побеждает
Да зачем сразу бежать учить другой язык, если этот не знаете. Для решения Вашего частного случая есть возможность отправки асинхронного запроса в PHP curl_multi_init
В описанном частном случае сразу указано, что запросы отправляются не одновременно. Эти запросы разнесены, т.е. нет возможности отправить их из одной точки разом. Нужно отправить один запрос, не блокироваться в ожидании ответа и делать другую работу (которая не в апи-клиенте расположена), но обработать ответы как можно раньше при их получении
Не знаю как в Go, но в JS async/await не решит этот придуманный сценарий, так как доходя до await выполнение "приостанавливается" и дальше ждет, что вернет вызов. Почему сценарий придуманный? Потому что не могу придумать сценарий, когда мог бы спокойно выполнять какой-то код без полученных данных из внешних источников. Это такой мизерный случай, что в обычной разработке встречается практически никогда
Не надо придумывать абстрактные примеры. Ясно, что PHP не сможет сделать что угодно. Но для своей ниши он подходит очень прекрасно
в JS async/await не решит этот придуманный сценарий, так как доходя до await выполнение "приостанавливается" и дальше ждет, что вернет вызов
Это касается только асинхронной функции, в которой находится апи-вызов. А вот основной тред не блокируется и в нем можно продолжать работать.
не могу придумать сценарий, когда мог бы спокойно выполнять какой-то код без полученных данных из внешних источников
- Мы не всегда получаем, иногда только отправляем и позже лишь хотим убедиться, что запрос ушел без ошибок и не упал. Это не какая-то редкая/экзотическая операция.
- Когда получаем данные, то далеко не всегда знаем в одной точке все запросы, которые нам надо сделать в течение всего жизненного цикла. И тут PHP не дает удобного способа сделать эти вызовы из разных мест, сохранив асинхронность.
Эти моменты и пытаются решить асинк-фреймворки
не могу придумать сценарий
Просто представьте себе вебсокет сервер, который в цикле обрабатывает запросы множества пользователей.
Я об этом сценарии задумался, когда пытался понять, где можно использовать асинхронные запросы в mysqli
Не знаю как в Go, но в JS async/await не решит этот придуманный сценарий, так как доходя до await выполнение "приостанавливается" и дальше ждет, что вернет вызов.
Это не так. await лишь делегирует задачу "наверх", т.е. это другая форма записи yield. Фактически альтернатива выглядела бы так:
// JS
let response = await request('...');
// PHP
yield from $process = request('...');
$response = $process->getReturn();
// PHP (или так, если верхний обработчик
// умеет сам разворачивать вложенные
// генераторы и возвращать результат через ->send(...))
$response = yield request('...');Что фактически может быть в PHP упрощено в сторону:
// PHP
$response = request('...');
// где внутренности request
while (!feof($stream)) {
$body .= fread($stream, 1024);
Fiber::getCurrent() && Fiber::suspend();
}Это не решает описанную выше задачу
// JS
let response = await request('...');В этой строке мы "стоим" и ждем, что вернет нам request, а не продолжаем дальше выполнять код. А постановка задачи именно такая - отправили запрос и что-то продолжаем делать, пока выполняется запрос
А что это за конструкция?
// PHP
yield from $process = request('...');Не припомню такую в PHP. Если дадите ссылку на доку, буду премного благодарен
https://www.php.net/manual/en/language.generators.syntax.php#control-structures.yield.from
Про сами генераторы — лучше начать тут https://www.php.net/manual/en/language.generators.overview.php
А ещё подкину статью с Хабра — https://habr.com/ru/companies/oleg-bunin/articles/487258/
Кто использует PHP?
Да любой, кому нужен просто сайт, а таких большинство. И что он выберет, или выберет тот, кого он наймет для разработки? Конечно PHP! Это бюджетно, любой шаред подерживает пхп, VPS не нужен. Это легко, просто установи WP (или другую CMS). Это выгодно – разработчиков пхп найдешь везде, для доработки проекта.
Я вам больше скажу, даже не просто сайт вполне себе переваривается PHP
Да и не только сайт, если что!@greevex на вас не хватает! :)
преимущественно из-за его ассоциирования с устаревшими проектами WordPress
Преимущественно из-за петабайтов говнокода на нем написанном. У меня однажды была задача портировать код из ПХП в шарп и такого ада я не видал ни до, ни после. Причем, я смотрел на современный ПХП - вполне себе нормальный язык, позволяющий писать вполне нормальный, современный код, но, похоже вокруг него уже сложилась особая культура программирования, суть которой в отсутствии какой-либо культуры программирования вообще.
На мой взгляд проблема PHP в том, что порог вхождения не высокий, из-за чего полно всяких недопрограммистов ваяющих на коленке множество говнокода.
Оставлю истории из серии "бабка рассказала".
Одна компания контейнеризировала приложения и хотел заехать в кубер. Но контейнеры с пхп как то криво работали и ничего не получалось - по итогу переписали все сервисы на Go и закопали этот язык.
Вторая история. Одна компания смогла перевести все сервисы в докер и даже успешно запустила в кубере, при этом путь пакета до php-fpm проходил через несколько nginx (да и тот самый, который стоит перед самими php). Все работает прекрасно, все все устраивает... Нет фронетендеры хотят nodejs и другие хипстерские вещи и так пхп стал своего рода бэкендом с нотками фронтенда и иногда случается такая неразбериха + поиск кто должен исправлять багу на фронте, которая вроде как и на пыхе, но при этом часть на nodejs.
Согласен с комментариями по критике SEO и тп. Кликбейтное название - это не то что желают пользователи. Итог простой, есть язык, который используют многие компании - кто готов вкинуть средств на развитие, тогда будет хорошо. Если в разработку не будут вливать средств + слабое сообщество, то какой бы ни был супер язык- он умрёт.
Слушайте, но это правда какие-то истории от бабки. Мы упаковали пхп в контейнер на раз, даже не знаю что тут может не получиться, собственно.
фронетендеры хотят nodejs
С каких пор фронтендеры командуют бэкендерам, на чём делать бэк ? Бэкендеры же не командуют фронтендерам, что выбрать, vue, angular или rect.
Последние десять лет, исключая время ковида, регулярно посещал International PHP Conference в Берлине. Помню первые презентации Композера, ренессанс 7 версии, стенды JetBrains, полные залы, горы мерча и призы. В этом году было аж два спонсора, около 300 человек, из которых подавляющему большинству за 30. Чувак из Zend сокрушался снижению популярности. Вероятно, и среди ваших коллег есть те кто со стека съехал?
Забавно, что всё это нам рассказывает человек, так и не перешедший с JavaScript на TypeScript (ах, какое счастье было, когда в моей конторе этот переезд произошёл...)
PHP постепенно умирает, потому что развивается. Это парадокс, но это так. Порог вхождения в новые версии языка стремительно повышается, а вот преимуществ относительно других популярных языков, в общем-то, и нет.
Не повышается от слова совсем. Да, он начал чаще поправлять программиста, если тот совсем уж начинает говнякать, типа $a = ''; $a['id'] = 1; — но это повысит порог разве что для совсем уж дебила.
Умирает потому что перестал быть модным, потому что окрепли жизнеспособные альтернативы, и в силу традиционной репутации.
Приведу свой пример. Начинал с php, сейчас уже больше 7 лет на C#. Заходил посмотреть ради интереса что там появилось с 8 версии, вроде как даже типизацию обещали. Зашёл, ужаснулся, вышел. php как был монстром Франкенштейна в плане синтаксиса, так и остался.
Эээ. Вы, вроде бы, хотели рассказать про повышенный порог вхождения?
Это оно и есть. Если бы я сейчас с C# перекатывался обратно на php, это бы заняло некоторое время. Усложнённый несогласованный синтаксис - одна из причин.
В каком смысле усложненный? Можно пример?
Тайп хинты опциональны, они ничего не усложняют.
Мне кажется, вы немного запутались в своей аргументации. Давайте я вам напомню:
Порог вхождения в новые версии языка стремительно повышается
Можете привести пример такого повышения?
Насчёт согласованности синтаксиса. Вот я так и не могу понять, в каком формате принято именовать функции/переменные: camelCase или snake_case?
Ни в каком. Единого стандарта нет, есть только локальные, под конкретный проект или корпоративные.
Ну вот это, думаю, и подразумевалось под несогласованностью синтаксиса. В коробочных библиотеках то в любом случае camelCase, и он будет пролазить.
А в каких-то распространённых языках есть строгое требование к виду имён переменных? Так, чтобы компилятор/интерпретатор выдавал ошибку.
Ну как минимум в Go и Ruby. Только там не то что бы "компилятор упадёт"… Скажем так, он может упасть при определённых обстоятельствах, т.к. от именования зависит вообще всё.
Go допускает и camelCase, и PascalCase, и snake_case. Ruby резервирует PascalCase для констант, оставляя для переменных camelCase и snake_case. Строгих требований нет ни там, ни там, только стайлгайды.
Go допускает и camelCase, и PascalCase, и snake_case.
И вы хотите сказать, что вообще ничего не изменится, если все ExampleVariable заменить на exampleVariable? А вот судя по этой ссылочке на туториал, кажется, это совсем не так: https://go.dev/tour/basics/3
Про руби вы тоже ответили: Язык явно диктует как именовать переменные/константы и от этого самого именования полностью зависит поведение языка.
Ок. Какие-то ограничения эти языки накладывают (хотя, на мой взгляд, привязывать свойства переменных к регистру символов — не лучшее решение создателей языка).
Но остаётся выбор между camelCase и snake_case, между PascalCase и SCREAMING_SNAKE_CASE. Это будем считать несогласованностью синтаксиса или как?
Вопрос был, цитата:
А в каких-то распространённых языках есть строгое требование к виду имён переменных?
Я ответил: Да, в каких-то языках есть строгое требование к виду имён переменных. Даже привёл пример современных языков, где такие ограничения есть, т.к. в зависимости от того как оно выглядит — меняет свою семантику и поведение.
Так, чтобы компилятор/интерпретатор выдавал ошибку.
Ну такое делать было бы очень опрометчиво. Но негласные (а где-то и явно прописанные) договорённости обычно есть и соблюдаются. В ниже упомянутом Ruby, JS. На других я не так много кода видел, но вроде как в Python, Java, C# тоже пишут в одном стиле.
Мне кажется, вы путаете сам язык и userland код. Язык не регламентирует такие вещи, и не может отвечать за то, как на нем пишут.
Под несогласованностью синтаксиса РНР обычно подразумевают разнобой в именовании и порядке параметров в стандартных функциях.
Ну вообще-то, есть PSR который регламентирует, как надо, и оно принято сообществом. а так, cAlLMyAWESOMEmethod() можно в любом ЯП написать, это не проблема ЯП.
Расскажу про свой опыт.
Мы в основном используем nodeJS.
Но PHP используем:
1) всякие отчеты из аналитики, это проще на PHP взять из Postgres данные и отобразить их в табличкой виде.
2) Работа со всякими API где надо сделать post запрос, причем на PHP больше всяких примеров от сервисов, чем на nodeJS.
3) Генерация картинок на лету, на PHP намного лучше библиотеки
4) Всякие примитивные скрипты, допустим вернуть место на диске
Работа со всякими API где надо сделать post запрос, причем на PHP больше всяких примеров от сервисов, чем на nodeJS.
Что-то я не понял, вы по примерам кодите что ли? Какая разница, каким языком запросы отправлять? Равно как и принимать их.
Обычно так. Есть сервис, не особо популярный, там есть библиотека работы с ним на PHP или готовый скрипт.
То есть там нужно, не только выполнить POST/GET, но реализовать работу с токенами с ключами, сделать авторизацию, которая бывает разная.
Иногда плохо документирована, но есть пример кода и переводить его в nodejs как-то не очень и хочется.
Пример Одноклассники, вот как там ситуация выглядит
https://apiok.ru/dev/examples/php
Плюс PHP проще контролировать если кривая библиотека.
То есть мы закидываем скрипт в папку и он выполняется раз в сутки и дополнительно пишет время исполнения в файл. Который независимо проверяется.
То есть не может быть утечки, не может быть кучу процессов nodejS и так далее.
Почему PHP?
Понадобилось тут питоновский скрипт запустить на сервере (через вебсервер) - убил кучу времени, но так и не понял как это делается легко и естественно
Nginx или Apache с PHP настроить - 5 минут
С PHP как серверным языком (сайты) работать удобней всего даже сейчас, несмотря на его неудобства
Мой хороший друг раньше был PHP разработчиком, но со временем в PHP разочаровался.
Каждый год такие статьи вижу, только все больше воды в них становится. Вообще ничего нового не узнал
фронтенд-составляющая веб-среды так или иначе работает именно на JS. В этой сфере я провела последние десять лет.
Кто они – те люди, которые до сих пор используют PHP? Почему они это делают?
Из года в год однотипные статьи о "php умирает", но всегда неизменно в них одно - о умирании php рассуждают люди, работавшие с ним десять лет назад, а иногда и вовсе никогда не работавшие. Тут автор хоть про современный php знает, уже хорошо.
PHP рождён чтобы умирать
Всегда ору с таких статей и комментаторов "PHP скоро умрет")) 15 лет умирает и умирает, все никак не умрет)
Кто до сих пор использует PHP?