company_banner

PHP 8: чего ждать. Письмо Зеева Сураски

https://externals.io/message/102415
  • Перевод


Привет, меня зовут Николай Крапивный, я руковожу отделом server-side разработки в Badoo. В Badoo PHP —  один из основных языков, на нем написана бóльшая часть бизнес-логики нашей системы. Поэтому мы следим за новостями из мира PHP, активно участвуем в развитии языка и стараемся развивать сообщество вокруг PHP.

Сегодня я бы хотел поделиться переводом письма Zeev Suraski, одного из основателей Zend Technologies, которое обрисовывает дальнейшее развитие PHP и проливает свет на то, чего нам ждать в PHP 8.


Я собирался написать об этом немного позднее, но раз уж подняли тему PHP 8, похоже, пришло время начать обсуждение.

Подчеркну: цель этого письма — не обсудить в подробностях каждое упомянутое мною изменение, а скорее закрепить наши планы: собираемся ли мы после 7.3 сосредоточиться на PHP 8, в основе которого лежат некоторые из наших исследовательских проектов и экспериментальные разработки.

Есть ряд направлений, на развитие которых, как мне кажется, нужно направить ресурсы в следующей основной версии.

JIT


Вероятно, многие из вас знают, что мы потратили много сил на реализацию JIT поверх инфраструктуры PHP 7. Есть хорошие и плохие новости. Хорошие: как и в случае с экспериментами с JIT, которые мы проводили в 2014-м, мы получили впечатляющие результаты бенчмарков с интенсивными нагрузками на CPU. А плохие новости в том, что JIT по нашим тестам не дает большого выигрыша на типичных веб-нагрузках.

Иными словами, в отличие от ситуации в 2014-м, мы считаем, что JIT не улучшит производительность при обработке типичных рабочих веб-нагрузок, поскольку исполнение PHP-кода больше не является узким местом.

Но я по-прежнему считаю, что нам нужно включить JIT в следующую основную версию PHP. Как минимум по двум причинам:

  • Это позволит PHP обрабатывать новые типы рабочих нагрузок (не веб).
  • Это позволит написать для PHP новую встроенную функциональность, которая повысит безопасность кода (например, PHP-реализацию unserialize() вместо версии на C).

Кроме того, всегда есть вероятность, что мы что-то упускаем в своих бенчмарках, и что существуют веб-нагрузки, обработка которых ускорится (прим. Badoo: хороший пример. На нашем масштабе потребление CPU критично, мы достаточно много занимаемся оптимизацией потребления CPU и обычно сильно выигрываем от оптимизаций языка).

Стоит отметить, что, по всей вероятности, в рамках работы над JIT мы захотим сделать OPcache (или хотя бы его большую часть) элементом основного движка, а не отдельным расширением.

  • (Бонус) в сочетании с некоторыми другими разработками, это всё-таки может улучшить производительность веб-приложений.

Чтобы вы понимали, о каком приросте производительности идёт речь, я записал сравнение бенчмарков PHP 7.0 и экспериментальной JIT-разработки: https://www.youtube.com/watch?v=dWH65pmnsrI

Асинхронность


Мы должны сконцентрироваться на улучшении поддержки долгоживущей (long-running), асинхронной модели исполнения, ориентированной на микросервисы. Вероятно, не секрет, что одной из главных причин популярности Node.js является его умение очень эффективно обрабатывать огромное количество одновременных подключений, генерирующих относительно лёгкие запросы. Это хорошо соответствует особенностям современных микросервисных архитектур. Есть уже несколько проектов, которые реализуют в PHP аналогичную функциональность, например, ReactPHP и более свежий Swoole.

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

Интерфейс внешних функций (Foreign Function Interface)


Это позволит подключать PHP к нативным библиотекам, написанным на С или С++, без необходимости создавать расширение. Я понимаю, это может выглядеть не сильно лучше, чем расширения, но если оценить не только сложность реализации, но и возможное влияние этого нововведения, то станет понятен его масштаб. Это позволит гораздо чаще использовать PHP в сочетании с «передовыми» технологиями, такими как искусственный интеллект и машинное обучение; да и не только с уже существующими сегодня — это своеобразный «задел» для использования в будущем с технологиями, которые будут появляться. Дмитрий (прим.: Дмитрий Стогов) уже добился определённых результатов в этом направлении. Последние пару недель он потратил на создание биндингов TensorFlow для PHP, и написал, судя по всему, первую нейросеть на PHP: она распознаёт рукописные цифры с точностью 98%. Думаю, что в сочетании с JIT это превратит PHP в настоящую рабочую лошадку для исполнения тяжёлых приложений, не ставя под угрозу продуктивность разработчиков. Кстати, чтобы этот механизм работал действительно быстро (особенно в паре с JIT), мы, скорее всего, объединим его с основным движком, а не будем делать его отдельным расширением.

Поддержка предзагрузки


Мы обсуждали это несколько раз на высоком уровне, но если внедрим JIT в PHP 8, то поддержка предзагрузки может неплохо его дополнить. Она позволит разрабатывать «расширения» на PHP, а не только на С (или FFI). В сочетании с JIT стоимость написания логики на PHP сильно упадет, и это будет лучше с точки зрения и простоты и безопасности. Кроме того, предзагрузка может значительно повысить скорость работы веб-приложений, поскольку мы сможем разрешать определённые зависимости (в основном, наследование) именно в ходе компилирования, а не исполнения. (прим.: Дмитрий Стогов дал нам более конкретное описание этой идеи: «Идея — загружать PHP-скрипты при старте PHP; функции и классы, определённые в них, будут доступны всем request-ам без всяких include/require. По сути, это даёт возможность писать стандартные библиотеки на PHP». Обсуждение этого можно почитать тут.)

Замечу, что этот список:

  • Неполон. Если здесь не упомянута какая-то фича, это не означает, что её не будет в PHP 8.
  • Не высечен на камне. Нам, конечно же, нужно иметь RFC по каждой упомянутой идее, но мы можем не справиться с реализацией каких-то из этих идей.

Этот список — ряд направлений, в которых мы провели определённые исследования (в некоторых — даже очень серьезные, как в случае с JIT), и которые являются прочной основой для начала дискуссии о PHP 8 и превращения PHP 7.3 в последний релиз в семействе PHP 7.x. Если бы нам пришлось на основе всего вышеупомянутого сформулировать предположения о сроках готовности PHP 8 к выпуску, то, вероятно, это будет через 2—2,5 года (то есть середина/конец 2020-го). Также можем обсудить очень скромный релиз PHP 7.4 где-нибудь в 2019-м, в котором не будет добавлено нового функционала, но который позволит нам объявить устаревшим (deprecate) всё, что действительно того заслуживает, и что мы забыли объявить устаревшим в PHP 7.3, чтобы позволить всем заранее подготовиться к PHP 8.

С помощью этого письма я хотел бы понять отношение к переносу усилий на создание PHP 8 после релиза 7.3, а также послушать ваше мнение о вышеописанных фичах. Если отзывы будут положительными, думаю, следующим шагом станет написание RFC «PHP 8 как следующий feature-релиз PHP», с возможными положениями о 7.4; а затем отдельные обсуждения всех вышеупомянутых (а также других) нововведений. Можем попробовать сформулировать некий график, но какие-то пункты могут быть сдвинуты вправо (до определенного предела), если их исследование/разработка/доводка потребует больше времени.

От себя добавлю, что радостно видеть активное развитие языка в последние годы и здравое стремление команды работать как над производительностью, так и над «генерализацией» языка и улучшением его возможностей. Все направления работы выглядят многообещающими, особенно интересными для нас являются улучшения потребления CPU и возможность работы с асинхронным вводом-выводом.

А что вы думаете об описанных планах на PHP 8 и перспективах PHP в целом? Делитесь вашими мыслями в комментариях.

Badoo

292,61

Big Dating

Поделиться публикацией

Похожие публикации

Комментарии 252
    +11
    Так ещё немного и php начнут использовать в качестве встраиваемого скрипт-движка вместо python или lua…
      +2
      А почему бы, собственно, и нет?
        +7

        Потому, что в php перед каждой переменной надо ставить знак доллара ))

          +10
          Много долларов — это плохо?
            +2
            это перл и шелл :)
              0

              В Perl, это нечто большее, чем просто обозначение переменной, — это обозначение скалярной переменной и часть системы типизации. На ряду с $, переменная может содержать впереди себя @ или % что означает соответственно список (массив) и хеш (ассоцированный массив). Что в частности позволяет например писать $h{@a} = @b — что означает: присвоение ключам ассоциированного массива %h списка значений заданных массивом @b причем список имён ключей соответственно задан масивом @a. И т.п.

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

                мечта — красивый и краткий способ записывать ещё и генерики :)
            –8
            Для чего в PHP сделали чтобы надо было знак доллара перед переменными писать, почему нельзя было сделать без него, как в других языках?
              +10
              Действительно! А ведь это главная и единственная причина, почему PHP так ненавидят и закапывают уже 20 лет!
                0

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

                  +2
                  Во-первых, это был сарказм. Во-вторых, она мешает только тем, кто не пишет на PHP (или пишет редко). В-третьих, придираться к синтаксису языка — это последнее, к чему в принципе стоит придираться, и стоит ли вообще? Аналогично можно придираться к тому, что после Питона забываешь про точки с запятыми в других языках. Это всего лишь вопрос привычки
                    0
                    Во-вторых, она мешает только тем, кто не пишет на PHP (или пишет редко)

                    Тем, кто не пишет на php, необходимость ставить доллар перед переменными в php не мешает )). А вот тем, кто пишет — логичным образом мешает.


                    В-третьих, придираться к синтаксису языка — это последнее, к чему в принципе стоит придираться, и стоит ли вообще?

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


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

                    Необходимость ставить доллары перед переменными мешает, когда пишешь код на php, поэтому ваша аналогия тут не применима.

                      –1
                      Они нужны для парсинга. Нельзя просто взять и убрать.
                        0

                        после введения AST можно. но, как минимум из-за обратной совместимости такое изменение делать нецелесообразно.

                          0

                          Можно просто метить файлы, в которых переменные без доллара. Чем-нибудь в первой строчке. А остальное парсить как раньше.

                        0
                        Не мешает этот знак доллара, когда ты пишешь на PHP достаточное время. Особенно с нынешними инструментами IDE.

                        Остальные аргументы об это убиваются. Если основной язык — другой, и периодически приходится переключаться, то безусловно это вносит неудобства, именно поэтому я и привел в пример Python с его «точкой с запятой». Лично для меня было бы удобно не использовать точку с запятой, если бы я использовал этот язык в качестве основного, НО как только я переключусь на любой Си-подобный, мне это будет доставлять дискомфорт.

                        Но речь о другом.

                        В дискуссиях ниже, Вы сами же объяснили, почему $ появился в этом языке, а теперь представьте, что разработчики языка, на котором Вы пишете несколько лет, взяли и поменяли синтаксис.

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

                          если удастся сделать так что бы небыло коллизий с константами — то не вижу проблемы. Отказ от $ в названии переменной не будет вызывать большого нарушения обратной совместимости.


                          Но это уже что-то вроде "традиции". Никто уже это не будет фиксить. Да и нужды нет.

                            0
                            про то и речь, я не говорю, что это сложно. Более того, я не знаю — сложно или нет.

                            И как Вы правильно заметили «нужды нет», потому что на самом деле — это самые последние из «проблем», которые есть у PHP, а те коллеги, которые цепляются именно к $ просто не могут объяснить реальные проблемы, которые есть у языка (а они безусловно есть, как и у любого другого).

                            **Update**
                            речь не только про обратную совместимость языка. Представьте, что команде JetBrains нужно будет переделывать PhpStorm, убирая оттуда подвязки к $, к поиску по этому символу (который, как отметили в последних комментариях может сокращать список возможных значений при автозаполнении), и так далее для остальных IDE, гайдов, книг и т.д.

                            Новичок в 2020 году покупает книги, читает статьи по языку, который не имеет $ в синтаксисе, хотя везде говорится об обратном.
                              0
                              те коллеги, которые цепляются именно к $ просто не могут объяснить реальные проблемы, которые есть у языка

                              Видите, какое дело. То, что проблему никто не собирается исправлять, потому что к ней все привыкли — не делает её не существующей. И тот факт, что она существует, но нередко её существование не признают, или вообще называют проблему фичей, меня изрядно удивляет.

                                0
                                не делает её не существующей

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

                            0
                            Не мешает этот знак доллара, когда ты пишешь на PHP достаточное время.

                            Ко всему со временем привыкаешь, это известный феномен. Вот, например, Робу Пайку не мешает отсутствие подсветки синтаксиса, и он не один такой.


                            Остальные аргументы об это убиваются.

                            Как об это убивается аргумент, что необходимости ставить доллар перед переменной объективно нет? Что это не несёт никаких плюсов и только увеличивает вероятность поймать туннельный синдром?


                            В дискуссиях ниже, Вы сами же объяснили, почему $ появился в этом языке, а теперь представьте, что разработчики языка, на котором Вы пишете несколько лет, взяли и поменяли синтаксис.

                            Если бы речь шла о том, что значок доллара больше не нужно ставить, я бы обрадовался.


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

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

                        0
                        Жесть конечно, но ведь круто
                        $p1 = 'Привет';
                        $p2 = 'Пока';
                        $property_name = $_GET['property'];
                        print($$property_name);

                        localhost?property=p1
                        Привет

                        localhost?property=p2
                        Пока

                        Попробуйте в другом языке через значение переменной обратиться к другой переменной по имени.

                          0
                          Попробуйте в другом языке через значение переменной обратиться к другой переменной по имени.

                          Возможность интересная, но для её реализации достаточно попросить пользователя поставить один доллар перед property_name, когда хочешь через неё обратиться к другой переменной.

                            +2
                            #!/usr/bin/perl
                            $v = 'first';
                            $first = 'second';
                            print $$v;
                              +1
                              Да почти в в любом динамическом языке способ есть:
                              Питон например:
                              locals()[var]
                              

                              Даже думаю что в C++ можно сделать если захотеть
                                0
                                Нельзя
                                  0

                                  основы языков программирования. У вас есть динамические языки (php, js, python, etc) и статические (C++, D, Haskell).


                                  Статические — это значит что информация о типах доступна в компайл тайме. Динамические — только в рантайме.


                                  В вашем примере нам неизвестно значение var. Существуют языки которые могут описать это типами что позволит проверить корректность в компайлтайме


                                  type data = {
                                      foo: string
                                      bar: number
                                  }
                                  
                                  const locals = () => data
                                  let v: keyof data | null = null
                                  locals()[v] // можно проверить в компайлтайме

                                  В теории это можно замутить на темплейтах, но зачем вообще так делать?)

                                  0
                                  Для этого есть хеш-таблицы. Более того, я не знаком с внутренним устройством PHP, но, скорее всего, в приведенном вами случае тоже используется хеш-таблица.
                                    0

                                    В том и суть. Это сахар. PHP не заставляет задумываться что тебе нужно (массив, список, справочник или даже объект), Ты можешь изголяться как хочешь:


                                    • Объект в массив? Легко!
                                    • Цикл по объекту? Без проблем!
                                    • Извлечь массив в переменные(по ключам)? Всего 1 комманда.
                                    • Добавление свойств классу на лету.
                                    • Конкатинация по отдельному символу для избежания затыков уровня JS.
                                    • Полноценное ООП

                                    Не язык, а мечта мага.


                                    Но ещё хотелось бы увидить пару фишек, например из питона:


                                    • именнованая передеча переменных в функцию
                                    • удобный выбор диапазонна в массиве
                                    • ну и кудаже без многопоточности
                                      +1
                                      PHP не заставляет задумываться что тебе нужно (массив, список, справочник или даже объект), Ты можешь изголяться как хочешь:
                                      Объект в массив? Легко!
                                      Цикл по объекту? Без проблем!

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

                                        +1
                                        Полноценное ООП

                                        а дайте ка определение

                                +1
                                Это Вы ещё Perl не видели
                                  +1
                                  П-с-с-с. Q-Basic.
                                    0
                                    В QBasic "$" стоял после переменной строкового типа, это был суффикс, а не префикс.
                                      0
                                      Именно это и имелось в виду. Плюс в стандартных функциях, возвращающих строку, если я правильно помню.
                                    0
                                    там еще % и @
                                    +4

                                    Исторически сложилось. Делалось для того, чтобы было удобно вставлять переменные в строки. Тогда никто не предполагал, что php станет настолько успешным и развитым языком, что доллары перед переменными на самом деле будут мешать.

                                      +4
                                      Совершенно непонятно, чем мешает знак доллара перед переменной. Может, объясните? Потому как мне не мешает, скорее даже наоборот.
                                        0

                                        Тем, что перед тем, как применить переменную в коде, нужно набрать символ, набор которого требует зажать шифт. Это особенно неприятно потому, что никакой объективной необходимости в этом нет и никаких преимуществ это не даёт.

                                          0

                                          Вводится одной рукой — не вижу неприятностей. К тому же, никто, вроде, не мешает использовать какую-нибудь раскладку, где доллар без шифта.

                                            +1
                                            Вводится одной рукой — не вижу неприятностей.

                                            Вообще не рекомендуется набирать одной рукой комбинации, которые включают в себя 2 и более символов. Но в общем и целом гораздо лучше вообще не набирать символ, в наборе которого нет совершенно никакой объективной необходимости.

                                              0
                                              не рекомендуется набирать одной рукой комбинации

                                              А вот тут можно подробней? alt+shift тоже к этому относятся? А заглавные бувкы?

                                                0

                                                Alt+Shit двумя руками зажать не проще, чем одной из-за неудобного расположения клавиш, увы. Кроме того, как правило, нужно зажимать Alt+Shift и ещё какую-то кнопку и тут уже совсем не возможно нажать одной рукой не больше одной кнопки.


                                                К заглавным буквам рекомендация относится без оговорок.

                                                  0

                                                  я чет не очень понял… зачем двумя руками если можно одной? Это как-то связано с нагрузкой на запястье? Купите себе нормальную клавиатуру может...

                                                    0
                                                    зачем двумя руками если можно одной?

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


                                                    Купите себе нормальную клавиатуру может

                                                    Что порекомендуете?

                                                      0
                                                      Для знака доллара это вполне себе актуально.

                                                      да как-то не особо

                                                        0

                                                        Что за клавиатура?

                                                          0

                                                          макбуковская родная, ничего примичательного. есть поинтереснее варианты где удобнее рука лежит. Но именно $ набирать в целом комфортно.

                                            +2
                                            На мой взгляд, код читается лучше. Всегда понятно, где переменные, а где что-то еще. Набирать, при этом, совершенно не напрягает. Ну и плюс выделение переменной даёт всякие парсинговые вещи, вроде подстановки переменной в строку.
                                            Я был бы против того, чтобы его убрать.
                                              +1
                                              На мой взгляд, код читается лучше. Всегда понятно, где переменные, а где что-то еще.

                                              Если писать код в блокноте, то в ваших словах есть определённая часть правды. Но сейчас код пишут в основном в IDE, там, благодаря подсветке, таких проблем нет.


                                              Набирать, при этом, совершенно не напрягает.

                                              Субъективно, понятно, что не напрягает, а объективно есть необходимость набирать дополнительный символ.


                                              Ну и плюс выделение переменной даёт всякие парсинговые вещи, вроде подстановки переменной в строку.

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

                                                +1
                                                вроде подстановки переменной в строку

                                                "Some $var" //можно
                                                "Some other {$this->var}" //можно
                                                "use some {constant}" // нельзя

                                                вот так появляется неконсистентность языка. И это много хуже.

                                          0
                                          так никто и не делал. исторически из перла перешло, куда из шелла :)
                                            +5
                                            Ну классика же:
                                            image
                                            Похоже, после каждого «Нам нужны значки, чтобы пояснять, о чём речь!» приходит озарение «Постойте, слова и сами справляются».
                                              0
                                              шутка такая есть — в перле используется вся клавиатура :)

                                              в руби вот нашли интересное применение символам…
                                              замена для this например… имхо както нетривиально. вобще язык хиптерский получился
                                              0

                                              Я вот не понимаю этого шума вокруг знака $. Не припомню чтобы мне когда либо мешал этот символ.


                                              Скажу даже больше. Некоторым не хватает $ в других языках. Довольно часто встречаю случаи когда JavaScript разработчики используют $ в имени переменных (сам так не делаю). Поначалу мне думалось, что это php программисты переносят свои привычки в js, но сейчас так пишут код даже чистые фронтендеры, которые php в глаза не видели. Возможно это просто последствия.


                                              Хотя есть свой смысл в использовании $ в контексте js. Например, в следующем примере без контекста невозможно понять, bar это переменные с некоторым значением или название функции, а foo это название функции или ссылка на функцию.


                                              foo(bar);

                                              Следующие примеры более очевидны


                                              foo($bar);
                                              $foo(bar);
                                              $foo($bar);

                                              И не подумайте. Я не поддерживаю идею использования $ в js.


                                              Сейчас набегут хейтеры и скажут, что это недостатки самого языка и писать надо на питоне)))

                                                0

                                                Ну, в JS долларом удобно отделять «обычные» переменные от объектов jQuery, например. Если, конечно, на проекте используется jQuery)

                                                  0
                                                  Отсюда, видать, растёт фобия к PHP: с долларов начинаются джунгли
                                            0
                                            Руководства нет готового. Но раз есть модуль под apache, то штатный способ встраивать php в свой процесс должен быть. Надо будет покопать исходники апача.
                                              +1
                                              Честно, не хочется вникать глубже, но вот сходу нашёл:

                                              aptitude show libphp7.0-embed

                                              This package provides the library /usr/lib/libphp7.0.so which can be used by application developers to embed PHP scripting functionality.

                                              The following extensions are built in: Core date filter hash libxml openssl pcntl pcre Reflection session SPL standard zlib.

                                              PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

                                              WARNING: The embed SAPI is experimental and there's no guarantee that the API/ABI will be kept compatible even between minor releases. You have been warned.
                                              –12
                                              Может потому, что PHP — сломанное и и плохо продуманное #####?
                                                +1
                                                Плохому танцору… Жизнь — боль. Нет во всех отношениях хорошего языка, везде есть проблемы. А ещё легаси для обратной совместимости, которое часто мешает.
                                                  0
                                                  Согласен, но я лично считаю, что это — один из худших языков программирования.

                                                  Раз, два, и т.д.

                                                  Конечно же, есть wiki.theory.org/index.php/YourLanguageSucks, но всё же видно, что у PHP недостатков очень много.
                                                    +3
                                                    Ну это ваше личное мнение. А у кого недостатков нет? Не, ну серьёзно, кто-то когда-то начал собирать странности и особенности PHP, остальные подхватили и теперь такая мощная пропаганда, что PHP — гадость. Особенно радует, когда люди апеллируют к «фракталу плохого дизайна». Статье, написанной в мохнатые времена, когда в ходу была ещё версия 5.1, Laravel не сущестовал даже как проект, а Symfony был… ну не будем об этом.

                                                    Если вам не нравится этот язык, его экосистема и инфраструктура, ну не программируйте на нём. Делать вброс вида «php sucks», имхо, не стоит. Уж хотя бы обосновали бы мнение своим личным опытом, не опытом постороннего дяди.

                                                    Я искренне желаю вам получать удовольствие от работы с тем инструментом, который вам нравится и с которым готовы прожить остаток жизни (не сарказм) :)
                                                      0
                                                      Согласен, немного переборщил. :)
                                                  +3
                                                  Поработал я как-то с джавистами… и передумал уходить с пхп без везких аргументов на то — проблемы они не в языке, а в тех, кто его использует.
                                                    0

                                                    И самое главное — как используют!
                                                    Кто-то жаву для веб-сервисов, кто-то пхп для GUI...

                                                      +1

                                                      Почему-то у вас в примерах джава программисты адекватные, а пхпшники какие-то безумные.

                                                        0

                                                        А почему бы не использовать Java для веб-сервисов?

                                                  0

                                                  Реализовывал уже году в 2006. Привинчивалось к Delphi 7 ;))))

                                                    0
                                                    Аминь
                                                    –32
                                                    Можно закапывать
                                                      +23
                                                      PHP закапывают уже лет 10 если не больше. А он всё живой.
                                                        +12
                                                        Больше, однозначно больше. Когда я десять лет назад его только начинал изучать — его к тому времени тоже уже давно закапывали.
                                                          +11
                                                          не меньше 20, с 1997, выход ASP.NET, котрый обещал похоронить пхп. Ну и дальше по списку хоронильщиков — РубиРельсы, Питон, Нода…
                                                            0
                                                            Не рой яму, бо сам упадёшь...)
                                                              +1
                                                              пока не упали.
                                                          +1
                                                          Пока что я вижу как PHP сам закапывает Ruby с его рельсами, а теряет разве что в специфичных местах, когда появляются лучшие инструменты. Микросервисы, к примеру. Однако, в статье о том и говорится, что над языком работают в сторону того, чтобы и эти задачи он начинал выполнять также хорошо.
                                                            +1
                                                            В каких проявлениях вы это видите? Я лично не встречал историй перевода проектов с Ruby на PHP, а только наоборот.
                                                              0
                                                              это потому, что после того как оно написано на руби, переводить уже нечего :)
                                                                0
                                                                В смысле проект загнулся?
                                                            –1
                                                            Windows must die
                                                            0
                                                            Клёво, ждём…
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                +25
                                                                Давайте будем всё делать по порядку: сначала 8, а потом 10.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    Iphone 10 с этим не согласен
                                                                    0
                                                                    Стоп, а миллениум я когда пропустил?
                                                                    0
                                                                    6 уже пропустили, не так же часто. Правильно выше написали — теперь только 9 пропускать.
                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                        +1
                                                                        Лучше все непростые. 7, 11, 13…
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                        +1
                                                                        6 не пропустили. PHP6 разрабатывался, но так и не релизнулся.
                                                                      0

                                                                      Диковатая мысль в голове — трансляция в WebAssembly. И тогда PHP начнёт просачиваться в браузеры :)

                                                                        +4
                                                                        Уже начал github.com/oraoto/pib
                                                                          0
                                                                          > Known issues
                                                                          >
                                                                          >Memory leak

                                                                          Их тестовая страница стабильно выгружает мне Chrome Android
                                                                          0
                                                                          Почему же диковатая? Сам давно копаю на досуге в эту сторону.
                                                                          +2
                                                                          В 5 раз быстрее работает на этом бенчмарке
                                                                          Выглядит многообещающе (и бенчмарк, и сама статья)


                                                                            +3
                                                                            Может быть пора наводить порядок в именах bundled функции? Добавить новые с унифицированными именами и задепрекейтить старые в 7.3-7.4
                                                                              +10
                                                                              Не не. Я спустя несколько лет наконец запомнил порядок аргументов в array_map и array_filter. Пусть оставляют как есть.
                                                                                0

                                                                                хотите лайфхак как быстрее запомнить?


                                                                                в array_map второй аргумент на самом деле variadic. А в reduce/filter — нет.


                                                                                function zip(array ...$arrays) {
                                                                                    return array_map(null, ...$arrays);
                                                                                }
                                                                                zip([1, 2, 3], ['a', 'b', 'c']); // [[1, 'a'], [2, 'b'], [3, 'c']]
                                                                                  0

                                                                                  Зачем вообще запоминать, если Шторм подсказывает?

                                                                                    0
                                                                                    Потому что всё равно будет мини-запинка при каждом обращении к такой функции. Да, Шторм покажет, но это всё равно чуток собьёт плавный процесс написания кода. Совсем чуток, но собьёт. А таких запинок может быть очень много раз за день. Может и небольшая проблема, но во многих других языках можно писать вообще не спотыкаясь об такое. Соответственно писать приятнее.
                                                                                      0
                                                                                      очень много использований array_filter/array_map в день — признак плохого дизайна кода. Неплохо было бы поревьювить код и подумать — может пора юзать объекты вместо массивов?
                                                                                        0

                                                                                        И получим мы массив объектов, который нужно так же обрабатывать. Не, можно конечно запилить коллекции, но там уже внутри коллекции будет filter/map…
                                                                                        А еще нужно не забывать про легаси, которое нельзя вот сразу взять и сделать идеальным, вот и приходится городить… Ну и про хайлоад не стоит забывать, где оборачивание строки в объект чтобы было удобнее слишком жирно.

                                                                                          0
                                                                                          признак плохого дизайна кода.

                                                                                          мне кажется в вашей логической цепочке пропущены важные штуки. Если объекты будут использоваться вместо массивов (коллекции например) как это избавит код от map-ов и редьюсов? Что будет внутри вместо?


                                                                                          Словом, поясните свою мысль.

                                                                                            +1
                                                                                            Так там кроме array_filter/array_map просто тьма такого.

                                                                                            Вот только сегодня столкнулся. Парсю URL:
                                                                                            $parse = parse_url($url);


                                                                                            Далее преобразовываю параметры в массив. По аналогии написал бы так:
                                                                                            $query = parse_str($parse['query']);


                                                                                            А правильно вот так:
                                                                                            parse_str($parse['query'], $query);


                                                                                            Всё это нужно либо помнить, либо вникать в подсказки IDE. А это хоть на пару секунд, но выбивает из потока. Писать уже не так приятно.

                                                                                            С другой стороны в современных PHP-проектах всё равно гораздо больше работы с библиотекой фреймворка или с новыми возможностями языка, где всё структурировано и стандартизировано, чем со стандартной библиотекой. Поэтому считаю подобное скорее досадным легаси, чем фатальным недостатком.
                                                                                              0
                                                                                              Подстройте свой поток под обстоятельства :)
                                                                                      +2

                                                                                      Предлагаю вам написать соответствующее расширение

                                                                                        +1

                                                                                        зачем, в статье ж говорится что будет прелоадинг кода, можно просто на php как композер пакет.

                                                                                          +2
                                                                                          Снимаю шляпу. Так гораздо мобильнее.
                                                                                          Осталось реализовать и нахватать звезд гитхаба, тем самым повлияв на дальнейшую разработку php, как это делает Phalcon
                                                                                            0
                                                                                            но никто не пишет, все просто ноют.
                                                                                              –3
                                                                                              А всё потому, что у всех php разработчиков лапки
                                                                                        0
                                                                                        Напиши свою библиотеку и все. Я например для массивов и строк себе такую сделал.
                                                                                        +1
                                                                                        PHP хороший язык не потому что академический, а потому что он имеет кучу полезных в работе расширений, которые можно использовать сразу из коробки. Пока этого не поймут остальные PHP будет спокойно наблюдать как гаснут звёзды. (Если конечно не найдутся «добрые» люди и не добавят туда вместо практически полезного, академически нужное: шаблоны, генерики, метопрограммироване, монады и еще что-нибудь чтоб «как у всех»)
                                                                                        ps: Я бы еще добавил в стандартную комплектацию phalcon т.к. это не затратно, быстро и очень близко к тому для чего это язык применяют.
                                                                                          +1

                                                                                          И какие звёзды погасли, кроме перла? Можете перечислить?

                                                                                            +6
                                                                                            Ну, драгоценный камушек уже потускнел чутка например. Уже нет такого хайпа вокруг него, как был на старте.
                                                                                              +2

                                                                                              Вроде руби входит в 10ку наиболее востребованных языков, по версии TIOBE. Явно далеко до затухания. К тому же javascript на равных с php а до питона обоим далеко еще.

                                                                                                0
                                                                                                Яваскрипт — не конкурент php, скорее это общепринятый симбиоз.
                                                                                                  +1

                                                                                                  Так оно и было, пока фракция javascript не выпустила nodeJS.

                                                                                                    0
                                                                                                    Мне кажется они и сейчас не конкуренты. PHP и Node применяются для разных задач по сути. Как-то тут выходила статья «PHP создан чтобы умирать» — пошутили и ладно, но с другой стороны это даже «плюс» PHP, то что каждый процесс создается заново.
                                                                                                      +2
                                                                                                      PHP и Node применяются для разных задач по сути.

                                                                                                      Раскройте свою мысль. Где, где применяют php, применить node будет ошибкой?

                                                                                                        +1
                                                                                                        Если я вам отвечу, вы начнете спорить о том, что считать «ошибкой».
                                                                                                        И то и то можно использовать где угодно, но, согласитесь, для стандартного веба по типу «запрос-ответ» PHP подходит лучше Ноды: вы не заботитесь о памяти, вы не заботитесь что что-то зависнет, у него простая схема работы (веб сервер мы не трогаем сейчас, он отделен).
                                                                                                        За Нодой нужно следить: а не упало ли чего, а нет ли у нас где утечек памяти и т.п. Конечно есть свои плюсы и минусы и именно поэтому это разные инструменты.
                                                                                                          +2
                                                                                                          Если я вам отвечу, вы начнете спорить о том, что считать «ошибкой».

                                                                                                          Я не хочу с вами поспорить, я хочу понять вашу точку зрения. Однако, хочу отметить, что для того, чтобы констатировать, что php и node сейчас не конкуренты, с вами должно согласиться подавляющее большинство программистов. Иначе эти программисты будут применять эти инструменты для решения одних и тех же задач.

                                                                                                            0
                                                                                                            Моя точка зрения была изложена в самом начале: «Мне кажется они и сейчас не конкуренты» :)

                                                                                                            В целом каждый пользуется тем, чем ему удобнее решить поставленную задачу. Если вы умеете это делать на С++, то почему бы и нет? :)
                                                                                                            0
                                                                                                            Плюс в PHP есть отличная экосистема для создания веб-бэкэнда, которая значительно масштабнее, чем в любом другом языке. Хорошие фреймворки (Symfony, Laravel), библиотеки, сообщество, можно быстро получить ответ практически на любой вопрос. Для меня отсутствие нормальной асинхронности — последний рубеж, который не позволяет использовать PHP вообще для всего бэкэнда.

                                                                                                            С другой стороны, PHP уже проспали микросервисы (да и обработку Websockets без геморроя на PHP не сделать), возможно через какое-то время проспят ещё какой-нибудь юзеркейс.

                                                                                                            А по поводу того как лучше писать, if (number in [1,2,3]) или if (in_array($number, [1,2,3])), то первое конечно писать приятнее, но недостатки легаси — это такая мелочь по сравнению со всем остальным.
                                                                                                              0
                                                                                                              Ну, у меня есть сервис, у которого несколько PHP-демонов асинхронно выполняют несколько задач (пробовал и треды и процессы), «общаются» между собой вне зависимости от того на каком сервере они находятся и т.д. и т.п.
                                                                                                              Все в продакшене уже почти год и единственное, что меня не устраивает — это то, что у RabbitMQ нет возможности получить список задач очереди или включить защиту от дублей, но к PHP это отношения не имеет.

                                                                                                              Сначала хотел использовать ноду, но как оказалось на тот момент она все равно была однопоточная (для реальной многопоточности нужен был какой-то геммор), плюс… ну нафига мне плодить разные языки в проекте? Все на PHP — и вся кодовая база едина, очень удобно.

                                                                                                              P.S. Вообще «нормальную» асинхронность найти очень сложно, как мне кажется. Потому как сама по себе асинхронность сложна и всегда будут какие-то неудобства.
                                                                                                                +2
                                                                                                                Плюс в PHP есть отличная экосистема для создания веб-бэкэнда, которая значительно масштабнее, чем в любом другом языке.

                                                                                                                Заменить в вашей фразе на название любого другого языка и с ней согласится не меньше людей, чем согласилось с оригиналом.

                                                                                                          0

                                                                                                          Не весь мир — тонкие API и микросервисы.

                                                                                                            0

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


                                                                                                            Вообще по хорошему спор кто лучше тут не имеет смысла.

                                                                                                        0
                                                                                                        В РФ руби это экзотика
                                                                                                          0

                                                                                                          В Европе для руби предостаточно вакансий

                                                                                                          0
                                                                                                          по версии TIOBE руби 11 вот прямо сейчас
                                                                                                        0
                                                                                                        эта, а че это вы перл закопали то? Вон большие проекты на нем люди пилят, букинг ком (внезапно) внутри вполне себе на перле.
                                                                                                          +2

                                                                                                          Потому что, кроме легаси букинга 22 летней давности, не видно ни одного серьёзного проекта на нем. Про кобол и то больше слышно

                                                                                                      0
                                                                                                      О да, в контексте упоминания предзагрузки классов сразу думается про phalcon. Не думаю, что его включат в коробку ибо сейчас он и так как расширение ставиться без проблем.
                                                                                                        0
                                                                                                        Из действительно хороших вещей в PHP, пожалуй, только низкий порог вхождения. Еще популярность — но это косвенный фактор, исторически вытекший из низкого порога.

                                                                                                        Включение популярных расширений в ядро языка — спорное решение. С одной стороны хорошо, что при выходе новой версии авторы проверяют все на совместимость. С другой — при наличии менеджера пакетов (как npm/nuget/gem/...) гораздо легче обновлять пакеты на актуальную версию, не завися от хостера.
                                                                                                          0
                                                                                                          а я думаю что в PHP плох только синтаксис, но в остальном он уделывает все скриптовые языки.
                                                                                                            0
                                                                                                            Перечислять плохо сделанные части PHP можно очень долго — статья довольно старая, но большинство вещей из нее все еще актуальны.
                                                                                                            0
                                                                                                            Серьезно? Может быть заглянем в ядро Symfony 4, например? В 2008 может так и было, сейчас все усложнилось на порядок, буквально.
                                                                                                              0
                                                                                                              Причем тут ядро Symfony?
                                                                                                                0
                                                                                                                Сегодня никто не пишет без фреймов и половина из них по сложности выше среднего. Вы начинаете про низкий порог. Какой еще низкий порог?
                                                                                                                  +2
                                                                                                                  Не надо мешать порог вхождения в конкретный язык и ваше представление о современной веб-разработке в целом. Для PHP он действительно ниже, чем для других backend-языков.
                                                                                                                0
                                                                                                                Симфони это исключение из правил. Мне кажется они там придумывают новые слои абстракции совершенно не задумываясь нужно ли это комуто вообще. Другое дело Ларавел — прочитал несколько статей «быстрый старт», открыл справочник классов и методов и пошел писать.
                                                                                                                  0
                                                                                                                  Мне кажется они там придумывают новые слои абстракции совершенно не задумываясь нужно ли это комуто вообще.

                                                                                                                  А можете пример привести? По-моему конечного пользователя все эти абстракции не касаются

                                                                                                                    0
                                                                                                                    Поленюсь, уж простите, тащить исходники, но мне как человеку, который всегда старается сначала разобраться, как именно работает инструмент перед тем, как использовать, разбираться в исходниках Symfony — сущее наказание. Для чего так всё переусложнено — понять невозможно.
                                                                                                                      0
                                                                                                                      Я свичнулся в Symfony из Yii1 меньше чем за неделю. У меня не возникло вопроса «Для чего так всё переусложнено?». Более того, я был в восторге от изящества большей части компонентов (вот формы мне не зашли, да)
                                                                                                                        0
                                                                                                                        разбираться в исходниках Symfony — сущее наказание.

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


                                                                                                                        p.s. использую симфони 6 лет, это лучшее что есть в php, и там все плохо.

                                                                                                                        0
                                                                                                                        Для меня самой большой проблемой является то, что Сифмони заставляется меня безукоснительно следовать СОЛИДу. СОЛИД это конечно хорошо, но реальная жизнь ведь намного сложнее. Я так и не разобрался как мне дернуть чтото из базы, если я нахожусь не в контроллере. Нужно создавать какието менеджеры, контейнеры, те в свою очередь хотят чтоб я им инъектил чтото и тп. Документацию опять же на подобные действия хрен найдешь, потому что это же не по СОЛИДу! В ларавеле у меня таких проблем не было, я чувствовал себя полностью свободным, в том числе и в написании говнокода, без которого в реальной жизни очень сложно приходится.
                                                                                                                          0
                                                                                                                          Сифмони заставляется меня безукоснительно следовать СОЛИДу.

                                                                                                                          Я так понимаю что вы не очень понимаете что такое SOLID.


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

                                                                                                                          Вы можете в симфони так же как и в ларавель херачить все в контроллерах. Так собственно половина людей делают. Солиды — никто не заморачивается по этим принципам. А если кто-то заморачивается и заставляет вас классы-менеджеры делать — он просто не понимает что делает.


                                                                                                                          без которого в реальной жизни очень сложно приходится.

                                                                                                                          суть не в том что бы не писать "сомнительных решений", а в том что бы изолировать их, дабы уменьшить их влияние на проект. Как говорится — все какают но обычно делают это в определенных местах а не по всему дому.

                                                                                                                            0
                                                                                                                            Это вы не поняли мой пример :). Я уже точно не помню свой юзер кейс. Я только помню, что гуглил как же мне получить чтото из базы, везде были примеры того как это делается в контроллере, потому что контроллер уже имеет встроенный менеджер сущностей, который дает доступ к базе. Если у тебя какойто свой левый класс, то хрен тебе — надо танцевать с бубном и инъекциями, чтоб этот менеджер сущностей организовать.
                                                                                                                              +1
                                                                                                                              контроллер уже имеет встроенный менеджер сущностей, который дает доступ к базе

                                                                                                                              контроллер (на тот момент, сейчас это не рекомендуется) имеет доступ к контейнеру зависимостей. в контейнере собственно все лежит. Там лежит менеджер сущностей (штука которую тоже не стоит так вот в открытую юзать но это детали), которая позволяет достать репозиторий (коллекцию сущностей) и там уже можно забрать из коллекции то что надо. Это не сильно отличается от Model::find() просто контроля больше. Ну и да, вас никто не заставляет юзать доктрину с симфони, ставите рядом любую AR библиотеку и радуетесь.


                                                                                                                              надо танцевать с бубном и инъекциями

                                                                                                                              я просто надеюсь что мне не придется сталкиваться с проектами написанными вами.


                                                                                                                              И да, к SOLID это все никакого отношения не имеет. Они про то как делать что бы было проще менять. Если вам не проще — вы что-то делаете не так. И если для вас проще бездумно собирать код из документации — сами понимаете какой будет эффект.

                                                                                                                                –2
                                                                                                                                Нет, это сильно отличается. Вы опять ничего не поняли. У меня нет никакого контейнера, нет никакого менеджера сущностей. У меня просто есть нулёвый левый класс, в котором мне нужно написать какуюто магию. И тут симфони вместо того чтоб просто дать мне нужный инструмент для работы с базой, начинает мне заливать про контейнеры и менеджеры, которые в моем учебном говно проекте мне даром не нужны. Это называется высокий порог вхождения. О чем собственно речь и была в начале ветки.
                                                                                                                                  +2
                                                                                                                                  Это называется высокий порог вхождения.

                                                                                                                                  это называется низкий уровень разработчиков.

                                                                                                                                    0
                                                                                                                                    которые в моем учебном говно проекте

                                                                                                                                    Пишите их на pure PHP, зачем там симфония?
                                                                                                                                    Пора придумывать какой-нибудь POPO для PHP как аналог POJO в Java.
                                                                                                                                    Это называется высокий порог вхождения.

                                                                                                                                    Он высокий там, где это нужно, и его высота зависит от сложности предметной области, а не от используемого фреймворка. Наоборот, сайт, написанный на фреймворке, имеет более низкий порог вхождения, нежели чем самопис на велосипедах.
                                                                                                                                  0
                                                                                                                                  Открою тайну. Вы можете любому своему классу добавить интерфейс
                                                                                                                                  ContainerAwareInterface и даже использовать трейт ContainerAwareTrait, чтобы не имплементить этот интерфейс самому.
                                                                                                                                  Теперь симфони сама внедрит контейнер в ваш сервис и вы сможете там хоть конект к бд достать и делать что захотите.
                                                                                                                                0
                                                                                                                                Нужно создавать какието менеджеры, контейнеры, те в свою очередь хотят чтоб я им инъектил чтото и тп.

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

                                                                                                                                  А с autoconfigure и конфиг писать не надо. Просто говорим в конструкторе какие зависимости нам нужны.

                                                                                                                        0
                                                                                                                        Тех же дженериков очень сильно не хватает, лично я бы назвал это самой крупной проблемой в PHP для моих задач.
                                                                                                                        Из других проблем — отсутсвие типов у филдов, и её уже хотят решить.
                                                                                                                        0
                                                                                                                        Несколько расстроило то, что в 8-ке хотят реализовать асинхронщину в рантайме лишь частично. Я не понимаю — это вообще как? Часть ввода-вывода на низком уровне сделают неблокирующим, часть блокирующим? Или добавят ворох функций «на _nb», которые будут точно неблокирующими? ИМХО лучше сразу сделать нормальные зелёные потоки, в которых все операции будут выглядеть блокирующими, а в действительности при IO будет передаваться управление циклу событий / планировщику зелёных потоков — тогда не нужно будет придумывать новые функции, а просто старые будут на низком уровне делать только неблокирующий ввод-вывод (ну или блокирующий, но только в режиме единственного зелёного потока, что сложнее).
                                                                                                                          –6

                                                                                                                          PHP8. Ни слова про asynс-await. Шел 2018-й год.

                                                                                                                            +6
                                                                                                                            Ни слова про asynс-await.

                                                                                                                            А раздел "асинхронность" для кого? async/await в целом это лишь сахар, корутины есть, не хватает лишь event loop-а из коробки и промисов (что бы стандарт а не как в ноде первые 5 лет). Без этого нет смысла говорить о добавлении сахара.


                                                                                                                            Более того, посмотрите на тот же amphp:


                                                                                                                            try {
                                                                                                                                $gh = "https://github.com/";
                                                                                                                                $response = yield  $http->request($gh);
                                                                                                                            } catch (HttpException $e)  {
                                                                                                                                // handle error
                                                                                                                            }

                                                                                                                            это код который вы можете писать уже сегодня. Проблема в том что область применения ограничена так как стандартные функции для работы с I/O все еще синхронны и людям приходится делать все с нуля.

                                                                                                                            0

                                                                                                                            Дайте дженерики хотя бы стандарт в док коменты. А то с промисами совсем беда.

                                                                                                                              0
                                                                                                                              Это я так скоро смогу писать игры не слезая с ПХП?
                                                                                                                                +2
                                                                                                                                Я вот думаю. Если PHP все же выкарабкается из своей ипостаси «только для говнокодеров», кто главные претендент на то, чтобы занять его место? :)
                                                                                                                                  +1
                                                                                                                                  не выберется. Слишком большой BC break. Однако perl в целом в узких кругах считается хуже)
                                                                                                                                    +3
                                                                                                                                    Массовый пользователь про Перл уже и не помнит. Все больше Java, JS, Python, C[++,#] и т.п. :)
                                                                                                                                    Надо из них выбирать. Я ставлю на JS, слишком много шуток вокруг него из серии «угадай, что этот код делает в JS»…

                                                                                                                                    З.ы. ну и про бесконечные фреймворки, конечно…
                                                                                                                                      +1

                                                                                                                                      JS как язык конечно говно, но развивается он намного лучше php. Особенно со всеми этими бабелями и т.д. Ну и есть typescript/flow и webassembly.


                                                                                                                                      честно сказать я получаю больше удовольствия от написания кода на js чем от php. Инфраструктура решает.

                                                                                                                                        0
                                                                                                                                        Скорей всего постепенно массово на смену js придёт typescript а там уже особо не «говнокодиш»
                                                                                                                                          0
                                                                                                                                          Не факт: Фейсбук довольно активно пилит его прямого конкурента в виде Flow и довольно интересный проект Reason.
                                                                                                                                            0
                                                                                                                                            Быть может ещё что-то придумают… Одним словом Js сейчас идёт в сторону типизации и стандартизации. Я уже сам редко пишу на «чистом js», как бы не сказать что практически не пишу))
                                                                                                                                              0
                                                                                                                                              По мне в том-то и проблема JS: слишком много параллельных решений. Тот же PHP, он один. Не перепутаешь. Порог вхождения ~= прочитать любую книгу по PHP.
                                                                                                                                              А какой порог вхождения в JS? Серверный JS, фронт? Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи… Не ясно за что хвататься.
                                                                                                                                              Мало того, что ванильный JS постоянно развивается, так параллельно еще и куча наворотов.

                                                                                                                                              З.Ы. и это при том, что я в целом люблю JS. :D
                                                                                                                                                +2
                                                                                                                                                А какой порог вхождения в JS

                                                                                                                                                ниже чем вы можете себе представить. Тут как с php. порог входа низкий, ограничений мало, и пошло поехало.


                                                                                                                                                Не ясно за что хвататься.

                                                                                                                                                каждый день люди спрашивают тупости типа "путь изучения php" и всякий раз в топе будет вопрос "поучи симфони/ларавель/yii". Я это к тому что язык тут не важен, проблема с комьюнити. У JS с этим пока все же лучше но не намного.

                                                                                                                                                  0
                                                                                                                                                  Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи…

                                                                                                                                                  Почему тогда про php не говорите, что у него есть всякие симфони, доктрины, ларавели, смарти, компоузеры и еще много аналогичных страшных слов?
                                                                                                                                                    0
                                                                                                                                                    Потому что этот зоопарк на PHP всё-таки меньше, и он не так быстро меняется. По сути для базовой разработки на PHP нужен только менеджер зависимостей (в PHP общепризнан Composer, не приходится выбирать из зоопарка) и фреймворк (ну здесь как и в JS три общепринятых лидера плюс набор менее популярных фреймворков). Ну ещё выбрать шаблонизатор из Smarty, Twig или Blade, да и то не факт, сейчас модно делать шаблонизацию на стороне фронтэнда. Ну ORM ещё выбрать, но это нужно не во всех проектах, и как правило ORM привязана к фреймворку. И это всё, остальное подбирается уже под частные задачи.

                                                                                                                                                    Не нужно заботиться ни о диалектах языка (TypeScript или нет?), сборщиках, браузерных API и т.д. PHP развивается достаточно понятно, фреймворки тоже уже давно устоявшиеся. Плюс такое ощущение, что в JS зоопарк технологий меняется с куда большей скоростью.
                                                                                                                                                      0
                                                                                                                                                      Потому что этот зоопарк на PHP всё-таки меньше

                                                                                                                                                      ну в js тоже есть свои стандарты. И как-то в php среде не принято делать красивый пост на медиуме о новом крутом фреймворке. Хотя на рэддите раз в неделю кто-то выкидывает свои творения.


                                                                                                                                                      и он не так быстро меняется

                                                                                                                                                      я вижу в этом больше негативного нежели позитивного. При таком большом количестве php разработчиков так хреново развивать экосистему — это о много говорит. Да, в js комьюнити проблема другая — много недовелосипедов которые пиарятся неплохо, но… с этим можно смириться хотя бы.


                                                                                                                                                      В целом как по мне будущее не за "язык А лучше" а за возможостью более гибко их юзать совместно.


                                                                                                                                                      выбрать шаблонизатор из Smarty, Twig или Blade

                                                                                                                                                      в js комьюнити все тоже выбирают только из nunjucks/pug/mustash. Есть еще, но это не мэйнстрим. Так же как и для php есть куча разных о которых вы даже не подозреваете.


                                                                                                                                                      ORM привязана к фреймворку.

                                                                                                                                                      так только в плохих фреймворках. Ну и всеравно нормальных ORM для php нет. Разве что доктрина, и то не оч.


                                                                                                                                                      Не нужно заботиться ни о диалектах языка

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


                                                                                                                                                      сборщиках, браузерных API и т.д.

                                                                                                                                                      вы ж под бэк писать собрались, зачем вам бандлеры?


                                                                                                                                                      фреймворки тоже уже давно устоявшиеся

                                                                                                                                                      стогнация?


                                                                                                                                                      такое ощущение

                                                                                                                                                      ощущение такое есть но… по факту этого нет. Тем более давайте будем честны, если вы возьмете именно серверную часть — там так же все давно устоялось. Есть express, koa и т.д. Не нужно просто всю экосистему JS в одну кучу смешивать и все будет куда проще.

                                                                                                                                                        0
                                                                                                                                                        Я изначально отвечал на
                                                                                                                                                        Ноды, редуксы, реакты, ангуляры, тайпскрипты, байбелы, йарны, прости, Господи…
                                                                                                                                                        , а это в основном про фронтэнд. Я думаю что на бэкэнде и для PHP и для Node.js ситуация устоялась не потому что болото и экосистема херово развивается, а потому что под все типовые задачи уже есть хорошие инструменты. В то время как для современного фронтэнда vanilla js совершенно недостаточно, и приходится придумывать кучу надстроек чтобы это решить.
                                                                                                                                                          0

                                                                                                                                                          ну если проанализировать ситуацию с фронтэндом вдруг тоже окажется что подходы устоялись. Дальше весь вопрос в мелочах — типа где делать diff стэйта, между приложением и UI или на уровне DOM и т.д.


                                                                                                                                                          babel и полифилы в целом позволяет не особо думать о том что умеет браузер, ну а дальше уже вкусовщина начинается.

                                                                                                                                      0
                                                                                                                                      PHP станет асинхронным! Все Node.js программисты начнут терять работ )
                                                                                                                                        +1
                                                                                                                                        Господя. Может кто-то внятно объяснить зачем сейчас использовать ПХП, когда есть Go и нода, которые намного быстрее и в 100 раз проще в развертывании на продакшене?
                                                                                                                                          +4
                                                                                                                                          Как минимум PHP объектно-ориентированный.
                                                                                                                                          Одно дело написать микросервис на Го, другое — крупный энтерпрайс с миллионам строк кода. Там будет столько говнокода, что легаси проекты на PHP вам позавидуют
                                                                                                                                            +1

                                                                                                                                            Для этого есть java, скала. Без статической типизации и дженериков в крупных проектах делать нечего

                                                                                                                                              0
                                                                                                                                              А как же VK, Facebook, Badoo?
                                                                                                                                                +2

                                                                                                                                                Которые переписывают понемногу все на микросервисы, используя го и джаву для этих целей? В интернете сотни статей про переписывание проектов из php на . Найдете хоть десяток, в котором описывался обратный процесс?

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

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

                                                                                                                                                    +2
                                                                                                                                                    Потому что PHP очень плохо подходит для микросервисов. Если в PHP появится нормальная асинхронность — я с радостью перейду с Node.js на PHP. Хотя бы потому что неудобно писать часть бэкэнда на Node, а часть — на PHP. Приходится дублировать библиотеки и т.д. По скорости как я понимаю особых преимуществ Node.js уже не даёт, а насчёт корявого легаси — это ещё можно поспорить где его больше, в Javascript или в PHP.
                                                                                                                                                      0
                                                                                                                                                      Почему плохо подходит то?
                                                                                                                                                      Уже сейчас можно пилить на пыхе как на ноде, со всякими ReactPHP\Swoole
                                                                                                                                                        0
                                                                                                                                                        Хотя бы потому что это решения не из коробки. Swoole — это вообще расширение, т.е. с каждым переходом на новую версию PHP мне нужно будет смотреть, подходит ли Swoole для этой версии, обновился ли?
                                                                                                                                                          0
                                                                                                                                                          1. Вы сколько раз в неделю обновляете версию пхп?
                                                                                                                                                          2. Докер решает проблему обновлений. Просто поправьте докер файл и все взлетит.

                                                                                                                                                          зы. Я согласен, что было бы круто иметь это из коробки. Но с другой стороны большинству проектов на пыхе этого не нужно. А кому нужно, тот разок заморочится с установкой расширения
                                                                                                                                                        0
                                                                                                                                                        А есть какая-то прямая связь между асинхронностью в PHP и микросервисами?
                                                                                                                                                        nginx/apache + php-fpm при правильной конфигурации покажет соизмеримые результаты с нодой.
                                                                                                                                                  0
                                                                                                                                                  PHP объектно-ориентированный.

                                                                                                                                                  классо ориентированный*


                                                                                                                                                  Что до Go — у него есть структурный тайпинг и в целом я бы еще с вами мог поспорить чья модель выполнения больше вписывается в концепцию ОО. Как по мне Го тут только в выйгрыше (просто концепт объекта меняется). И да, и у того и у другого нет дженериков.


                                                                                                                                                  Там будет столько говнокода

                                                                                                                                                  Увы правда в том что в любом проекте на миллион строк будет говнокод. Такова природа энтропии. И го в этом плане опять же выигрывает.

                                                                                                                                                  0
                                                                                                                                                  Одна из причин, это когда на php запускаешь проект быстрее, пусть и с плохим кодом — главное работает! А вот если заработает, то можно и заплатить другим, чтобы переписали на «правильный» язык.
                                                                                                                                                  К сожалению, большинство проектов не запускается, но это никак не уменьшает количество кода на php, скорее прибавляет :)
                                                                                                                                                    0
                                                                                                                                                    Потому что больше людей на нём работает, потому что есть много готовых решений, потому что на любой вопрос скорее всего уже есть ответ, потому что просто отлаживать и поддерживать. Больше из основного я не вижу.
                                                                                                                                                      +1

                                                                                                                                                      Та же ситуация с джавой и питоном. Причем там все лучше, так как более консистентно. Нету дублирующих функций с непонятными названиями и количеством аргументов

                                                                                                                                                        0

                                                                                                                                                        ИМХО 3 странички с базовой логикой на java, если не постоянно с ней работаешь, будет сложней, не говоря уже о том, что "условно нормальных" рецептов nginx+tomcat не нагуглить за 5 минут (не говоря уже о случаях, когда вдруг задеплоенный war валит сервер при старте выдавая кучу ошибок)

                                                                                                                                                          0
                                                                                                                                                          может быть просто надо забыть о сервлетах как о страшном сне?
                                                                                                                                                            0

                                                                                                                                                            Можно но тогда будут другие вопросы :) ведь банальной возможности скриптового php, когда можно смешать html+php и скормить интерпретатору установленному 1й командой практически в любом дистрибутиве, java, вроде, не имеет?, или я что-то пропустил?
                                                                                                                                                            p.s. специально "поспрашивал" яндекс с гуглом, везде jetty, tomcat и куча xml-ей в ide

                                                                                                                                                              0
                                                                                                                                                              > или я что-то пропустил?

                                                                                                                                                              github.com/reljicd/spring-boot-blog — ну вот посмотрите. Как по мне не сложнее всяких там ларавелей и симфони и при этом не php.

                                                                                                                                                              Ну а штуки где закинуть файлик по ftp и т.д. в коммерческой разработке должны умереть (их можно заменить другими вещами где не надо код писать вообще).
                                                                                                                                                                –1

                                                                                                                                                                Так мы про 3 странички с базовой логикой для не владеющего java или про заказную коммерческую разработку (которая может угробить бизнес идею ещё до начала работы?), у меня есть перед глазами пример бизнес который появился только за счёт того что был php, в котором было не сложно разобраться знакомому владельца. При этом стоимость "коммерческой разработки как должно быть" никто бы оплачивать не стал :)

                                                                                                                                                                  +1
                                                                                                                                                                  повторюсь — для трех страничек обычно не нужен даже php.

                                                                                                                                                                  очень часто люди кидаются в разработку кастомных решений хотя их задачу покрывают какие-нибудь гугл доки и запир.
                                                                                                                                                      0
                                                                                                                                                      Про ноду не скажу, т.к. не опытен тут. Расскажу мой случай про GO vs PHP.

                                                                                                                                                      Мне нужно было сделать сайт по объявлениям, очень быстро. Набрал в гугл php script classifieds — получил кучу ссылок. Рабочий полностью сайт поднял за 1 час.

                                                                                                                                                      Набрал в гугл go script classifieds — выдает РНР решения.
                                                                                                                                                      Набрал golang script classifieds — нет РНР решений, но вижу набор не потребных ссылок.

                                                                                                                                                      Я не знаю есть ли готовое решение на GO, может оно и есть, тогда можно сказать, что гугл виноват. Но подозреваю что его все же нет.

                                                                                                                                                      Представьте что за эту работу я получил 5000 долларов. На РНР я заработал эти деньги за 1 час, на GO — неделя, месяц?

                                                                                                                                                      Профит?
                                                                                                                                                        0
                                                                                                                                                        Да я не спорю, что делать сайты (интернет магазины, блоги и прочее) удобнее и быстрее на пыхе, но зачем тогда все эти нововведения 8й версии, кому они нужны? Если нужно сделать какой-либо высоконагруженный сервис, то пыха здесь никак не подходит из-за низкой производительности и отсутствием многопоточности (про сторонние костыли я молчу).
                                                                                                                                                          0
                                                                                                                                                          Аналогичная практика жизни. Когда нужна быстро заработать то php «собрал из палок и г..», а когда нужно сделать качественный продукт с бледжеком и ш… то node, java в зависимости от задачи
                                                                                                                                                            +3
                                                                                                                                                            Профит?

                                                                                                                                                            всегда было жаль клиентов которые платят кому-то $5K/h за скаченный скрипт и потом страдают с тем что бы кто-нибудь это дело потом поддерживал.

                                                                                                                                                              0
                                                                                                                                                              ваши фантазии не соответствуют действительности, клиент остался доволен
                                                                                                                                                                0
                                                                                                                                                                а у вас не репрезентативная выборка. Любой проект рано или поздно придется развивать. Либо он просто умирает (бывают проекты которые нужны на пару месяцев-год, например к определенной дате или событию, а потом не нужны вообще). Последние меня не интересуют.
                                                                                                                                                                  0
                                                                                                                                                                  Наговнокодить можно и на питоне и на чем угодно, что потом поддерживать проект будет не менее трудно.

                                                                                                                                                                  Я отвечал на конкретный вопрос — почему люди до сих пор выбирают РНР, вы куда-то не туда данную ветвь дискуссии повели.

                                                                                                                                                                  В моем конкретном примере 5к заработано за 1 час работы, сделать нужно было быстро. Заказчик был впечатлен оперативностью. Далее был подписан контракт на поддержку и развитие проекта и никакой боли от этой поддержки и развития нет. Скрипт который был выбран вполне себе хорошо спроектирован и нормально написан на РНР.

                                                                                                                                                                  Если проект в будущем взлетит и будет приносить 1млн в месяц, то уже можно будет нанять команду гошников или питонистов, которые радостно всё за год перепилят и на которых будет не жалко тратить заработанные деньги. А можно будет поступить по другому — потратить лишние N-к денег на дополнительные бэкенд сервера под РНР нагрузку, что опять же будет дешевле той самой команды питонистов или гошников.

                                                                                                                                                                  Чтобы уж совсем все по полочкам разложить то расскажу еще одну историю. В предыдущей моей конторе ребята переписывали систему (кажется с питона) на GO. Делали они это 2 года! В итоге вместо 10 серверов они смогли тоже самое на 1-ом серваке развернуть. Только не помню уже точно детали, но кажется изначально дело было не в питоне, а криворукости тех питонистов, которые изначально написали систему. Можно посчитать сколько они бабла на программистов потратили за 2 года, там их около 5 человек было и когда это все добро окупится.