company_banner

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

Автор оригинала: Brent
  • Перевод


Помните некогда популярную публикацию: «PHP: фрактал плохого дизайна»? Я, когда впервые её прочитал, работал в дурацком месте с большим количеством устаревших PHP-проектов. Она заставила меня задуматься: должен ли я уйти и заняться чем-то совершенно другим, нежели программирование.

К счастью для меня, вскоре я смог сменить место работы, и, что более важно, PHP сумел «немного» развиться со времён 5.* версий. А сегодня посредством этой статьи я хочу обратиться к людям, которые либо больше не программируют на PHP, либо застряли в устаревших проектах.

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

Сегодня же я хочу взглянуть на светлую сторону: давайте сосредоточимся на том, что изменилось, и на способах написания чистого и поддерживаемого PHP-кода. Я хочу попросить вас отбросить на несколько минут предрассудки.

После этого вы можете думать о PHP точно так же, как и раньше. Хотя, скорее всего, вы будете удивлены некоторым улучшениям, сделанным в PHP за последние несколько лет.

TL; DR


  • PHP активно разрабатывается, каждый год выходит новый релиз
  • Производительность с эры PHP 5 выросла вдвое, если не втрое
  • Существует чрезвычайно активная экосистема фреймворков и библиотек
  • За последние несколько лет в PHP было добавлено много новых функций, и язык продолжает развиваться
  • Инструменты, подобные статическим анализаторам, за последние годы очень развились и продолжают развиваться дальше

Краткая история


Вкратце рассмотрим релизный цикл PHP. Сейчас текущая версия PHP 7.3, а версия 7.4 ожидается в конце 2019 года. PHP 8.0 будет следующей версией после 7.4. Начиная с поздней эры PHP 5.*, команда мейнтейнеров старается поддерживать ежегодный цикл релизов и в течение последних четырех лет у неё это хорошо получается.

В целом, каждый новый релиз активно поддерживается в течение двух лет и получает ещё один год «исправлений безопасности». Цель состоит в том, чтобы мотивировать разработчиков на PHP поддерживать актуальность версии: применить небольшие обновления каждый год намного проще, чем, например, перейти с 5.4 на 7.0.

Обновляемый календарь сроков поддержки разных версий PHP можно найти тут.

Наконец, PHP 5.6 был последним релизом ветки 5.*, а 7.0 являлся следующим. Если вы хотите узнать, что случилось с PHP 6, Вы можете прослушать подкаст PHP Roundtable.

Теперь давайте развенчаем некоторые распространённые заблуждения о современном PHP.

Производительность PHP


В дни версий 5.* производительность PHP была… средней, в лучшем случае. Однако в версии 7.0 значительные части ядра PHP были переписаны с нуля, что привело к увеличению производительности в два-три раза.

Но слов недостаточно. Давайте посмотрим на тесты. К счастью, другие люди потратили много времени на бенчмаркинг производительности PHP. Я считаю, что у Kinsta есть хороший обновлённый список.

Начиная с версии 7.0, производительность только увеличивается. Настолько, что веб-приложения PHP имеют сопоставимую, а в некоторых случаях лучшую производительность, чем веб-фреймворки на других языках. Взгляните на этот обширный набор тестов.

Конечно, PHP-фреймворки не будут превосходить C и Rust, но они намного лучше, чем Rails или Django, и сопоставимы с ExpressJS.

Фреймворки и экосистема


Говоря о фреймворках: PHP больше не ограничивается WordPress. Смею заявить  вам как профессиональный PHP-разработчик: WordPress никоим образом не является представителем современной экосистемы.

В общем, есть два основных фреймворка веб-приложений: Symfony и Laravel. И несколько более мелких: Zend, Yii, Cake, CodeIgniter и т. д.  Но если вы хотите знать, как выглядит современная PHP-разработка, хорошим выбором будет познакомиться с одним из двух крупнейших.

Оба фреймворка (Symfony и Laravel) имеют большую экосистему пакетов и продуктов. Начиная от административных панелей и CRM до автономных пакетов (в оригинале — «standalone packages»), от CI до профилировщиков, а также многочисленные сервисы, такие как серверы веб-сокетов, менеджеры очередей, интеграции платежей; честно говоря, слишком много, чтобы перечислить все.

Однако эти фреймворки предназначены для непосредственной разработки. Если вы нуждаетесь просто в управлении контентом, такие платформы, как WordPress и CraftCMS, только всё больше и больше улучшаются.

Один из способов измерить текущее состояние экосистемы PHP — посмотреть на packagist — основной репозиторий пакетов для PHP. Он экспоненциально растёт. При ~25 миллионах загрузок в день, можно справедливо сказать, что PHP-экосистема  — уже не та слабая сторона, которой она являлась раньше.

Посмотрите на этот график, в котором указано количество пакетов и версий с течением времени. Его также можно найти на веб-сайте packagist.



Кроме фреймворков приложений и CMS, в последние годы мы также наблюдаем рост асинхронных фреймворков.

Это фреймворки и серверы, написанные на PHP или других языках, позволяют использовать поистине асинхронный PHP. Среди примеров: Swoole, Amp и ReactPHP.

С тех пор как мы вошли в асинхронный мир, такие вещи, как веб-сокеты и приложения с большим количеством операций ввода-вывода, стали действительно актуальными в мире PHP.

В списке рассылки internals — месте, где ведущие разработчики обсуждают развитие языка, — также говорилось о том, чтобы добавить libuv в ядро. Для тех, кто не знает libuv —  это та же библиотека, которую Node.js использует для обеспечения всей её асинхронности.

Сам язык


Хотя async и await ещё недоступны, за последние годы было сделано много улучшений в самом языке. Вот далеко неполный список новых функций в PHP:

  • Стрелочные функции
  • Оператор объединения с null
  • Трейты
  • Типизированные свойства
  • Оператор распаковки
  • JIT компилятор
  • Интерфейс внешних функций
  • Анонимные классы
  • Декларации возвращаемого типа
  • Современная криптография
  • Генераторы
  • Многое другое

В то время как мы говорим о языковых особенностях, давайте также затронем тему того, как язык развивается сегодня. Существует команда мейнтейнеров-добровольцев, которые двигают язык вперёд, при этом сообщество также может предлагать RFC.

Затем эти RFC обсуждаются в списке рассылки «internals», который также можно прочитать в интернете. Прежде чем новая языковая функция будет добавлена, необходимо провести голосование. Только RFC с большинством голосов, не менее ⅔ от всех проголосовавших, допускаются к включению в ядро.

В голосовании принимают участие около 100 человек, при этом требования голосовать на каждом RFC — нет. В группу людей, имеющих возможность голосовать, конечно, входят мейнтейнеры, т. к. они должны поддерживать кодовую базу. Помимо них, есть группа, участники которой были выбраны в индивидуальном порядке из сообщества PHP. Эта группа состоит из   мейнтейнеров PHP-документации, авторов крупных PHP-проектов и выдающихся разработчиков из PHP-сообщества.

Хотя большая часть разработки происходит на добровольной основе, один из разработчиков ядра PHP, Никита Попов, недавно был нанят JetBrains для работы над языком на полный рабочий день. Другим примером является фонд Linux, который недавно решил инвестировать в Zend Framework. Подобные работы и приобретения гарантируют стабильность для будущего PHP и его развития.

Инструментарий


Помимо самого ядра, последние несколько лет мы наблюдаем увеличение инструментов вокруг него. На ум приходят статические анализаторы типа Psalm, созданный Vimeo, Phan и PHPStan.

Эти инструменты статически анализируют ваш PHP-код и сообщают о любых типовых ошибках, возможных багах и т. д. В некотором смысле, предоставляемые ими функциональные возможности можно сравнить с TypeScript (примечание переводчика: статические анализаторы расширяют возможности языка по поиску ошибок\недоработок тем самым улучшая язык, TS условно делает то же самое поверх JS), хотя на данный момент язык PHP не транспилируемый, поэтому настраиваемый синтаксис не допускается.

Несмотря на то, что при этом нам нужно полагаться на докблоки и типизацию, Расмус Лердорф, создатель PHP, упомянул идею добавления механизма статического анализа к ядру. Эта задача содержит в себе много потенциала, но по трудозатратам она огромна.

Говоря о транспилировании, стоит отметить, что были попытки расширить синтаксис PHP не на уровне ядра, а на уровне пользовательских библиотек, как это реализовано в JavaScript. Проект с именем Pre делает именно это: позволяет использовать новый синтаксис PHP, который переносится в обычный  PHP-код.

Хотя такой подход зарекомендовал себя в мире JavaScript, он сможет заработать в PHP только если будет обеспечена надлежащая поддержка IDE и статического анализа. Это очень интересная идея, но она должна пройти ещё долгий путь, прежде чем её можно будет назвать «мейнстримом».

В заключение


Несмотря на всё сказанное, не стесняйтесь думать о PHP как об ужасном языке. У него определённо есть свои недостатки и 20-летнее наследие, но я могу с уверенностью заявить, что работать с ним мне нравится.

С его помощью я могу создавать надёжное, хорошо обслуживаемое и качественное программное обеспечение. Клиенты, на которых я работаю, довольны конечным результатом, как и я.

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

Вы не согласны? Напишите в комменты, почему!
FunCorp
214,84
Разработка развлекательных сервисов
Поделиться публикацией

Комментарии 95

    –17
    Говоря о фреймворках: PHP больше не ограничивается WordPress.


    1) Я всегда думал что это CMS ну да ладно…
    2) В 2018 «фремворки» PHP ограничивались WordPress, а в 2019 все резко изменилось?

      +6
      Можно долго словоблудить что является фреймворком, а что нет, но, думаю, в данном предложении имелось ввиду, что появились достойные фреймворки, которые пришли на смену низкокачественным поделкам с плохой архитектурой.
        +1
        Это очень оптимистично, про «пришли на смену.» Во-первых, Symfony и Laravel не в 2019 году появились, во-вторых, Wordpress сдавать позиции не собирается. 60% или сколько там?
        +5
        не позорься пожалуйста
          –4
          Вы что все на вордпресе сидите?:)
        0
        В целом, каждый новый релиз активно поддерживается в течение двух лет и получает ещё один год «исправлений безопасности». Цель состоит в том, чтобы мотивировать разработчиков на PHP поддерживать актуальность версии: применить небольшие обновления каждый год намного проще, чем, например, перейти с 5.4 на 7.0.


        Большинство пользуется ровно тем, что есть в дистрибутивах и, без достаточных на то оснований, предпочитает LTS-дистрибутивы. Без борьбы с LTS-ами этот мотивационный шаг не имеет смысла.
          0
          Оба основных игрока на рынке панелей для коммерческого хостинга (cPanel и Plesk) давно и эффективно поддерживают современные версии PHP, и добавляют новые достаточно оперативно по мере их выхода. Я работаю в одном здании с cPanel и ребята в команде EasyApache очень внимательно следят за экосистемой PHP. Конечно, есть люди, которые работают на голых дистрибутивах, но при разработке коммерческих приложений де-факто приходится учитывать скорее то, какие версии PHP доступны на лидирующих хостингах. Плюс к тому, PHP 7 значительно эффективнее с точки зрения CPU и использования памяти, и для хостера это транслируется в экономию ресурсов сервера и, соответственно, затрат — т.е. имеем коммерческую мотивацию.
            +3
            Как бы 2019-й на дворе. Devops, kubernetes, докер, облака. На голом дистрибутиве работать довольно грустно.
              +4
              Да, ООО «Рога и копыта» для своего лендинга на вордпрессе без kubernetes ну совсем никак.
                0
                С определенных масштабов даже лендинги на вордпрессе проще рулить через кубернетес или аналогичные решения.
                  0
                  И у скольких компаний сайты/приложения достигли таких масштабов, чтобы им было выгодно содержать банду «рулителей кубернетесов»? 100 на всю РФ? 103?
                    0
                    1) Я не считал и в общем-то не в РФ работаю и уже давно не с PHP.
                    2) Вам не нужна банда рулителей, на небольших объемах рулением может заниматься и один человек (два для резервирования на случай отпусков/болезней/увольнений), причем разделяя эти обязанности с непосредственной разработкой, например. Или с администрированием.

                    А вот когда работал в РФ PHP-разработчиком в среднего пошиба аутсорсе (НЕ Москва, 150-200 человек всего, включая все сорта мобильных разработчиков, джавистов, сишников и прочих тестировщиков с менеджерами. PHP-команда человек 20 разработчиков, самый крупный отдел, если мне память не изменяет, таких компаний в СНГ должно быть очень много), делал полуавтоматизированную платформу быстрого деплоя PHP проектов для внутренних нужд — Q/A, демонстрация клиентам, проверка на не-девелоперском энвайроменте, обкатывание миграций при передеплое и прочее, естественно с поддержкой разных версий php. Делал руками, поверх виртуальных машин и LTS-убунты, потому что ни докера ни кубернетеса тогда еще не было (2011-й, 2012-й годы), были бы — наша жизнь была бы сильно проще.

                    БольшАя часть проектов, кстати, была на Drupal (не вордпресс, да, но лучше бы уж вордпресс).

                    Я к тому что вот это был вполне обыденный аутсорс и там эти технологии были бы применимы и полезны.

                    И кастомерам можно было бы отдавать готовые к работе контейнеры (сначала мы отдавали просто сорцы, потом какие-то рукодельные скрипты-инсталляторы, потом были chef/ansible/puppet/vagrant, потом я ушел, не знаю как там сейчас.
                      +1
                      Дело не только в масштабе, докер вообще не эту задачу решает, и осваивается мидлом за 1 день, до уверенного пользования во всех своих следующих проектах.
                0
                А кто мешает в LTS дистрибутив поставить современную версию нужного пакета? Зато переставлять сервер из-за того что на него прекратились секурити фиксы не прийдется дольше… :)
                +4

                Пара слов в защиту WordPress: существует божественный Bedrock, который как раз реализует экосистему для CMS, и существует WordPress Packagist, который является репозитарием плагинов и тем для CMS. Все ставится композером, существует прозрачная система настройки окружения, манифесты для плагинов, опять же, под разные окружения. Кароче, мир WordPress разработки уже далеко ушел от того, что представляет сам WordPress из себя, теперь это ядро системы, которое обрастает удобным интерфейсом. К слову WordPress это уже давно просто админка для нормальных парней.

                  0
                  А если туда еще Timber добавить, то и более-менее жить уже можно =)
                  –10

                  Мне кажется, php явно идёт не туда. Это стремление конкурировать с большими языками общего назначения ничем хорошим не закончится, даже сейчас все эти амбициозные планы и реализации выглядят как ченжлоги питона 5-15 летней давности, не говоря уже о java/c#. При этом php растеряет всю свою простоту, которая и принесла ему такую популярность.

                    +1
                    По моему простота, которая и принесла ему такую популярность, это возможность встраивать код в html разметку, и вряд ли php ее растеряет )
                      +4
                      А php и не пытается конкурировать с языками общего назначения. Основная задача 7 ветки была ускорение скорости интерпретации и выполнения, с чем они успешно справились. А JIT просто немного расширит границы применимости: там где сейчас php очень сложно использовать (ML и еще какие-нибудь сложные мат. вычисления), уже можно будет попробовать.
                        –2

                        По-моему в вашем сообщении явное противоречие. Если php не пытается конкурировать с языками общего назначения и его ниша это веб, то зачем ему расширять границы применимости и как он вдруг оказался в ML? Причем, ниша интерпретируемых языков с JIT и асинхронностью уже заняты python/node.js, которые развиваются в этом направлении уже очень много лет и чтобы догнать их, команде и сообществу php придется потратить как минимум столько же времени (для выявления и оптимизации узких мест в реализации, создания экосистемы пакетов, тулинга, адаптации существующего легаси кода и т.д.), тем самым php изначально обрекает себя быть в "догоняющих" с огромным отставанием (~10 лет?), оказываясь в очень неудобном положении.
                        Мне кажется, что php стоило бы дальше развиваться в направлении веб-ориентированного языка-фреймворка, на котором просто и быстро можно делать сайты, а не пытаться втиснуться в устоявшиеся ниши, не предлагая ничего нового. Это тупиковый путь, имхо.

                          +8
                          Большой вопрос кто куда пытается втиснуться. 10 лет назад РНР был полновластным хозяином веба. Затем в моду вошел Python и появился NodeJS (первый релиз как раз вышел 10 лет назад). Но Python постепенно растерял свою популярность как язык для разработки сайтов. А Node я бы сказал так: Javascript «сходил» на бэкенд и вернулся на фронт. Да сегодня есть команды которые влюблены в  React и Angular, но мне кажется все же большинство серьезных вещей делаются с разделением на фронтэнд и бэкэнд. Где на фронте правят React || Angular а вот на бэкэнде Javascript особо не прижился и там зоопарк из Python || PHP || Java || .Net.
                          Я категорически не согласен с
                          php изначально обрекает себя быть в «догоняющих»
                          На бэкенде у него свои давно завоеванные огромные территории. Он изначально рожден вместе с вебом. Да он слабо применим и практически не используется как универсальный язык. С этим не буду спорить. Но в своей нише он далеко не новичок и общий посыл автора о том что РНР точно не собирается на покой я полностью поддерживаю.
                          Если вам нужна кроссплатформенность наверное Java. Если вы увлеклись embeded то извольте С и С++. Если вы хотите ML и AI то Python рулит сегодня. И далее по списку. Существуют вполне нишевые языки Ruby, Rust, Haskel, Go на которых написано мало (по количеству проектов), но они решают определенный тип задач лучше всего. PHP тоже нишевой язык.
                            –1
                            На бэкенде у него свои давно завоеванные огромные территории. Он изначально рожден вместе с вебом..
                            Это так, но веб, для которого используют php и веб, для которого используют python/node.js/go/etc, это во многом очень разный веб, более явно это разделение очертилось с «эпохой вебсокетов» и SPA. И обычные, «традиционные» сайты и есть ниша php, это очень большая ниша веба, которая никуда не собирается деваться. Но вместо того, чтобы дальше в этом направлении развиваться, php пытается втиснуться в нишу «асинхронного веба» с многолетним опозданием. Я не совсем понимаю зачем это делать и более того, это ведь полностью противоречит идее самого языка с «умирающими» воркерами и полной синхронностью. Перейти на такой php будет не намного проще, чем вообще сменить язык.
                            PHP тоже нишевой язык.
                            Вот я как раз за то, чтобы он таким и оставался.
                              0
                              В асинхронщину сам язык вроде как не лезет. Сторонние разработки. Основной вектор как мне кажется на добавление «строгих» возможностей, улучшение стат анализа.
                                0

                                Мне довелось работать в Lazada и на бэке жил php, мы отдельные куски переносили в go, но все равно доля php была 80-85%. И оно жило под нагрузкой. А миграция с 5.5 на 7.0 дала почти двухкратный рост производительности и более чем двухкратное падение потребления памяти.

                                  0

                                  Как мне кажется, объяснение простое: экономически целесообразно для типовых решений иметь один язык на бэке.

                                    +4

                                    Умирающие воркеры это не часть языка, а часть менеджера запросов. Архитектурных ограничений языка нет.

                                  0
                                  Ниша PHP не только web, можно запросто писать и консольные приложения, например. Учитывая, что для работы достаточно только самого PHP на целевой машине. Используя FFI можно подкрутить множество библиотек, и ML в том числе. PHP — инструмент, и нет ничего плохого в том, что он cможет дать больше, хоть и не так хорошо в конкретный момент, как другой язык. Откуда уверенность, что у PHP не получится и он будет «догоняющим»? Ну и с асинхронностью в JS тоже не всё гладко, насколько мне может быть известно (блокировки потока, потери контекста, миллионы колбеков и прочие радости). «Просто и быстро делать сайты» можно делать и на html. И мне на самом деле странно слышать утверждение, что node.js — интерпретируемый язык, а php — язык-фреймворк.
                                0
                                А что такое эти ваши языки общего назначения?
                                В моём представлении, сейчас можно:
                                — писать под веб
                                — писать консольные линукс-приложения
                                — писать графические линукс-приложения
                                — писать под винду
                                — писать под ведроид и ios.

                                С первыми двумя кейсами php справляется вполне успешно. Ну да, питон тоже. Касательно графических приложений под линукс — это какая-то очень узкая и странная ниша. Писать на питоне и на пхп под винду и мобилки — проще выстрелить себе в ногу. Те средства, что есть, настолько костыльны, что лучше бы их не было, наверное.
                                Единственный реально универсальные язык, который я знаю — это Java. Но он изначально таким и задумывался, кроссплатформенным и переносимым.
                                Чем питон универсальнее и «общЕе» пхп? Ну вот чем?
                                +1
                                Несмотря на то, что при работе с PHP всё ещё можно написать очень плохой код, я бы сказал, что это отличный выбор для веб-разработки, если его использовать правильно.

                                Капитан на палубе.
                                  0

                                  На любом языке можно написать очень плохой код, внезапно

                                  +4
                                  Мы начинали с асма, потом где-то там промелькнул паскаль, бейсик, потом си и снова асм в виде включений в си.
                                  Потом побаловались с флэшем и случайно пришли в веб на пхп. Это был еще то ли пхп2 то ли пхп3. Чем язык понравился? Простотой, возможностями в том числе стрелять себе в ногу. Чем не понравился? Малым количеством функционала и тормозами после с/асма.
                                  Пхп4 оставил простоту и возможности стрелять в ногу, сильно расширил набор функций из коробки и сохранил совместимость. Это было круто, мы подсели на него сильно и даже сдали зендовский экзамен по приколу.
                                  Пхп5 стал отнимать возможность стрельбы себе в ногу, откромсал часть совместимости и стал сложнее. Функционала он почти не добавил, но зато неплохо увеличилась скорость. Стали появляться яваподобные фреймворки.
                                  Пхп7 еще больше отнял возможность стрельбы себе в ногу, откромсал уже солидную часть совместимости и стал существенно сложнее. Функционал почти не добавился, скорость увеличилась кардинально.
                                  С одной стороны нас радует то, что скорость у пхп7 такая, что можно не смотреть на другие языки.
                                  С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется установить композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсы и так далее, иначе ты не модный. Вместо простого языка получилось нечто явоподобное. При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях. Уже не первый раз ловим себя на том, что проект неплохо бы завернуть в докер, что бы не думать на какой из подверсий пхп у заказчика сервер, опять же лишний наворот.
                                  Отсюда испытываем смешанные чувства, видим скорее не движение вперед, а скорее дрейф куда-то в бок с сильными и плюсами и минусами, но главное — с изменением идеологии. Не эволюция, а революция. Может быть это хорошо и мы просто жуткие консерваторы, в конце концов 20 лет с пхп это много. Но со времен пхп4 первый раз сильно хочется сменить язык.
                                  p.s.: Це личное мнение, не обязательно правильное:)
                                    +11
                                    использовать интерфейсы и так далее, иначе ты не модный

                                    Разве код нужно писать по моде? Интерфейсы нужны для связи частей программы. Если Вам нужны контракты — используете интерфейсы, не нужны — не используйте.
                                    При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях.

                                    По моему опыту ломаются какие-то неочевидные или неоднозначные выражения (которые вообще по-хорошему не надо было писать, типа $foo->$bar['baz']). Язык идет к строгости и это круто.
                                      –3
                                      Разве код нужно писать по моде?
                                      Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода.

                                      По моему опыту ломаются какие-то неочевидные или неоднозначные выражения
                                      В пхп5 это было в бОльшей части верно, хотя уже были нюансы.
                                      А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.
                                      Это кажется мелочью если ведешь только свои недавно рожденные проекты и/или проекты на последних версиях современных фрейворков, при этом контроллируешь серверное окружение и никто не делает ошибок.

                                      Язык идет к строгости и это круто.
                                      php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.
                                        +3
                                        А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.

                                        Незадолго до релиза php7 появился репозиторий (или даже несколько), с помощью которого можно было проверить совместимость с ним. У меня в нескольких проектах было только в одном месте выражение вида $foo->$bar['baz']), которое я исправил и успешно забыл о серьёзных различиях.
                                        Не вижу ничего сложного. Если проект дикий легаси седых годов, то с ним в любом случае будут проблемы, даже без обновления. Тем более мажорного релиза php. Тут дело не в php:)


                                        при этом контроллируешь серверное окружение и никто не делает ошибок

                                        а если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.

                                          +2
                                          если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.
                                          Может и странная, но мы ее не высказывали.
                                          У меня в нескольких проектах… Не вижу ничего сложного.
                                          Так потому что это у Вас в своих нескольких проектах. В своих проектах у нас тоже никаких особых проблем нет, более того, изрядная их часть спокойно работает на любых 5.х-7.х версиях без поправок.
                                          Просто мы как правило работаем с чужими проектами в том или ином виде. И если выход пхп5 не напряг почти никак, то вот после выхода пхп7 40% времени уходит на проблемы версионности.
                                          Тут дело не в php:)
                                          Невозможно написать код так, что бы он гарантированно не поимел проблем с новой версией, просто потому что неизвестно что она поломает. И если новая версия что-то ломает, при чем без необходимости, то достаточно странно говорить «пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©
                                            0
                                            Странная претензия.
                                            Может и странная, но мы ее не высказывали.

                                            Цитирую место, из которого я сделал вывод про претензию (убрал лишние рассуждения, думаю, смысл не поменялся):


                                            А вот в пхп7 уже достаточно… изменений
                                            Это кажется мелочью если… контроллируешь серверное окружение и никто не делает ошибок.

                                            Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимы. Если проблема в сторонних решениях — либо заменить, либо забить на обновление, либо контрибьютить совместимось — решения на любой вкус.


                                            «пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©

                                            теперь моя очередь:) «Может и странная, но мы ее не высказывали»© Я писал о том, что переход с одной мажорной версии на другую — однозначно требует проверки и доработки. Если на них нет времени/денег — значит не надо надеяться на авось.


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

                                            если речь про аусорс и на переход с одной версии на другую не выделялось время, то проблемы версионности — проблемы того, кто изменил версию php на сервере.
                                            если речь про сторониие библиотеки, то я встречал только 1 библиотеку не совместимую с php7.2 phpword. Конечно, это не показатель, но как я писал выше — есть скрипты для проверки совместимости 5. -> 7. если есть какие-то проблемы, то либо пофиксить, либо забить на обновление, если проект не предполагает бюджет на это.

                                              0
                                              Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимы
                                              Если велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого? А если второе обновление на 50% состоит из того, что дорожку адаптировали к стандартам трэкинговых, а не прогулочных дорожек (как было раньше) и именно из-за этого получилось 80%, а не скажем 20%?
                                                0
                                                Если велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого

                                                Вы забыли упомянуть что этот велосипедист смотрит не куда едет а на небо.
                                                  0
                                                  Как по нам на нормальной велосипедной дорожке вполне можно посматривать в небо и нет необходимости 100% времени смотреть не врежешься ли во что-то и не изменился ли со вчерашнего дня маршрут.
                                          0
                                          php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.


                                          Можете возразить, но я считаю что строгость в текущем контексте — с любой стороны хорошо(тем более она опциональна). Потому тут скорее «купить пользованую шестерку, а в ходе модификации получить приору какую-нибудь», до Феррари пока далеко )
                                            +1
                                            Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода

                                            Нутк вы ж не школьник, я надеюсь, чтобы следовать слепо за модой, своя же голова есть на плечах. Просто нужно возможностями языка пользоваться в соответствующих местах. Если вам нужно новую страничку или эндпоинт добавить в проект, который написан, скажем, на Symfony 4 — то да, нужно писать всё в том же стиле, что и весь остальной проект, а если нужно сделать
                                            echo 'hello world' на голом пхп

                                            то так и пишите.

                                            То, что сейчас появилась куча стандартов и все стараются писать в соответствии с SOLID, то что есть прекрасный пакетный менеджер и развивающиеся фреймворки с большим комьюнити — это прекрасно. Просто нужно адекватно использовать все эти возможности и не тащить тяжёлую артиллерию туда, где она не нужна.
                                          +2
                                          С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется

                                          Совершенно ничего не требуется. Все работает ровно так же.
                                           echo 'hello world'; 

                                          Поменялось и стало более строгим именно там где люди пытались «городить огород» и делали это разнообразными костылями. И им постепенно сказали какими костылями можно пользоваться, а какими нельзя. А потом поотбирали костыли совсем.
                                          Про
                                          композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсы
                                          вам уже написали. Это новые фишки, которые вы можете игнорировать и если ваш код не требует зависимостей и вы не путаетесь в наименовании классов или вообще не используете классы, все будет работать ровно также как работало.
                                          +4
                                          Конечно, PHP-фреймворки не будут превосходить C и Rust, но они намного лучше, чем Rails или Django

                                          Очень спорное заявление. Если судить по исходникам тестов, то правильно было бы написать: "Nginx + php_fpm намного лучше чем Gunicorn на чистом Python".


                                          Замени Gunicorn на Nginx + uWSGI или на bjoern и результаты поменяются кардинально.

                                            +4
                                            В статье нет ничего нового, о чем бы не упоминали регулярно в последние два года.

                                            P.S. Но картинка шикарная. Стиль рисунка напомнил одну, в свое время популярную игру.
                                            «Из зоопарка города Бердичева, похищен слон, необычной, полосатой породы...»
                                              +1

                                              Прямо вспоминается реклама Internet Explorer sucks less.

                                                0
                                                А нативную поддержку юникода в главный язык по веб разработке уже завезли?
                                                  +2

                                                  А она, извиняюсь, зачем? Ну хоть одну причину сможете назвать?

                                                    –6
                                                    1. � 2019 ���� �� �������� ���-�ࢥ� �뤠�� ���⥭� � �⮩ ����஢��.
                                                      +5

                                                      Вашему вниманию предлагается котик данных

                                                  –10
                                                  PHP годится только для веб-разработки. Больше ни для чего.
                                                  Серьезные программные продукты никто не станет писать на PHP.
                                                  Зачем делать из PHP вторую Java, если уже есть Java? Которая с нормальной типизацией, с «настоящими» аннотациями, а не мимикрирующими под них комментариями, многопоточностью, асинхронностью. Она более логична и не раздражает программиста. Я не хочу умалять заслуги PHP в роли языка для веб-разработки, но если вы хотите иметь возможности для роста, а не застрять в «нише», для которой PHP был придуман, берите другой язык.
                                                  Ну а если хотите играть в низшей программисткой лиге и постоянно быть в роли догоняющих, выбирайте PHP.

                                                    +1
                                                    > Зачем делать из PHP вторую Java, если уже есть Java?
                                                    Примерно затем же, зачем делать из телефона-звонилки современный смартфон, когда уже был компьютер. Новые фичи PHP не мешают старым задачам, а вполне себе даже помогают. То что они есть в других языках только доказывает их полезность.
                                                      +2

                                                      По-моему, главное что мешает перебраться пхп в боле высшую лигу, это люди с таким вот мнением, как у вас.
                                                      Т.е. проблема более идеологическая, нежели техническая.

                                                        0
                                                        Когдато думали зачем нужен С если есть ассемблер и машинные коды. Тем более что в машинных кодах программа получается меньше и более быстрая… даже бухгалтерии так писали…
                                                          +1
                                                          Она более логична и не раздражает программиста.

                                                          Ага, совсем не раздражает.
                                                          Заходит джавист в столовую и говорит «Паблик статик файнал Борщ борщ нью Борщ, пожалуйста.»
                                                          0
                                                          Подскажите, реально ли сейчас писать на РНР в чисто процедурном стиле? Вот как лет 10 назад. Не с целью холивара, просто интересно — раньше делал небольшие странички, а теперь, как я понял, без ООП никуда. Или, все же, не так все плохо?
                                                            0
                                                            я динозавр и либо использую вордпресс, либо пишу мелкие скрипты в процедурном стиле. Кстати, так получается короче, чем использовать теперь уже встроенные классы.
                                                              +1
                                                              Т.е. это вполне реально в РНР 7, ООП там не является обязательным, верно?
                                                                0
                                                                Да.
                                                                  +1
                                                                  Но не все функции всех библиотек будут доступны.
                                                              +2
                                                              Вообще да, но зачем? Собираетесь изобретать велосипеды? На packagist.org есть очень много хороших готовых библиотек для работы с чем угодно. А composer предлагает отличный инструмент для управления этими компонентами в вашем проекте. Впрочем, даже используя либы, которые написаны по ООП, вы можете писать своё приложение так, как вам нравится.
                                                                0
                                                                Возможно, они действительно удобно и приятно (я помню еще PEAR), но не хочется погружаться во все это… РНР (и веб в целом) не является моими основными направлениями. Моя цель — небольшие скрипты для тех или иных задач.
                                                                  0
                                                                  Тогда для вас особо ничего не поменялось. Только вот тащить PHP для небольших скриптов… Может для этих целей лучше подойдёт python (хотя бы потому что он искаропки во многих дистрибутивах)?
                                                              0
                                                              Я из прошлого века, вопрос: под Windows есть IDE с отладчиком, такая, чтобы установить и нормально работало, хотя бы как в Delphi версии Turbo Pascal?
                                                                0
                                                                Есть Visual Studio Code, там можно поставить расширение php и отладчик.
                                                                Правда я ее не использую, т.к. для мини-скриптов хватает нотепада и браузерной отладки.
                                                                  0
                                                                  Да, питерские JetBrains PHPStorm/WebStorm например.
                                                                    +1
                                                                    WebStorm почти не работает с PHP, кроме хайлайтинга там ничего нет. Нужен именно PHPStorm, в нём как раз есть почти всё, что необходимо для комфортной PHP разработки.
                                                                    0
                                                                    NetBeans хорошая бесплатная иде
                                                                    –10
                                                                    Ну вот зачем архаичный язык почти такой же как и другие императивные, только со спамом $ тащить в двадцать первый век? Неужели нельзя перестать быдлокодить одни и те же низкоуровневые операции 10000 раз и сделать модуль для веб разработки, генерирующийся из модели???
                                                                      0
                                                                      Нельзя просто взять и выкинуть сотни миллиардов строк крутящегося прямо сейчас на серверах кода, уволить сотни тысяч программистов, взять на их место сотни тысяч новых, перекофигурировать миллионы серверов, и совершить множеству других сопуствующих действий в подобных масштабах. Это тупо дорого, долго, сложно, и не стоит полученных преимуществ. Есть возможность перевести что-то свое — переводите, никто вам не запрещает.
                                                                      +1
                                                                      Хотя async и await ещё недоступны...

                                                                      Если сильно хочется, то доступны ext-async.
                                                                        0
                                                                        Но если вы хотите знать, как выглядит современная PHP-разработка, хорошим выбором будет познакомиться с одним из двух крупнейших.

                                                                        Можно также упомянуть, что Symfony очень похож на Spring Framework из java со своей ORM Doctrine, которая является аналогом Hibernate.

                                                                        А Laravel аналог Ruby On Rails с Active Record для работы с бд.
                                                                          +1

                                                                          Очень люблю PHP, даже несмотря на все проблемы и косяки, но после 12 лет плотной работы перешел на Go, перевел основные проекты и сейчас понимаю, насколько все было сложно и тяжеловесно. После перехода на микросервисы как-то пропал драйв писать новое на PHP. Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP? А если еще на Laravel или Zend? На Go это происходит без малейшего напряга, сохраняя объектную декомпозицию и слабую связность.


                                                                          На чем вообще поднялся PHP? В 2001, задолго до эпохи VDS, были ровно две альтернативы: perl и с/с++. Причем доступен только shared-хостинг для средней компании. Допустим, если хостинг с perl еще можно было найти, то со своими экзешничками мало где можно было захоститься, если у вас нет своего сервера. И тут возникает нечто, похожее по синтаксису на C, да еще и классы/объекты какие-никакие и можно недорого "скриптик в интернете" сделать. Причем я сразу начинал на ООП писать, а народ крутил пальцем у виска, типа выпендривайся в своем С++ с объектами. Со временем как-то дозрела отрасль и до объектов :)


                                                                          Сейчас ситуация принципиально иная. Есть недорого хостинг с шелом и возможностью компиляции. Казалось бы, можно и на С/С++, но есть специальный вариант компилируемого С для веба, с интерфейсами/инкапсуляцией и огромным набором библиотек (Golang). Причем понятие фреймворка в принципе чужеродно и не приветствуется. Пакеты(библиотеки) с юниксовым подходом "одну функцию делать хорошо" и возможностью совмещать несовместимое, лишь бы набор методов/аргументов совпал. В PHP, к сожалению, нужно чтобы об интерфейсах имели представление все клиенты библиотек.


                                                                          Делаешь в проекте россыпь пакетов, в одном из которых сервер, отдельно cli-утилиты, отдельно общие части для повторного использования. И все это со скоростью нативного кода, как будто модуль для nginx написал.


                                                                          Куча кода PHP на поддержке осталась и если ничего не делать, через пару лет это перестанет работать после обновлений (приходится следить за языком, за нюансами конфига, за поддерживаемыми модулями), в то время как экзешнику без зависимостей пофиг. У меня есть микросервис-долгожитель, написанный на Go за два дня, кропает картинки, работает полтора года без перезапуска, сколько аптайм сервера. И память пока не сожрал.


                                                                          Изучать ли PHP, инвестировать ли время, писать ли новый проект — гораздо сложнее ответить на этот вопрос сейчас, чем в нулевых. Вроде и ништяков много в языке, но и альтернативы интересные появились.

                                                                            +2
                                                                            Я не хочу спорить, поскольку с основным вашим посылом полностью согласен.
                                                                            И у меня нет особого опыта на Go, но просто мне кажется вы чуть-чуть передергиваете.
                                                                            приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс

                                                                            Такая производительность обычно близка к производительности самого вебсервера (Nginx, Apache) при использовании локалки. Вот только что на своей машине проверил.
                                                                            Далее вопрос, раз уж вы называете производительность для одного языка, то желательно привести производительность и второго рядом. Но прочитав вам коммент до конца, закрадывается впечатление что вы не соизмеряли одно с другим на одинаковых задачах. А просто написали пару микросервисов на Go и вам понравилось. И возможно у вас были какие-то проекты на РНР где вас не устраивала производительность. Но это никак не отражает какие-то особые преимущества Go vs PHP.
                                                                              +1

                                                                              У меня на PHP не получилось преодолеть порог 50-70 мс отклика при минимальной нагрузке или на тестах показать больше 500-600 rps. Если речь идет не о пустом скрипте. Причем обычно счастье, если удалось утрамбовать отклик в 100 миллисекунд. От безысходности начал уже модули писать на С. На моей практике с php, если идет склейка каких-то выборок из sql/redis и очередей, плюс какая-то объектная логика, в среднем по больнице получается около 150-200 мс на среднем восьмиядерном сервере. Сверху еще передача по сети и, как правило, очень заметный по времени коннект к базе, если отдельно с этим не заморачиваться.


                                                                              На Go пишу всерьез уже примерно два года и сравниваю одну и ту же бизнес-логику, переписанную без оптимизаций. Реально уровень производительности веб-сервера. Приложение на go и представляет собой веб-сервер в виде самодостаточного экзешника, который сам плодит легковесные треды и загружает все ядра. Можно сделать сборку сайта, с навигацией, пользовательской сессией, выборкой контента из базы, развесистой маршрутизацией, до кучи закатать туда веб-сокеты и время генерации html будет около 5мс. Естественно, что это при умеренной нагрузке и примерно 95 перцентиль, причем будут изредка выбросы до 15-20мс и большая нагрузка может дать удвоение-утроение. Но даже 50мс при 2-3тыс. rps выглядят очень привлекательно (это тупо VDS за цену в пределах тысячи, на которой php не сможет участвовать в сравнении, потому что умрет раньше при меньшей нагрузке). Nginx можно не ставить, но обычно остается из за удобства подключения сертификатов и привычного конфигурирования, чтобы не нервировать админа.


                                                                              За советскую власть не буду агитировать, т.к. с PHP еще жить долго, людей нанимать не перестанут и можно в принципе не заморачиваться, но присмотреться осторожно к другим технологиям не помешает, вдруг понравится ;) Смысла сравнивать или/или совершенно нет, т.к. современный веб можно собирать из нескольких технологий, особенно с микросервисами. Больше свободы в выборе инструментов для разных задач. Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.

                                                                                0
                                                                                Спасибо за ответ. Хотя вы продолжаете в том же стиле.
                                                                                Простой РНР скрипт «Hello world» похоже не сильно отличается по скорости отдачи.
                                                                                Хорошая отсылка к соединениям к соседям (ака Redis, MySQL). Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать `SELECT * FROM users WHER id=1` и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.
                                                                                Я понимаю что концептуально бинарник всегда быстрее. Просто если поднят php-fpm и уже сидит в памяти. То на простых скриптах разница не будет в 10. раз как вы пытаетесь представить. Да при больших нагрузках в теории более «правильная» архитектура Go покажет свои преимущества. Просто, вынужден повториться, надо сравнивать одинаковые задачи. Порой проблема не в языке.
                                                                                В ваших примерах (просто пытаюсь угадать) проблема может быть во фреймворках как ни странно. Например та же Doctrine от Symfony может очень сильно влиять на производительность и длину отклика если сравнивать с кодом написанным на том же PHP, но вызывающим MySQL напрямую без ORM. Есть очень серьезные проекты которые работают на PHP и имеют персентиль ниже 50 мс на проде с очень сложной логикой под капотом.
                                                                                Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.
                                                                                Можете дать ссылочку на MVC framework для Go? какой-то аналог Symfony или Laravel?
                                                                                  0
                                                                                  Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать SELECT * FROM users WHER id=1 и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.

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


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


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


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

                                                                                    0

                                                                                    А какая разница пользователю блокирующе будет исполняться SELECT или нет, если ему нужен ответ?

                                                                                      0

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


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


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

                                                                                      image


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

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

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


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

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


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

                                                                                            0

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

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

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


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


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

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

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

                                                                                                Бессмысленна она только если у нас однопоточная однопроцессная модель исполнения. В fpm точно не такая, в mod_php вроде тоже. Внешний диспетчер организует очередь запросов и передаёт их хэндлерам по мере обработки. Если надо, то форкает-убивает процессы. На уровне языка навскидку никакой поддержки не надо и только минимальная поддержка на уровне приложения (если оно грамотно написано, конечно), только на уровне диспетчера типа fpm значимые изменения.


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

                                                                                                Да :) Только тупанул, не проснулся ещё, не сокеты, а потоки, стримы. Через stream_select организуем наблюдение за пулом неблокирующих операций.

                                                                                    0

                                                                                    На простых тестах и единичных запросах все хорошо работает. Под бенчмарками с минимальной параллельностью съезжает до неприличных значений. К сожалению, в php очень дорогой вызов функции. Иногда прямо ломает лишний метод выносить, хотя было бы красиво. Я как раз приводил примеры реальной логики из реального проекта, специализированного поисковика, где нет текстовой шаблонизации и основная задача — выборка из быстрого хранилища и манипуляции хеш-массивами. По сути молотилка по формулам, которую уже некуда дальше оптимизировать. Просто описал свой опыт портирования практически один к одному. Это был первый реальный проект, который люди в теме еще и раскритиковали справедливо за расточительность в аллокациях памяти. Можно было взять железо помощнее, вынести что-то в модули, как сделал Фалкон. Или вот так вот тупо переписать. Дальше уже потихоньку втянулся, параллельно разрабатывая на php.


                                                                                    По поводу MVC вопрос дискуссионный. Фреймворки есть, но это немного не в стиле Go. Самый известный ORM — это, имхо https://gorm.io Лично мне такой подход к базе не нравится, но ORM таки есть. Для маршрутизации запросов хорошо зашел аскетичный https://github.com/gin-gonic/gin


                                                                                    Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы. Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу. Это дает просто немыслимую свободу в проектировании отдельных кирпичей с низкой связностью. Смысла нет создавать комбайн для всего в одном флаконе — для этого есть целый гитхаб пакетов на любой вкус, зачастую взаимозаменяемых. https://github.com/avelino/awesome-go

                                                                                      0
                                                                                      К сожалению, в php очень дорогой вызов функции.

                                                                                      Моя точка зрения состоит в том, что эти потери никак не влияют на время отклика, а если влияют то они измеряются в десятках процентов, а не в сотнях и не в разах, как вы пытаетесь представить. Именно это я называю передергиванием.
                                                                                      Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы.
                                                                                      Именно. И именно это я и имею в виду, когда прошу вас предоставить какие-то тесты и доказательства, когда вы взяли голый РНР и голый Go, написали на них простую или немного непростую вещь, и получили результате отклик на Go 5ms vs PHP 50ms через тот же вебсервер.
                                                                                      Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу.
                                                                                      Мне кажется это один из принципов в любом языке поддерживающим ООП. И РНР один из них. Никаких проблем с использованием интерфейсов я не замечаю. Или вы не пытаетесь сказать что это есть в Go но нет в PHP?
                                                                                        0

                                                                                        С интерфейсами интересная ситуация. В PHP интерфейс — это некая декларация с полным неймспейсом. Я не могу в неймспейсе потребителя интерфейса описать интерфейс локально, а подставить посторонний объект, который ничего не знает об этом объекте/интерфейсе. Интерфейсы должны быть описаны "глобально" и видимы всем, кто реализует и использует. Не уверен, давно не проверял, можно ли подсунуть объект под интерфейс, если он в цепочке наследования не заявляет implements. Кажется нет. Поправьте пожалуйста, если это не так.


                                                                                        В Go я могу локально объявить "методу нужен интерфейс publisher, который состоит из одного метода Publish()". Далее абсолютно любые объекты с методом Publish() могут быть переданы как аргумент и пролезут сквозь проверку типов. Автор объекта даже не знает, что реализовал интерфейс publisher, потому что для меня это требуемая зависимость, а для автора часть какого-то другого набора методов. В PHP для этого надо интерфейс сделать глобальным и заставить всех причастных сослаться на один и тот же неймспейс. Поэтому в PHP и слипаются во фреймворки наборы полезных объектов, из за необходимости поддержания единой иерархии зависимостей.

                                                                                          +1
                                                                                          Go очень гибок в этом плане, но пых более понятный чтоли. В пыхе интерфейс объявляется на стороне потребителя, как его декларация необходимых ему зависимостей. Можно взять любую реализацию publisher-а и запилить адаптер. Все прозрачно и ясно.
                                                                                            0

                                                                                            Для меня такая утиная типизация выглядит небезопасной. Мало ли для чего предназначен метод Publish в подключенном модуле. Навскидку: событие, перевод публикации из черновика, постинг в соцсеть

                                                                                              0
                                                                                              One more thing, в мире PHP есть PSR-ы и их уже довольно много. Самый банальный пример — логгер.
                                                                                              Подключаем пакет с интерфейсом логера и пишем свои логи опираясь только на этот интерфейс. В качестве реализации можем подсунуть любую реализацию логера, которая PSR-соместимая. Да, интерфейс должен быть у всех один и тотже, в том же неймспейсе, но он и будет одинаков, потому тчо вынесен в отдельный пакет, который и автор логера и потребитель может себе подключить.
                                                                                                0

                                                                                                Чтоб понятней было добавлю: Общий интерфейс для сервиса и клиента разработан третьей стороной и лежит в совсем отдельном неймспейсе, о котором знают и клиент, и сервис.

                                                                                    +1

                                                                                    У меня вот сложилось впечатление, что Go хорошо подходит для инфраструктурных вещей, а вот для серьёзной бизнес-логики, именно для моделирования бизнес-процессов, сложных флоу, часто описанных в BPM нотациях или UML, с активной работой с БД на уровнебизнес-терминов. а не строк/записей, системі уровня ERP/CRM он как-то не очень, не хватает полноценного ООП, хотя бы как в PHP4 :) Есть основания так считать?

                                                                                      +1
                                                                                      Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP?
                                                                                      Можно, постоянно так делаем :) Как раз с помощью Go.
                                                                                        0
                                                                                        Да всё возможно. Простой тест go fasthttp VS php libevent
                                                                                        Заголовок спойлера
                                                                                        image

                                                                                        P.S. в fasthttp на 1 заголовок больше приходит, не совсем честно. Могу согласится, что пхп всего ненамного медленнее

                                                                                        У меня есть сервис на основе этой библиотеки, скоро отмечу 8 месяцев без перезапуска. Редко когда отвечает более чем за 3мс. Да, не использует базу, но активно юзает винт. Память не утекает
                                                                                          0
                                                                                          Могу согласится, что пхп всего ненамного медленнее

                                                                                          Эээ… Либо я слепой и в тестах, кажется, всё чуть-чуть наоборот? Или я просто сарказма не понял?


                                                                                          P.S. Ходят слухи, что uv побыстрее libevent будет. Но это только слухи.

                                                                                            0
                                                                                            Я поленился добавить 1 HTTP заголовок в тесте c пхп, объём переданных данных отличается.
                                                                                            По факту, libevent наравне с go. Но латенси приятно радует

                                                                                            Про uv. Слухи лично подтвердить не могу, у меня получилось медленнее. В ближайшее время планирую использовать эту библиотеку на личном проекте. В этой библиотеке столько всего вкусного…

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

                                                                                    Самое читаемое