Comments 126
ПХП хороший и приятный язык, восьмая версия действительно быстрая, работает на уровне Го. При этом ужасный го очень любят в русском айти, а пхп считается "зашкваром".
Жаль, конечно, что хорошие разработчики уходят из пхп в раст, из-за этого недавно пришлось фонд ПХП создавать: https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/
Точнее, мне то не жаль, я на пхп уже давно не пишу, в отличии от раста, но пхп до сих пор люблю и иногда пользуюсь.
А чем ужасен GO?
Из PHP уходят в Rust? Извините, но это откуда такая информация? Когда читал, чуть чаем не подавился.
В моем комментарии есть ссылка, ее можно открыть.
Один Никита Попов ушел - экстраполировали на всех PHP-шников?
Обычные средне-статистические PHP-ники не уходят в Rust, по крайней мере массово. Поверю, что куда-нибудь в NodeJS, но не Rust.
Так на сколько знаю Никите просто нравится Rust и он уже давно контрибьютит и туда. Просто человеку захотелось развития как личности, Rust совсем другие принципы нежели PHP, Java, Go или NodeJS
Gordon01 21.12.2021 в 10:32
Жаль, конечно, что хорошие разработчики уходят из пхп в раст
Hett 22.12.2021 в 08:51
Обычные средне-статистические PHP-ники не уходят в Rust
Спасибо, это именно то, что я изначально написал. Попробуйте читать внимательно и до конца то, на что отвечаете.
Еще предлагаю подумать, в чем разница между ПХП-разработчиками и разработчиками ПХП.
Это вам ещё повезло! Я подавился
Работает на уровне go? Go в десятки раз производительнее, так как он компилируемый и легковесный
Попробуйте найти пруф, очень удивитесь
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
Тут php медленнее Go в шесть раз.
Эта ссылка тут уже была, зачем ее повторять.
Вам тоже предлагаю внимательно и до конца читать то, на что отвечаете:
Go в десятки раз производительнее
Где-то была статья по сравнению производительности. Там Go оказывался быстрее, чем PHP. Это при использовании в Go типа int32. Но при int64 производительность практически сравнивалась. По всей видимости, на время так влияют затраты на передачу лишних байт.
Оказывается, в PHP нет типа int32. Наверное, просто в нем не было необходимости. В JS есть оба типа, и выбор происходит интерпретатором в зависимости от значения. Это как бы и плюс, но может быть и минусом, если окажется, что нужно постоянно переключать типы.
В общем случае, в реальных выскоуровневых приложениях очень маловероятно, что такая особенность сыграет заметную роль в производительности.
Производительности Go, JS, PHP примерно одинаковы, но PHP и его экосистема гораздо более развиты применительно к вебу, бэкенду. Да и сам по себе язык обладает большими возможностями в целом. В большинстве случаев проще и быстрее создавать качественные приложения именно на нем.
восьмая версия действительно быстрая, работает на уровне Го.
Судя по бэнчмаркам PHP медленее Go в шесть раз.
Это довольно специфичные тесты по обработке больших объемов данных. С практической точки зрения более интересен тест фреймворков, и Symfony, один из наиболее богатых возможностями, является лидером среди аналогов, он быстрее Spring из Java. В Go нет подобных аналогов.
Да и вообще, вверху списка много разных фреймворков на PHP, на Go их мало, они значительно медленнее и уступают по функционалу.
Поиграться в PyCharm с питоном на каких-то небольших скриптах, парсерах и прочих штуках - возможно. Запустить в бой продакшен реди приложение на Python - удачи =)
Я помню, как после какого-то говно-курса по Питону на тостере разрывали вопросы типа. Вот я на Djnago сделал бложик, как мне его захостить. Им там им про DigitalOcean и VPN, nginx, gunicorn и гайды про настройку виртуальных окружений, а там просто "ничего не понятно, помогите" =)
Также и разработка полноценного питон приложения энтерпайз уровня - редко обходится без каких-то аннотационных либ, что вводят строгую типизацию.
Просто детишки насмотрся всяких инфоцыган, которые им впаривают курсы по 100к, а потом учат Python без перспективы на нем работу найти.
Так что Python что-то там откусывает у PHP только в роликах инфоцыган, реальность другая.
__
Про GO - согласен.
Я PHP люблю за вот это
Можно на лету сгененрировать PHP файл по некотрым правилам(Ну например что он поддерживает некий интерфейс.
сделать include и тут же выполнить на лету.
$newmodule_php =genereate_and_save(...arg)
require_once('./connect/Idbcommon.php');//Интерфейс что должен поддерживать newmodule_php
include_once(SYS_BASE_PATH . "некий путь/" . $newmodule_php . ".php");
$t = new $newmodule_php(...arg);
if ($t instanceof Idbcommon)...Выполняем только что на лету сделанную логику и это классноЭто дает возможность типа саморазвиваться платформе ,что Вы пишите...на других языках так же сделать ещё тот головняк.
Но мне в нем не нравится жесткая привязка к пути VM php типа /usr/local/php
Даже если я компилирую его с другим путем /home/shop/php (во первых это тоже хардкодно) во вторый все расширения и дополнения всё равно ищут путь /usr/local/php
если в java /home/user/java8/bin/java код запустить /home/user/java17/bin/java код /home/user/java6/bin/java код
Так же в node
для php экспериментов и т.д надо поднимать докер ..ибо основную среду PHP разработки можно испорить.
Не самая лучшая идея. Генерировать код на лету, в зависимости от каких-то внешних данных и исполнять его — прямой путь к уязвимостям типа log4j
Не обязательно генерировать в зависимости от внешних данных. Это могут быть зависимости от конфига, от наличия определенных пакетов в вендоре (автоматический бриджинг). Кодогенерация генерирует более оптимальные для исполнения структуры (можно почитать например про роутиниг симфони, который генерирует огромную регулярку по факту в кэш, супероптимизированную)
Можно не сохранять в файл:
$class = new class implements SomeInterface {
public function hello(string $name): string
{
return sprintf('Hello, %s!', $name);
}
};
echo (new $class())->hello('World');Но мне в нем не нравится жесткая привязка к пути VM php типа /usr/local/php
В любом исполняемом скрипте можно лего получить полный путь до используемого интерпретатора
https://www.php.net/manual/en/reserved.constants.php
см. PHP_BINARY
Вообще не понял к чему Вы это...
Мне не нравится хардкодный путь...я бы хотел его запускать откуда хочу... типа /home/shop/php и запускать его низкоприоритетным пользователем.(который вообще не видит /usr /bin и т.д )
ещё бы я хотел иметь кучу версий для экспериментов /home/shop/php8 /home/shop/php7.2 /home/shop/php7.4 и т.д
Задать этот путь можно только скомпилировав из исходников в файле config...и я так делал...но все расширения типа mysqli пытаютя стать в /usr/local/php и т.д ...а я бы хотел чтоб они ложились в home/shop/phpX или туда куда мне нужно(может это и можно дикими усилиями как-то добится...но овчинка думаю не стоит выделки...ибо есть докер)
C java и node таких проблем нет....И можно например постепенно переползать на новые версии java(имея их сколько угодно в домашней папке) и изучать новые фичи
А, я понял о чем вы. Но снова не понял. PHP вполне себе успешно запускается после распаковки из зип архива, никогда не было проблем с расширениями. достаточно положить .so файлы в правильное место (в ext). На той же убунте легко поставить несолько версий пых параллельно, после чего тот же непривилигерованный пользователь может их вызывать по типу php7, php8, php81 и тд.
который вообще не видит /usr /bin и т.д
Эти папки видят все пользователи, даже бесправные, это системные папки и они прописаны в PATH. можно любому пользователю прописать любой PATH.
В общем, нет никаких хардкодных путей в самой пыхе. Они могут быть в том способе установки и настройки пыхи, которым вы пользуютесь, но не в пыхе. У меня на компе пыха лежит в C:/Tools/PHP{74,80,81}, в PATH прописана 81, но при необходимости я могу рукам вызвать любую нужную мне версию (или например в шторм прописать как интерпретатор). и весь запущенный код этой пыхой работает именно с этой версией пыхи
Видимо автор выше имел в виду что у вас будет проект работать полноценно, но к примеру UserRepository будет юзать 7.2 вместо 8.1, в теории такие кейсы могут быть и это действительно сложно реализуемо, но php довольно неплохо поддерживает обратную совместимость даже между мажорными версиями, вплоть до того что в 7.2 при отключении strict mode можно спокойно выполнять код, написанный на 5.3 или 5.6, получая в логи warnings иногда, но сам код будет вполне себе работать до тех пор пока не обновишь
Так работать не будет. Что в в джаве, что в ноде, что в пыхе интерпретатор\вм у вас один конкретный и (в случае пыхи) каким вы индекс файл запускаете - тем интерпретатором все и обработается, т.к. по сути все остальное - это цепочка инклудов\реквайров из него. Да, там есть обратная совместимость, но такого что вот эти файлы исполняются таким рантаймом, а такие - другим - такое я не видел ни в одной экосистеме. Такое можно сделать запуская отдельный код через экзеки, но это какие то уже странные подходы
Разные версии php легко ставятся из стороннего репозитария, например, ondrej/php. Версия по умолчанию переключается с помощью update-alternatives. Ничто не мешает постепенно переползать на новые версии.
То, что Вы расказываете не соответствует моему опыту...Я нача "щупать" php с 7.4 Тогда в репозитории Centos 7(я работаю с Centos-redhat направлением) его не было...я сбилдил из исходников...становился в аккурат в хардкодную папку...можно юыло сбилдить(указав в конфиге ) в другую...но расширения не цеплялись к нему.
Такая же фигня с php 8
Любой язык с препроцессором умеет генерировать код. Да и в джаве с котлином полно генераторов бойлерплейта, а инлай имплементация без костылей реализуется.
Даже если я компилирую его с другим путем /home/shop/php (во первых это тоже хардкодно) во вторый все расширения и дополнения всё равно ищут путь /usr/local/php
Подозреваю что вы эту кошку ещё не научились правильно готовить ;)
Разумеется, в PHP работа со строками сделана не так круто, как в Python
А можно хоть каких-то подробностей, чем конкретно работа со строками в Python лучше? Я питона не знаю, но по многим отзывам и личному опыту сложилось мнение, что уж с текстом в php все просто отлично.
конструкция switch/case не насколько богата, как в том же Swift
А как же новая конструкция match?
Я тут недавно немного с Java поработал и понял как же удобно когда у тебя есть стандартный String ты ставишь точку и IDE в подсказке сразу выдает все эти .toUpperCase .toLowerCase .startsWith .contins и т.д. и тебе не надо мучительно вспомнить все эти дурацкие strstr strpos str_contains str_starts_with prereggreppos %) которые за каким-то фигом еще и названы по разным принципам, где-то подчеркивание, где-то слитно.
В общем видно что в процессе разработки тут был такой разброд и шатания, а теперь обратная совместимость играет.
В Python не спец, но то что видел там удобно сделано типа string[5:10] - можно выбрать кусок строки, и прочие вариации string[5:] string[:10] чтоб отрезать с разных сторон. Там в общем куча всякого такого сахара, хотя его тоже еще в голове держать надо, в то время как в той же Java подскажет IDE и по названию функции очевидно что произойдет со строкой )
Этой статьи оказалось мало? Всего 11 дней прошло. Складывается впечатление, что автор не свое мнение высказывает, а выполняет какую-то разнарядку по пиару PHP.
Так а по сути/содержанию есть претензии? Ну не обсуждать же в самом деле ваш внутренний стандарт "на одинадцатый день пока рано" и тем более ваши впечатления, которые субъективны.
и тем более ваши впечатления, которые субъективны.
Вы так пишите, будто чьи-то впечатления могут быть объективны))
Мнение автора, что PHP это хороший язык для изучения в 2022 году также субъективно. По этому мне непонятна ваша претензия - каждый здесь высказывает свое субьективное мнение. Отписывался в его прошлой теме восхваляющей пхп, и отпишу здесь - все мои знакомые пхпшники собираются уходить с этого языка.
Мнение автора, что PHP это хороший язык для изучения в 2022 году также субъективно.
Автор написал статью, в которой его мнение подкреплено довольно увесистыми фактами в пользу оного и с чем уже можно спорить/обсуждать.
По этому мне непонятна ваша претензия - каждый здесь высказывает свое субьективное мнение.
Претензия была у вас. У меня лишь вопрос, есть ли что по существу статьи.
все мои знакомые пхпшники собираются уходить с этого языка.
Ок, а у меня 25см в холодной воде.
его мнение подкреплено довольно увесистыми фактами
Допустим, а мое:
все мои знакомые пхпшники собираются уходить с этого языка.
Вы увесистым не считаете, а говорите что это:
Ок, а у меня 25см в холодной воде.
Но, представляете, я тоже самое могу сказать и по поводу аргументов автора. Что, например, зарплаты в php ниже топовых (по зарплатам) языков не на 15-25%, как говорит автор, а намного больше:
Допустим, а мое: "все мои знакомые пхпшники собираются уходить с этого языка." Вы увесистым не считаете а говорите что это: "Ок, а у меня 25см в холодной воде"
Именно, мой "факт" по достоверности такой-же как и ваш, не находите?
Что, например, зарплаты в php ниже топовых (по зарплатам) языков не на 15-25%, как говорит автор, а намного больше
У вашей картинки мало того, что выборка зачем-то по мидлам так и еще никаких выходных данных. Далеко ходить не нужно - https://habr.com/ru/article/511700/
Картинка автора, к слову, расходится с его же словами:
Если мы берем в целом middle разработчика на PHP (Symfony) и middle Java (Spring) разработчика, то разница в зарплате будет незначительной.
На картинке для PHP - 100 тысяч, для Java - 132 тысячи. На следующей ступеньке 165 и 200 тысяч соответственно. Не очень-то похоже на "незначительную разницу".
Вопрос в рынке и том, как строится подобная статистика, конкретно у меня сейчас в Минске на позиции миддла в пхп зарплата сопоставима с миддлами на той же джаве, но я не сижу при этом на саппорте в легаси проекте под древней как испражнения мамонта версией джавы, а учавствую в разработке новых проектов, по зп если быть точным - миддл на джаве зарабатывает в среднем долларов на 100-150 больше, тут скорее вопрос дальнейшего роста, у пхпшников потолок ниже, согласен, но и будем честны - до сумм в $5к+ далеко не каждый джавист сможет дорасти, должно повезти с навыками, софт скиллами, конторой и прочими вещами, которые далеко не всегда от тебя зависят
Почему бы и нет? ПХП — отличный язык, проверенный временем и нормально развивающийся. Да, у него есть недостатки, но в большинстве случаев, для бека это до сих пор лучший выбор из всего.
Поэтому я уже давно с недоумением смотрю на людей, которые говорят, что PHP медленный. Когда-то это было так, но сейчас он обходит своих конкурентов по производительности.
Быстрый php по сравнению с другими интерпретируемыми языками, но он в разы(иногда на порядки) медленнее популярных компилируемых языков, в т.ч. упомянутой Java.
Ну и раз уж заговорили о скорости, можно упомянуть, что в PHP практически не подходит для разработки приложений работающих асинхронно(с неблокирующими потоками). В языке для этого есть полторы библиотеки, и они не совместимы со всей остальной экосистемой PHP, включая многие функции стандартной библиотеки, и даже тем же xdebug
Как бы программисты не рассуждали о том, что на определенном языке невозможно сделать хороший проект, а на другом можно, все же ключевой показатель – это Time-To-Market. И вот тут PHP – король!
Очень общее утверждение, которое ничем не подкреплено
либо сайты построенные на конструкторах (wix/shopify/bigcommerce/tilda и так далее). Кстати, все эти конструкторы написаны на PHP и оцениваются в миллиарды долларов. Неплохо так для синего слоника!
Как минимум Wix не написан на PHP, насколько я знаю. Раз уж упомянуто в статье, хотелось бы ссылок на источник информации. Ну и многие компании, которые "оцениваются в миллиарды долларов", обычно осознают, что на таких масштабах с PHP пора съезжать на что-то более быстрое/удобное.
Есть весь туллинг, который нужен современному разработчику
Базовый тулинг есть, я бы сказал. С поддержкой современными платформами всё похуже, как и с библиотеками для более современного тулинга(например, трейсинг, или мониторинг из Прометея какой)
Все внимание CORE PHP разработчиков и PHP-комьюнити сосредоточено на том, чтобы сделать PHP максимально удобным и эффективным инструментом написания бекенда. Именно поэтому современные PHP-фреймворки и библиотеки оказываются лучше
Для полной картины, очень не хватает информации о том, сколько активных core contributors у PHP, а сколько у Java / Kotlin / C# etc. :)
Именно поэтому современные PHP-фреймворки и библиотеки оказываются лучше, чем аналоги на других языках программирования.
Это тоже ничем не подкреплено. Экосистема библиотек в C# / kotlin / Java / JS значительно богаче таковой у PHP. Это быстро становится понятно сравнением популярных клиентов/фреймворков/интеграций etc.
Конечно, именно поэтому PHP нельзя назвать в полной мере языком общего назначения, ибо для других целей, кроме бека его редко используют. Но вы уже должны для себя решить: вам нужна призрачная универсальность или максимальная эффективность?
Максимальная эффективность по каким метрикам?
По поводу ситуации на рынке - согласен, что найти работу джуном на PHP сильно проще, и порог входа ниже(хотя и на эту точку зрения есть критические взгляды).
Со сложными проектами на PHP ситуация уже похуже чем с другими языками, имхо.
Быстрый php по сравнению с другими интерпретируемыми языками, но он в разы(иногда на порядки) медленнее популярных компилируемых языков, в т.ч. упомянутой Java.
Да нет там никаких порядков. ПХП 8 работает со скоростью го.
Если нужная максимальная скорость — то С, С++ или Раст.
Да нет там никаких порядков. ПХП 8 работает со скоростью го.
Автор статьи за бенчмарк взял mandelbrot. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html - разница в 6 раз. .
Если нужная максимальная скорость — то С, С++ или Раст.
Судя по бенчмарку Вы JS тут забыли
Ну и многие компании, которые "оцениваются в миллиарды долларов", обычно осознают, что на таких масштабах с PHP пора съезжать на что-то более быстрое/удобное.
А можно список этих "многих"? У меня для вас есть обратный:
Yahoo
Facebook
Wikipedia
Flickr
Digg
SourceForge
VK и другие проекты VK Group
mailchimp
Etsy
Zynga
Slack
Baidu
imgur
Avito
Badoo
Boxberry
Яндекс Еда
Кинопоиск
Blablacar
iStock
Freepic
Сбер (Здоровье, облако, мб ещё что-то)
ManyChat
SuperJob
Ultimate Guitar
Skyeng
Райффайзен
Юла
Lamoda
МТС
Delivery Club
Альфа Банк
Перекрёсток
Делимобиль
Wildberries
DNS
Связной
Ubisoft
Tutu
Belka Car
Lyft
Whatsapp
Tesla
Upwork
Space-X
А конкретно можно?
Ясно-понятно, начали с "компаний" а в итоге только VK и "судим только по слухам". Вы вообще в курсе что там kphp?
А где гарантия того, что те, кто работает "в наше время" умнее "команды Дурова"? Какой хороший разработчик в здравом уме сегодня пойдет в ВК?
Как вы себе представляете ситуацию, когда разработчик, опыт которого позволяет разобраться в легаси монолите и аккуратно его переписать, придет в ВК добавлять API для выгрузки переписок тащмайору и разработки ВК.Такси?
Тут не пхп виноват, а факт того, что нормальный разработчик не пойдет работать в ВК.
Не представляю, как VK стал бы таким крутым проектом, если бы там был плохой код.
Плохой код, значит его сложно поддерживать, вносить в него изменения, создавать новый функционал, будет много ошибок. Как мы видим, в ВК очень много разного функций, и они хорошо работают на протяжении долгого времени. Следовательно, код довольно хороший. Простая логика ).
они хорошо работают на протяжении долгого времени
Неужто вы не помните постоянные красные тост-месседжи на любой чих? А взломы страниц и накрутки голосов практически на потоке? При том, что сверхестественного количества функционала ВК не предоставляет, а тем, что есть — ресурс обрастал все эти десятки лет. Да и тот же KPHP — как логичное продолжение идеи, что даже с деньгами проще было ускорить PHP, чем масштабировать и рефакторить кодобазу.
А можно список этих "многих"? У меня для вас есть обратный:
Серьёзно? Половина компаний из вашего списка свои продукты переписывает с php на go/kotlin/kphp/hack/hhvm.
Навскидку - Facebook(hhvm+другие языки), Wikipedia(hhvm), VK(kphp), Mailchimp(go), в Etsy бэк не только на php, судя по вакансиям, Slack(Hack), Avito(go), Badoo(go и др.), ЯЕда(c++ как минимум), Lamoda(go, kotlin), Delivery Club(go), и пр.
Альфа банк, Space-X и пр.
Space-X на php это интересно конечно. Вы не путаете основной продукт с каким-нибудь бложиком компании?
Половина компаний из вашего списка свои продукты переписывает с php на go/kotlin/kphp/hack/hhvm.
Да, наверняка половина - я вам на слово так и быть поверю (нет)
Facebook(hhvm+другие языки), VK(kphp), Slack(Hack)
То есть таки php (видоизмененный)
Wikipedia(hhvm)
Не правда - php
Avito(go)
Опять не правда, бэк почти весь на php (даже микросервисы некоторые на php делают)
Badoo(go как минимум)
Как минимум не правда
Mailchimp(go)
Опять же... какие-то микросервисы, бэк на php
ЯЕда(c++ как минимум)
Бэк на c++? А че уж не на асме - быстро ведь. Но бэк у них на симфони, судя по этим вакансиям 1 2
Lamoda(go, kotlin)
И php вы забыли опять
Delivery Club(go)
Space-X на php это интересно конечно. Вы не путаете основной продукт с каким-нибудь бложиком компании?
Нет, я предполагаю использование php в основном там, где ему и место - на web backend, это вы похоже что на c++ и котлине хотите все писать.
То есть таки php (видоизмененный)
То есть таки иной язык, частично похожий, но не обратно-совместимый с PHP, и выбранный из-за наличия легаси.
По поводу остальных примеров - вы наличием языка PHP в стеке компаний доказываете, что переписывания не происходит. В отдельном случаях прямо указывая, что на ПХП существует в основном легаси код.
Ваши выводы не следуют из предпосылок, поэтому мне тут нечего ответить более :)
это вы похоже что на c++ и котлине хотите все писать.
А с каких пор котлин, с экосистемой богаче чем у PHP, и на который уже даже документация спринга переведена, не подходит для бэкенда?)
Котлин вообще неудобное странное УГ. Лучше бы уж тогда вы привели в пример Java, но версии до 7 включительно очень многословны, а на 8 просто сложно перейти тому, кто начинал с 5 или 6. PHP развивается более плавно, на мой взгляд.
По поводу остальных примеров - вы наличием языка PHP в стеке компаний доказываете, что переписывания не происходит.
Нет, этими примерами я доказываю то, что вы намеренно вводите в заблуждение меня и остальных не указывая его. Непонятно только зачем вы это делаете, когда информация эта легко проверяема.
В отдельном случаях прямо указывая, что на ПХП существует в основном легаси код.
Вы опять приписываете мне то, что я не писал и даже не подразумевал. Это в вашем выдуманном мире весь php код в энтерпрайзе - сплошное "легаси", которое все переписывают денно и нощно. В реальном мире PHP это лидер для написания web приложений для любых сфер, самый быстрый из интерпретируемых языков с огромной кодовой базой.
А с каких пор котлин, с экосистемой богаче чем у PHP
А кто вам сказал, что у Котлин экосистема богаче php?
Нет, этими примерами я доказываю то, что вы намеренно вводите в заблуждение меня и остальных не указывая его. Непонятно только зачем вы это делаете, когда информация эта легко проверяема.
Я не указываю его, потому что в ситуации, когда происходит переписывание кода с php на другие языки, одним из языков в стеке будет php, неужели это действительно так неочевидно?
А кто вам сказал, что у Котлин экосистема богаче php?
А вам важно "кто мне сказал", или всё-таки экосистема?) Пока что у меня есть ощущение, что поставить галочку о победе в споре, и таким образом защитить полюбившуюся технологию вам важнее, чем реальные ответы на вопросы.
Будем сравнивать экосистемы PHP vs Java+Kotlin?)
Можем начать, например, с количества фреймвокров поддерживающих actor model, или как я выше писал, клиентами open telemetry, или даже клиентами к Кафке, из популярного :)
Ну и в целом есть много областей где Kotlin/Java как языки представляют сильно больше возможностей и юзкейсов для развития экосистемы, за счёт чего расширяют её, и позволяют решать более широкий класс задач(взять ту же асинхронность)
Асинхронного выполнения как такового нет, верно, есть корутины и промисы, которыми если честно, никто особо в реальных проектах не пользуется, да оно и не надо как правило в сфере применения языка. На крайний случай все что надо выполнить когда-нибудь можно запихать в асинхронную очередь и пусть хоть 100 тасков выполняется асинхронно в фоне в отрыве от скрипта, в основном так и делают и этого более чем достаточно
В каких случаях прям настолько заморачиватсья со скоростью именно исполнения надо, что это становится критичным? Масштабы фейсбука может, но в реальности упор будет скорее всего в субд. Да и проекты типа optane вполне позволяют добиться минимума оверхэда по времени исполнения непосрердственно кода.
А кто целевая аудитория статьи? Кого убеждаем?
Мета использует Hack все же, не PHP.
Ито многие внутренние сервисы пилятся на других языках. Сейчас тенденция двигаться в сторону Rust.
Я бы ещё порекомендовал выучить в 2022 году Ruby с фреймворком Ruby on Rails, а ещё, Cofee Script и, на всякий пожарный, Action Script. Потом можно будет открыть Некромант-Студио и на собеседовании отдельным пунктом просить написать скрипт на Perl.
По бенчмарку Symfony на Swoole веб-сервере быстрее аналога Spring из Java - https://www.techempower.com/benchmarks/. Ну и судя по статье - https://www.kode-krunch.com/2021/12/trying-out-php-after-7-years.html, превосходит его по удобству использования и быстроте разработки.
По своему опыту знаю, PHP очень гибкий, быстрый, удобный, его можно использовать практически для чего угодно. Наиболее развита сейчас, конечно, сфера применения в вэбе, бэкенде мобильных приложений. Возможно, Symfony, лучшее, что есть сейчас в своем роде.
Часто незнающие люди говорят, что вот, столько всякого плохого кода написано на PHP, и значит это плохой язык. Но они путают причину и следствие. PHP в свое время набрал огромную популярность, как раз потому, что на нем можно было проще и быстрее всего создавать проекты. Мало кто знает, но у всеми известного Битрикса была так же версия на C#, но она не обрела такой популярности, и код там еще хуже, и поддерживать его еще сложнее. То есть, PHP, как раз, помог в этом случае всем.
его можно использовать практически для чего угодно
Его можно использовать только для web backend приложений. Причем короткоживущими.
Если делать долгоживущие приложения типа демона, то без хорошего понимания как устроен PHP внутри столкнешься с проблемами в виде утечки памяти и прочих сюрпризов.
Так же на нем не рекомендуется писать многопоточные приложения и приложения которые работают с сокетами (да, я в курсе про мегакостыли).
GUI приложения на PHP не пишут.
Для всего этого есть более подходящие инсрументы.
GUI приложения на PHP не пишут.
Но ведь обычные веб-сайты — это и есть GUI-приложения.
Да, но им нужен браузер в роли тонкого клиента. Хотя с современным JavaScript клиент значительно потолстел став более умным. На котором можно даже закодить бизнес логику которую он отработает без хождения на сервер.
PHP это боль, возведённая в куб. К языку претензий нет. Но нет ни одной задачи, которую бы PHP решал лучше, чем например .NET, с другой стороны есть огромное число задач, которые .NET решает лучше, или PHP в принципе не способен их решать без прокладок и костылей на C/Go/etc. О чём говорить, у PHP до сих пор нет собственного веб-сервера. До сих пор. Ему нужны прокладки в виде PHP-FPM, RR, Swoole, Supervisor. Он сам по себе не в состоянии даже тупо запуститься. :)
Но нет ни одной задачи, которую бы PHP решал лучше, чем например .NET, с другой стороны есть огромное число задач, которые .NET решает лучше, или PHP в принципе не способен их решать без прокладок и костылей на C/Go/etc.
Как мило, вы сравниваете мягкое с теплым, платформу и язык. Даже если взять C# - это компилируемый ЯП, когда PHP интерпретируемый. Про "костыли" это вы хорошо тоже отметили, бред опять же, на Си сам php и написан как и практически все его модули, на Go есть конечно какие-то микросервисы, но что примечательно, никому и в голову не взбредет писать модуль или микросервис для php на том же C#.
О чём говорить, у PHP до сих пор нет собственного веб-сервера. До сих пор. Ему нужны прокладки в виде PHP-FPM, RR, Swoole, Supervisor. Он сам по себе не в состоянии даже тупо запуститься. :)
Очевидно, что вы совсем не понимаете о чем пишете, вот вам встроеный веб-сервер:
php -S 127.0.0.1:8000 app.phpPHP FPM который вы называете "прокладкой" это тоже один из модулей php, для которого никто не пишет свой веб-сервер т.к. есть Nginx, Apache и др.
Про php -S вы это серьёзно? А зачем тогда "есть Nginx, Apache и др."? Я не очень понимаю вашу логику :)
По поводу "никому в голову не взбредёт", опыт такой есть, именно написание микросервисов на .NET, и именно для проектов на PHP.
Ну опять же, я сделал наверное достаточно провокационное заявление. Что есть задачи, которые, например, тот же .NET решает лучше чем PHP, а есть задачи, которые PHP просто не способен решать, но решаются на .NET. А вот наоборот, задач, которые можно решать лучше на PHP, чем на .NET, я не знаю. Это не вопрос чьё кунфу лучше или хуже. Вполне себе практический.
Пока считаю, что минусы, которые мне насыпали, обусловлены исключительно эмоциями. Опять дескать кто-то набрасывает на наш любимый язык, но это вовсе не так. Мои суждения могут быть ошибочны, хотелось бы послушать контраргументы, а не холиворить попусту.
Про php -S вы это серьёзно? А зачем тогда "есть Nginx, Apache и др."? Я не очень понимаю вашу логику :)
Это было опровержение ваших слов про то, что в php нет веб-сервера, никто конечно не будет это использовать в продакшене т.к. есть тот же PHP FPM. И никто не будет писать веб-сервер для php т.к. как я писал выше есть Nginx и другие.
По поводу "никому в голову не взбредёт", опыт такой есть, именно написание микросервисов на .NET, и именно для проектов на PHP.
Ну ктож вам запретит велосипедостроение, я говорю про энтерпрайз решения, а там если микросервис то скорей всего Go, если модуль - Си или набирающий обороты Rust. На C# вероятнее всего будет писать какой-нибудь горе-интегратор, зашедший в проект с php и не имея в штате специалистов нужного профиля, но это лишь предположение.
Ну опять же, я сделал наверное достаточно провокационное заявление. Что есть задачи, которые, например, тот же .NET решает лучше чем PHP, а есть задачи, которые PHP просто не способен решать, но решаются на .NET. А вот наоборот, задач, которые можно решать лучше на PHP, чем на .NET, я не знаю. Это не вопрос чьё кунфу лучше или хуже. Вполне себе практический.
Во-первых, озвучьте пожалуйста задачу, которую PHP не способен решить, а .NET способен, т.к. судя по вашим прошлым комментариям ваши познания в php и его инфраструктуре у вас на уровне IT менеджера среднего звена. Ну и во-вторых, если мы берем абстрактную задачу с метрикой "кто быстрее" то очевидно, что компилируемый язык как C# сделает это быстрее интерпретируемого PHP (но это не точно), ну и опять же, если нужна производительность никто не пойдет делать это на .NET и возьмет тот же Rust.
Пока считаю, что минусы, которые мне насыпали, обусловлены исключительно эмоциями. Опять дескать кто-то набрасывает на наш любимый язык, но это вовсе не так. Мои суждения могут быть ошибочны, хотелось бы послушать контраргументы, а не холиворить попусту.
Минусы вам насыпали за накидывание на вентилятор без аргументов и полное незнание инфраструктуры php, ну и конечно, сравнение компилируемого и интерпретируемого языков это моветон.
И никто не будет писать веб-сервер для php т.к. как я писал выше есть Nginx и другие.
Это и значит, что в php нет своего веб-сервера. Значит для запуска веб-приложения в продакшене нужно что-то ещё. И это не очень хорошо, как показывает практика.
Продолжая сравнение с .NET, веб-приложение содержит в себе полноценный веб-сервер, как часть самого приложения. Более того, оно может работать в режиме прокси, ощутимо не уступая в производительности nginx-у.
На C# вероятнее всего будет писать какой-нибудь горе-интегратор, зашедший в проект с php и не имея в штате специалистов нужного профиля, но это лишь предположение.
Это неправильное предположение. Не понял, на чём оно базируется. Я часто сталкивался с утверждениями, что PHP в энтерпрайзе не место. И не согласен с этим.
Во-первых, озвучьте пожалуйста задачу, которую PHP не способен решить, а .NET способен
Например, gRPC Server, без прокладок на Go никак, и в режиме бесконечного полнодуплексного бесконечного стриминга -- нужны очень серьёзные приседания и высокие скилы. Т.е. оно как-то решается, но плохо.
Тож самое касается WebSocket.
Поддержка OpenTelemetry, в глубочайшей альфе и по сути всё делать надо руками, никакой поддержки прозрачной трассировки. Даже метрики негде хранить, кроме как прикручивать какой-нибудь Redis, а это уже влияние, недопустимое для счётчиков производительности.
Асинхронные IO операции, без удержания рабочих процессов и потоков. Тут всё плохо. Есть конечно перспективные fibers, а также различные реализации promise, но это всё весьма внушительные приседания. В .NET всё асинхронно, по умолчанию, из коробки, порой разработчики даже не задумываются об этом, оно просто работает.
Разработка игр, мобильных приложений, десктопных приложений, веб-приложений, работающих в браузере -- нет, от слова совсем.
ну и опять же, если нужна производительность никто не пойдет делать это на .NET и возьмет тот же Rust.
Какое-то очередное заблуждение. При чём ультимативное, "все...", "никто..", ну да, ну да. Не понятно на чём основано.
сравнение компилируемого и интерпретируемого языков это моветон.
Погодите. Каюсь конечно, формат похож на вброс. Но всё исключительно по теме. Вопрос очень простой. Если на PHP нет ни одной задачи, которую бы он решал лучше, быстрее или оптимальнее чем на том же .NET, и отвечая риторически на вопрос топика, стоит ли учить PHP? Я не берусь утверждать, а присоединяюсь, но с дополнительными аргументами.
Это не камень в огород PHP, я пытаюсь разобраться. Может потому что, на PHP проектов много, пол интернета на нём? Да, согласен. Но если вот эту часть отбросить и посмотреть взглядом инженера. Зачем?
Это и значит, что в php нет своего веб-сервера. Значит для запуска веб-приложения в продакшене нужно что-то ещё. И это не очень хорошо, как показывает практика.
Что в этом плохого? Какая практика, ваша?
Продолжая сравнение с .NET, веб-приложение содержит в себе полноценный веб-сервер, как часть самого приложения. Более того, оно может работать в режиме прокси, ощутимо не уступая в производительности nginx-у.
Веб-сервер как часть самого приложения это минус, как это масштабировать? То есть в каждую ноду с приложением мне тащить кроме него самого еще и веб сервер? Страшно представить, как до сих пор живут без своего веб сервера perl, node.js, go и прочие.
Это неправильное предположение. Не понял, на чём оно базируется.
Базируется оно на том, что я до сих пор не видел ничего хоть отдаленно претендующего на энтерпрайз решение где в качестве микросервиса/модуля для php используется .NET(C#). У вас есть что-то чтоб переубедить?
Например, gRPC Server, без прокладок на Go никак, и в режиме бесконечного полнодуплексного бесконечного стриминга -- нужны очень серьёзные приседания и высокие скилы. Т.е. оно как-то решается, но плохо.
Тож самое касается WebSocket.
Полным полно
Поддержка OpenTelemetry, в глубочайшей альфе и по сути всё делать надо руками, никакой поддержки прозрачной трассировки. Даже метрики негде хранить, кроме как прикручивать какой-нибудь Redis, а это уже влияние, недопустимое для счётчиков производительности.
Ну не в "глубокой альфе" а в бете, особенно учитывая то, что платформе всего несколько лет и это "непрофильная" для php задача.
Асинхронные IO операции, без удержания рабочих процессов и потоков. Тут всё плохо.
Все там нормально с этим, особенно в последние годы.
Разработка игр, мобильных приложений, десктопных приложений, веб-приложений, работающих в браузере -- нет, от слова совсем.
Вот вы пишете такую чушь а потом удивляетесь, откуда минусы. Игры, мобильные приложения... напомню, что php разрабатывался и продолжает разрабатываться в первую очередь как язык для веб приложений.
Какое-то очередное заблуждение. При чём ультимативное, "все...", "никто..", ну да, ну да. Не понятно на чём основано.
Основано на опыте. Ну и как писал выше - разубедите меня, покажите проекты где с php бок о бок работает хоть с чем-то на .NET.
Если на PHP нет ни одной задачи, которую бы он решал лучше, быстрее или оптимальнее чем на том же .NET, и отвечая риторически на вопрос топика, стоит ли учить PHP?
Учитывая то, что PHP это в первую очередь разработка под WEB - конечно стоит. И очевидно, что решает задачи не хуже .NET, т.к. на данный момент в сфере бэкенд фреймворков он занимает лидирующие позиции, в отличии от .NET доля которого несоизмеримо мала.
Но если вот эту часть отбросить и посмотреть взглядом инженера. Зачем?
Низкий порог вхождения, тонны учебного материала, огромная кодовая база, язык развивается в правильном направлении
Я вот давно задавался вопросом, а почему из PHP никто не отдаёт файлы, статику? Это максимально перекладывается на внешний веб-сервер, или внешние микро-сервисы. Не понимал, пока не увидел это in action. Насколько это больно. В то же время, в .NET он статику сам отдаёт, и делает это не хуже nginx-а. Т.е. он способен абсолютно всё, все 100% трафика пропускать через себя, и статику и проксировать запросы, быть API-гейтом, и выступать в одном лице и бек-ендом, хостить внутри себя фоновые задачи, держать входящие и исходящие подключения. Одно приложение может сразу реализовывать REST, gRPC, WebSocket, GraphQL, SOAP, проприетарные TCP/IP соедниния, агрегировать логи, метрики, трассировку, быть многокональным продьюсером и консьюмером сразу и в кафку и в реббит и в натс, -- да, всё это сразу вместе, в одном приложении. Без каких-либо проблем. Главное чтоб хватило сетевых ресурсов :)
Вот собственно, я почему и задаюсь вопросом. Я вижу как с этим всем больно, буквально на каждом шагу в PHP. Да, всё решается, всегда есть какой-нибудь супервизор, или модуль, или процесс на C или Go, который как-то это вывозит. Но какой ценой! Вот что меня тревожит.
Я вот давно задавался вопросом, а почему из PHP никто не отдаёт файлы, статику? Это максимально перекладывается на внешний веб-сервер, или внешние микро-сервисы.
Попробуйте задаться другим вопросом. Зачем из PHP отдавать статику?
Вот собственно, я почему и задаюсь вопросом. Я вижу как с этим всем больно, буквально на каждом шагу в PHP.
В чем боль то? Или это что-то ваше личное на уровне ощущений и поэтому вы это не можете описать?
хочу снимать метрики обращений к статике точно таким же образом, как и к любым другим ендпоинтам -- единый код, единый подход, единая точка наблюдения
хочу рулить отдачей контента программно, в одном месте, а не размазывать по конфигам nginx-а
хочу иметь возможность управлять доступом к статике программно, смотреть на юзера и решать, отдавать статику или нет, точно таким же образом, как к любому другому ендпоинту -- единый код, единое место
хочу иметь возможность генерировать статику на лету, программно определять как именно, и где хранить, как отдавать
хочу иметь возможность хранить статику как удобно, а пути делать любыми, такими как нужно бизнесу, программно
хочу иметь возможность легко и безболезненно менять логику размещения статики, сегодня на диске, завтра в S3, без каких-либо ковыряний конфигурации серверов
Вот собрал я образ с приложением, и ему ничего больше не нужно, он просто работает. С PHP пока так не получается. Приседаний выше крыши.
И, если быть честным, "зачем отдавать PHP статику", а почему бы и нет? Но нет. Понятно, что удобно всегда дать простой ответ: "да вам это не нужно" :)
хочу снимать метрики обращений к статике точно таким же образом, как и к любым другим ендпоинтам -- единый код, единый подход, единая точка наблюдения
А это и так одна точка наблюдения - логи Nginx, что для статики, что для динамики. А если вы хоть сколько-либо претендуете на хайлоад то ваша статика живет на CDN.
хочу рулить отдачей контента программно, в одном месте, а не размазывать по конфигам nginx-а
Что такое "рулить отдачей контента программно"? Конфиг Nginx это не программно? Нужно обоснование, что конкретно вы хотите и какие цели преследуете, а не просто "хочу".
хочу иметь возможность управлять доступом к статике программно, смотреть на юзера и решать, отдавать статику или нет, точно таким же образом, как к любому другому ендпоинту -- единый код, единое место
Nginx + Secure link module
хочу иметь возможность генерировать статику на лету, программно определять как именно, и где хранить, как отдавать
Ну генерируйте на PHP, в чем проблема?
хочу иметь возможность хранить статику как удобно, а пути делать любыми, такими как нужно бизнесу, программно
Rewrite rules
хочу иметь возможность легко и безболезненно менять логику размещения статики, сегодня на диске, завтра в S3, без каких-либо ковыряний конфигурации серверов
Ради бога, деплой конфига того же nginx прям из приложения
Вот собрал я образ с приложением, и ему ничего больше не нужно, он просто работает. С PHP пока так не получается. Приседаний выше крыши.
Ничего страшного, это нормально, имея познания PHP и его инфраструктуры на уровне джуна все кажется сложным, с опытом все прийдет
И, если быть честным, "зачем отдавать PHP статику", а почему бы и нет? Но нет. Понятно, что удобно всегда дать простой ответ: "да вам это не нужно" :)
Для любой задачи должно быть обоснование, а не просто "хочу"
А это и так одна точка наблюдения - логи Nginx, что для статики, что для динамики. А если вы хоть сколько-либо претендуете на хайлоад то ваша статика живет на CDN.
NGinx как точка конкретно Nginx, т.е. промежуточного узла наблюдения -- да, но не того, что приходит в приложение. Возможности наблюдения крайне ограничены. Он регистрирует запрос на URL, но не знает что в нём, что это.
GET user/123/service/44/info
GET user/333/service/55/info
Для nginx это совершенно разные запросы, которые нельзя консолидировать.
Приложение знает, что это запрос одного и того же метода, но с разными параметрами.
Разница между уровнем и детализации наблюдений -- разная. Это крайне очевидно.
Что такое "рулить отдачей контента программно"? Конфиг Nginx это не программно? Нужно обоснование, что конкретно вы хотите и какие цели преследуете, а не просто "хочу".
Это то и значит. Может вы всё остальное приложение в nginx перенесёте? Или что значит "хочу"? )) Значит применять логику при отдаче контента.
Nginx + Secure link module
Во-первых, возможности крайне ограничены. И придётся подстраиваться. Во-вторых, это костыли. В-третьих. В .NET не нужно ни того, ни другого, ни каких-либо ещё костылей и прокладок. Всё можно делать в одном месте, используя единый механизм для всего, а не городить огород. И реализовывать любую логику, а не заставлять бизнес подстраиваться под возможности secure link.
Ну генерируйте на PHP, в чем проблема?
Генерирование на лету, проблема в том, что файлы начинают отдаваться из PHP, а это уже проблема.
Например, запрос GET /avatar должен отдавать аватар картинку текущего пользователя. Приложение отдаст её или из кеша, или сгенерирует (допустим виде уменьшенной фотки) и положит в кеш. Без всяких костылей и прокладок.
Rewrite rules
GET /avatar должен отдавать изображение текущего пользователя.
Покажите rewrite правило. Авторизация определяется либо зашифрованной кукой, либо зашифрованным токеном в заголовке.
GET /product/123/banner -- отдаём баннер товара, какой именно зависит от региона, правил, да и параметров самого пользователя
Я прекрасно понимаю, что если приложение не может эффективно отдавать статику, то решается по-другому. Сначала отдаётся линк на статику, потом по линку статика. Но иных вариантов и нет. Просто потому что иначе просто нельзя.
Я не говорю о том, что задачи вообще не решаются. Решаются и весьма эффективно. Но способ решения обусловлен исключительно ограничениями.
Другими словами. Вам не нужно ходить на природу, ведь есть телевизор и National Geographic. Это хоть какой-то выход для человека с ограниченными возможностями.
GET user/123/service/44/info
GET user/333/service/55/infoДля nginx это совершенно разные запросы, которые нельзя консолидировать.
Приложение знает, что это запрос одного и того же метода, но с разными параметрами.
Разница между уровнем и детализации наблюдений -- разная. Это крайне очевидно.
Вы много написали, но не указали самого главного - проблему, собственно из-за этого все что выше лишено смысла.
Это то и значит. Может вы всё остальное приложение в nginx перенесёте? Или что значит "хочу"? )) Значит применять логику при отдаче контента.
Тоже самое, опять читаю это как "хочу" т.к. не раскрыта проблема.
Во-первых, возможности крайне ограничены. И придётся подстраиваться.
Ограничены для чего? Для описаной вами задачи - достаточно.
Во-вторых, это костыли.
Я понял, у вас везде где что-то незнакомое - "костыли". Это модуль для Nginx от самого Nginx(F5). Я так понимаю, что вам там в .NET запихали все и сразу, нужно это или не нужно не спрашивают. Практически во всех хоть сколько-либо серьезных приложения/сервисах для Linux (и не только) используется модульный подход, т.е. при необходимости определенного функционала вы подключаете модуль/библиотеку, а не тащите все в рантайм, чтоб оно расходовало ресурсы зазря.
Генерирование на лету, проблема в том, что файлы начинают отдаваться из PHP, а это уже проблема.
Вижу 2 слова "проблема", но как и выше нет самой проблемы.
Приложение отдаст её или из кеша, или сгенерирует (допустим виде уменьшенной фотки) и положит в кеш. Без всяких костылей и прокладок.
Приложению вообще не нужно ничего ложить самому в кеш, фотка будет там уже после первого запроса. Вот как-то так:
location ~ /avatar/.+\.(png|jpe?g)$ {
try_files $uri @app;
}Без лишнего оверхеда запросами в приложение - прямиком из Nginx.
GET /avatar должен отдавать изображение текущего пользователя.
Покажите rewrite правило. Авторизация определяется либо зашифрованной кукой, либо зашифрованным токеном в заголовке.
location = /avatar {
set_decode_base32 $session $cookie_auth;
set_decrypt_session $id $session;
if ($id = '') {
return 404;
}
try_files $id /avatar.php?id=$id;
}GET /product/123/banner -- отдаём баннер товара, какой именно зависит от региона, правил, да и параметров самого пользователя
Все в томже духе, задача простая и довольно распространенная, если вы думаете, что эффективно с этим справится только .NET - у меня для вас плохие новости :)
Другими словами. Вам не нужно ходить на природу, ведь есть телевизор и National Geographic. Это хоть какой-то выход для человека с ограниченными возможностями.
Ваше невежество можно понять, вы видимо долго и безвылазно сидите на .NET и даже не пытаетесь вникнуть как оно там в других окружениях, а тут еще на конфах бравые докладчики рассказывают что "там" все криво, через костыли и велосипеды а у нас православно и круто.
Вы много написали, но не указали самого главного - проблему, собственно из-за этого все что выше лишено смысла.
"А вы точно разработчик?"
В приложении есть методы, один и тот же метод обрабатывает запрос:
GET /some/{some-id}/some-other/{some-other-id}
some-id и some-other-id -- разные, но метод один, и приложение знает что это один метод, и метрики успешных, ошибочных и т.д. запросов собирает для одного метода, не важно это запрос на файл, или АПИ
Nginx ничего этого не знает, с разными параметрами это будут совершенно разные URL для него. Он не может собрать статистику хитов, ошибок, гистограмму выполнения и т.д. по методу.
На nginx эта задача не выполнима. Это конкретная задача, которая в боевом окружении крайне важна для наблюдаемости и траблшутинга.
Я так понимаю, что вам там в .NET запихали все и сразу, нужно это или не нужно не спрашивают. Практически во всех хоть сколько-либо серьезных приложения/сервисах для Linux (и не только) используется модульный подход, т.е. при необходимости определенного функционала вы подключаете модуль/библиотеку, а не тащите все в рантайм, чтоб оно расходовало ресурсы зазря.
В .NET всё тоже самое. Что-то нужно, подключаете библиотеку. Однако все решения работают в одном пространстве. Статические файлы .NET отдаёт также эффективно, как nginx, и к обработке запросов на файлы можно применять абсолютно весь обвес и все правила, которые применимы для любых других запросов. Но PHP файлы не отдают, поэтому всё что можно костылится на nginx-ах.
Это же факт. Или затыкаем любой неудобный факт "вам это не нужно", и дело в шляпе? :)
location = /avatar {
set_decode_base32 $session $cookie_auth;
set_decrypt_session $id $session;
if ($id = '') {
return 404;
}
try_files $id /avatar.php?id=$id;
}
Ох... вы расшифровываете токен в Nginx, который создан приложением. Даж не знаю как комментировать. Ну ок.
Все в томже духе, задача простая и довольно распространенная, если вы думаете, что эффективно с этим справится только .NET - у меня для вас плохие новости :)
Нет не всё в том же духе, здесь вы не смогли привести даже пример на пальцах. Да я и не думаю. Я знаю, так как эту задачу решал и решается она легко, и держит высокие нагрузки, с масштабирование и гео-балансировкой. И без всяких nginx-ов и промежуточных прокладок.
Более того, сервис на .NET-е используется в одном проекте на Python, выступая в роли API-гейта и статики со сложными политиками доступа к файлам. Новости у меня хорошие, это работает отлично :)
Ваше невежество можно понять, вы видимо долго и безвылазно сидите на .NET и даже не пытаетесь вникнуть как оно там в других окружениях, а тут еще на конфах бравые докладчики рассказывают что "там" все криво, через костыли и велосипеды а у нас православно и круто.
Заметьте, я не разу вам не грубил, не подвергал сомнению ваши компетенции, знания, и не говорил в сторону PHP слова "плохой", я говорю о конкретных кейсах.
Ну вот кейс, PHP плохо справляется с отдачей статики. И так его не применяют. Это факт? Факт. Вы как будто мимо ушей это пропускаете, называете меня неучем, дескать это "никому и не надо", и задачи-то у меня глупые. Всё чтоб оправдать факт, который от этого фактом быть не перестаёт.
Что сложного сказать, да так и есть, но мы знаем обходные пути и пользуемся этим. Всё. Нет, надо перейти в холодную агрессию, и назвать оппонента дураком. Странная манера у вас вести дискуссию. Обидно, что вы до такого скатились.
В приложении есть методы, один и тот же метод обрабатывает запрос:
GET /some/{some-id}/some-other/{some-other-id}
some-id и some-other-id -- разные, но метод один, и приложение знает что это один метод, и метрики успешных, ошибочных и т.д. запросов собирает для одного метода, не важно это запрос на файл, или АПИ
Nginx ничего этого не знает, с разными параметрами это будут совершенно разные URL для него. Он не может собрать статистику хитов, ошибок, гистограмму выполнения и т.д. по методу.
На nginx эта задача не выполнима.
Все правильно, на Nginx эта задача невыполнима, наверное потому, что это всего лишь вебсервер и его задача просто передать запрос, что собственно и сделаем:
location ~ /some/([^/]+)/some-other/(.+)$ {
try_files /app.php?some_id=$1&some_other_id=$2 =404;
}Собираем в приложении статистику хитов, ошибок и чего угодно.
Но PHP файлы не отдают, поэтому всё что можно костылится на nginx-ах.
На PHP не отдают статику т.к. в этом нет никакого смысла, и это делает далеко не только PHP а любой скриптовый и не только язык т.к. это контрпродуктивно. Поэтому node.js, питон, go и многие другие "костылят" это на Nginx и только .NET все прогоняет сквозь себя :)
Более того, сервис на .NET-е используется в одном проекте на Python, выступая в роли API-гейта и статики со сложными политиками доступа к файлам. Новости у меня хорошие, это работает отлично :)
Good for you. Жду ссылку на гитхаб
Ну вот кейс, PHP плохо справляется с отдачей статики.
Я уже не знаю как объяснить еще более доступно... Статику отдает вебсервер, потому что это статика и потому что PHP не вебсервер. И повторюсь, так поступает по озвученым выше причинам далеко не он один, и вэтом нет никакой проблемы от слова совсем. Проблему пытаетесь найти вы, но до сих пор тщетно, поэтому не сдавайтесь, пишите, вы один против всей индустрии веб фреймворков, cms и всего такого :)
location ~ /some/([^/]+)/some-other/(.+)$ {
try_files /app.php?some_id=$1&some_other_id=$2 =404;
}
Вы предлагаете для каждого метода писать какие-то реврайты на nginx-е? Может и логику уже на Lua туда разместить? ))
На PHP не отдают статику т.к. в этом нет никакого смысла, и это делает далеко не только PHP а любой скриптовый и не только язык т.к. это контрпродуктивно. Поэтому node.js, питон, go и многие другие "костылят" это на Nginx и только .NET все прогоняет сквозь себя :)
NodeJS прекрасно статику отдаёт. Go прекрасно статику отдаёт. PHP и Python делают это из рук вон плохо.
И не надо натягивать сову на глобус, объясняя что PHP это плохо делает только потому, что это дескать и не нужно. Как раз потому, что он делает это плохо, задача решается с помощью nginx.
Или в какой библии вы прочитали, что это божественный закон такой, что статику из приложения отдавать грех?
Кроме того, вы так и не показали хотя бы на пальцах, как обеспечить защиту статики для пользователей, исходя из их полномочий. Полномочий могут быть сотни, вы их в куки не запихаете. Как решать будете?
Я уже не знаю как объяснить еще более доступно... Статику отдает вебсервер, потому что это статика и потому что PHP не вебсервер.
Т.е. если бы PHP был бы веб-сервером и мог бы делать это эффективно, то можно было бы отдавать файлы прям из PHP-приложения? :)
Ну так об этом и речь. При чём с самого начала я об этом и сказал, с самого первого сообщения. В PHP нет встроенного веб-сервера. PHP не может эффективно отдавать статику.
Да, я считаю, это плохо. И не только я, среди наших сеньёров PHP тоже есть такие, кто так считает, и делают ставку на развитие RR, в сторону долгоживущих процессов (прям как Java, .NET и др.), когда-нибудь даже с поддержкой io/асинхронности.
Вы предлагаете для каждого метода писать какие-то реврайты на nginx-е? Может и логику уже на Lua туда разместить? ))
Нет конечно, я написал пример конкретно под ваш кейс. Обычно все запросы просто идут в роутер, примерно так
location / {
try_files $uri /index.php$is_args$args;
}NodeJS прекрасно статику отдаёт.
Ясно-понятно, вы и ноду знаете на уровне джуна. Читайте
For a high-traffic website in production, the best way to put compression in place is to implement it at a reverse proxy level (see Use a reverse proxy). In that case, you do not need to use compression middleware. For details on enabling gzip compression in Nginx, see Module ngx_http_gzip_module in the Nginx documentation.
С Go похожая ситуация, ибо насколько бы эффективно это бы не делало приложение (неважно на каком языке) иебсервер это сделает быстрее и без оверхеда. Это best practices.
Кроме того, вы так и не показали хотя бы на пальцах, как обеспечить защиту статики для пользователей, исходя из их полномочий. Полномочий могут быть сотни, вы их в куки не запихаете. Как решать будете?
В куки полномочия, серьезно, еще наверное plaintext? :) Токен и/или сикрет и по нему уже проверять, поразительно что это не очевидно, примеры проверки токена я уже приводил выше.
Т.е. если бы PHP был бы веб-сервером и мог бы делать это эффективно, то можно было бы отдавать файлы прям из PHP-приложения? :)
Вопрос из разряда если бы у бабки было причинное место.
В PHP нет встроенного веб-сервера.
Я вам в самом начале показал, что есть.
PHP не может эффективно отдавать статику.
Так же эффективно как Nginx/Apache - конечно, и не будет никогда т.к. есть вебсерверы специально для этого предназначенные (в который раз я это пишу, в 5-й?).
Да, я считаю, это плохо.
Ваше право.
И не только я, среди наших сеньёров PHP тоже есть такие, кто так считает
А у меня 25 сантиметров в холодной воде
Устал я от вашего высокомерия, и совершенно неадекватной грубости.
Знатно посмеялся конечно с того, что NodeJS-у нужен nginx. Кстати, расскажите об этом, например, вот этим ребятам https://github.com/nodeSolidServer/node-solid-server или вот этим https://github.com/cloudhead/node-static -- а то они дураки, и не знают, как же они без его величества Веб-Сервера )))
Скиньте ссылку на вашу библию, где написано, что без Веб-Сервера только глупцы хостят свои приложения :)
С Go похожая ситуация, ибо насколько бы эффективно это бы не делало приложение (неважно на каком языке) иебсервер это сделает быстрее и без оверхеда. Это best practices.
Какие же у вас убойные фантазии, диву даюсь.
Сразу в догонку, насчёт сравнения платформы и языка -- я сразу сказал именно к языку претензий нет никаких, язык великолепен, в PHP есть даже фишки, которых нет в C#. Но рассматривать язык без библиотек, среды исполнения и платформы просто не имеет никакого смысла. В .NET можно и на PHP писать :)
Хорошо, если за платформу взять фреймворк, Symfony, какие у вас к ней претензии?
Никаких, шикарный фреймворк, как для PHP. Слышал, жалуются на сложность. Меня же смущает, что к каждому фреймворку прибиты свои ORM и компоненты, и не так много можно переиспользовать, либо переписывают, либо адаптируют. По сути часто ищут не просто PHP разработчика, а разработчика со знаниями конкретного фреймворка. Это удручает.
По сути часто ищут не просто PHP разработчика, а разработчика со знаниями конкретного фреймворка. Это удручает.
Это прям жирно вы набросили, правда. Вас не смущает что так вся индустрия работает и не только в IT.
Это вовсе не наброс, и вовсе не жирный. Наличие большого количества конкурирующих фреймворков -- это плохо для индустрии. Вот живой пример. В компании используется Yii2. Что плохо. Компания не может искать себе разработчиков PHP. Она вынуждена искать разработчиков именно yii2, что сильно сужает круг поиска. В самом Yii2, есть проблемы, которые решены в других фреймворка, но не в нём. Вот примеры: невозможно работать с Redis Cluster, ограниченная работа с Redis Sentinel, невозможно работать с кластером Rabbit, невозможно работать с кластером Postgre, ORM генерить непараметризованные запросы, и поделать с этим ничего нельзя, dba лютуют. Невозможно без сложных доработок перейти на RR. Серьёзные проблемы с логами, невозможно применить ничего из других фреймвоков для работы с Open Telemetry, нет прозрачной трассировки.
Почему на этом акцентировал внимание на этом. В .NET нет ни одной из этих проблем. Основной фреймворк один и любой .NET веб разработчик его знает. Нет разработчиков XXX, YYY, ZZZ и десятков других фреймворков. И это значит, что вся масса всех компонентов, библиотек и решений, все они работают, нет необходимости писать и дублировать решения под каждый отдельный фреймворк, которые друг с другом не совместимы.
Наличие большого количества конкурирующих фреймворков -- это плохо для индустрии.
Да, я понял, вы просто решили преплюнуть свою прошлую глупость. Я не могу сколько либо серьезно отвечать на такие вбросы, всерьез заявлять, что конкуренция это плохо может либо жирнющий тролль, либо школьник у которого пока отсутствуют ввиду возраста базовые знания об экономике.
То что, вы не можете отвечать серьёзно на вопросы, я уже понял. Если вопрос вам не нравится (или скорее, вы просто не в состоянии на него ответить), то вопрос автоматически становится глупостью, а собеседнику нужно зачем-то нагрубить, дать характеристику его интеллекту.
Конкуренция сама по себе, это не плохо и не хорошо. Если залогом развития является только лишь конкуренция это плохо и приносит убытки, так как сложно развивать одинаково хорошо все направления.
Но я рискую нарваться на очередную грубость, так как вы не терпите другие точки зрения.
Вы можете заниматься софистикой сколько угодно, провоцировать на ответ фразами "вы не ответили на вопрос потому что он не равится" и все в этом духе, не утруждайтесь, правда. Мне ваших 2-х перлов про то, что "нанимать нужно не разработчика со знанием фреймворка, а просто PHP разработчика" и вред конкуренции хватило сполна.
Ох, я покусился на священную "конкуренцию" :) В целом, сам факт, что вы перешли на грубости и высокоумное "ах вы сказали так, ну это много о вас говорит..", просто напросто подтверждает озвученные мною тезисы.
И всё равно вы не заставите меня невзлюбить PHP :) У нас великолепная команда, пишет на нём великолепные проекты. Но только фанатики не умеют видеть обожаемом предмете недостатков.
Если вам кажется в PHP что-то не так, то это вам кажется, вы тупой, и вообще вам это не надо :)
Так, например, в своей статье Дмитрий
Стогов приводит бенчмарк для версии PHP 7.0, где демонстрируется,
что PHP обходит по производительности своих конкурентов, таких
как Python и Ruby, и даже не сильно отстает от Java с выключенным JIT.
Каждый кулик, как говорится ... Но давайте смотреть объективно на вещи и не сравнивать моську со слоном, ну честное слово, это утомляет.
И правда, давайте смотреть объективно
Про сообщество. Я бы добавил https://phpcommunity.ru/ движение направленное на объединение разработчиков и обмен опытом и знаниями. А так же конференцию https://phprussia.ru/
В сравнении в Python замечу, что найти работу в регионах сложнее. Конечно корона расширила региональные рынки труда до федеральных, но в целом в доковидное время люди были вынуждены пережать в столицы в поиске работы и коллег.
Стоит ли учить PHP в 2022 году