PHP — какая ниша у языка и поможет ли PHP8 решить насущные проблемы (спойлер: имхо нет)

    class Number {
        private int|float $number;
    
        public function setNumber(int|float $number): void {
            $this->number = $number;
        }
    
        public function getNumber(): int|float {
            return $this->number;
        }
    }

    В одном из выпусков подкаста "Цинковый прод" мы мельком обсуждали, что нового будет в языке PHP8. После записи я решил написать статью, чтобы сформулировать свои мысли по положению PHP в современной разработке.

    Давайте определимся в целом, какую нишу занимал/занимает язык, и куда он движется

    Изначально язык позиционировался как простой инструмент, в котором из коробки есть всё необходимое для web.


    С одной стороны, это действительно так: без дополнительных библиотек можно, например, вытащить из суперглобальной переменной $_POST параметры POST-запроса и вставить их в mysql с помощью встроенных функций, и это вроде как здорово.


    Также очень важно, что модель "рожден, чтобы умереть" (например, в php-fpm) упрощала и упрощает разработку до безумия: не нужно знать, что такое локи, дедлоки, утечки памяти и т.д. Не надо писать await перед каждой строкой кода и т.д.


    Скрипт начал работать над входящим HTTP-запросом, поработал в отдельном процессе, ни с кем не общаясь, и сдох, очистив все после себя. Очень просто программировать. Порог входа — около нуля.


    Опять же, можно обойтись без роутинга: имя файла — это уже описание роутов.


    С другой стороны, увы, есть нюансы. Веб не стал ждать и ушел далеко вперед.


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


    Сейчас повсеместно распространены вебсокеты: они нужны для онлайн игр, чатов, оповещений в SPA-приложениях и т.д. Но вы просто не можете держать на php чат на 10000 человек: php-fpm worker обрабатывает только одно соединение за раз. Нельзя просто так взять и нагородить 10000 процессов ОС.


    Есть, конечно, ReactPHP, Swoole, Amphp, но это по сути костыли, с помощью которых можно попытаться обойти ограничения PHP. Однако это не сам язык, а именно костыли. Кто поручится, что проект Swoole проживет еще лет 5? Много ли народу его изучила? Куча тимлидов предпочитает для вебсокетов использовать другой язык (Go или nodejs) или же вообще выбросить php полностью и написать ВЕСЬ проект на конкурирующей технологии.


    Еще раз: разработчки на Go точно знают, что такое горутина, и горутина никуда не денется из языка. Разработчик под nodejs точно знает, что такое async/await и Promise. В деталях.


    А знает ли средний PHP-шник что-нибудь про ReactPHP? Нет!


    Далее, современный веб зачастую строится на микросервисах, которые активно общаются друг с другом. Часть API выгодно строить с постоянным соединением и асинхронным взаимодействием. Попробуйте организовать GRPC-сервер на голом php без 100500 костылей сбоку. Вас будет ждать разочарование.


    Короче, писать микросервисы на PHP невыгодно.


    Веб становится всё более хайлоадистым. Увы и ах, как ни ускоряй PHP, но под каждый HTTP-запрос выделяется отдельный процесс — это поведение прибито гвоздями. Даже если скрипт просто ждет ответа от БД или внешнего API, и ничего не делает — процесс продолжает существовать. Т.е. для io-bound задач PHP опять же подходит хуже, чем nodejs/golang/etc.


    Простота


    Простота языка немного подрассосалась. Нет, серьёзно, никто уже не пихает $_POST прямо в mysql_query. В вашем проекте с вероятностью 99% есть фреймворк, куча зависимостей из Composer, соблюдение принципов проектирования и т.д., роутинг, заданный в конфиге или аннотациях, а не в именах файлов. Т.е. встроенность веб-фич из коробки никак не играет роли. Spring boot (java) не намного сложнее: поставил пару аннотаций, и вот уже ты запустил своё веб приложение.


    Итак, какая же ниша?


    Ниша по сути — это админки со сложной бизнес-логикой (т.е. на Golang такое писать нецелесообразно) и не особо нагруженные сайты. Здесь PHP — лидер. Язык не переусложнен многопоточностью, колбек-хеллами, приятный синтаксис, куча разработчиков, опыта применения и т.д.


    Да-да, приятный синтаксис. Есть все необходимое, но не перегружено лишними фичами. Есть типизация аргументов функций и свойств классов — и этого почти достаточно. Хотя это всё проверяется только в рантайме, но даже это сильно помогает в разработке, да и IDE сразу подсказывает, где косяк.


    С точки зрения типов не хватает дженериков. Чтобы на входе в функцию сразу было видно, что это не просто сферическая Collection в вакууме, а Collection<User>, т.е. коллекция объектов класса "пользователь". Читабельность выросла бы в разы.


    PHP 8


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


    JIT


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


    Является ли это киллер-фичей? Как бы да, но… По-моему, не особо. Проблемы, описанные выше это никак не решает. И я не видел, чтобы PHP использовали или планировали использовать как числодробилку. C, C++, Rust все равно будут подходить лучше и работать в разы быстрее. Т.е. имхо ускорение которое мы увидели в PHP7.* по сравнению с PHP5 — уже и так крутое. PHP и так один из самых быстрых скриптовых языков, быстрее чем Ruby и Python. Я очень уважаю команду PHP и Дмитрия Стогова в частности, но по-моему титанические усилия по добавлению JIT в PHP не совсем оправданы для реальных php-приложений.


    Если честно, я бы предпочел, чтобы вместо этого был сделан шаг в сторону асинхронных возможностей. Какие-нибудь аналоги Async/await и Promise.


    Атрибуты


    Что еще интересного в PHP8? Атрибуты.
    Если по-простому, то аннотации в Symfony будут выглядеть не так


    
        /**
         * @Route("/blog")
         */
        public function list()
        {
            // ...
        }
    

    а как-то так:


    
        <<Route("/blog")>>
        public function list()
        {
            // ...
        }
    

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


    Union Types и mixed


    Пример говорит сам за себя, можно перечислять типы через символ |


    class Number {
        private int|float $number;
    
        public function setNumber(int|float $number): void {
            $this->number = $number;
        }
    
        public function getNumber(): int|float {
            return $this->number;
        }
    }

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


    Кстати, еще в PHP8 можно указать тип mixed в явном виде.


    Являются ли все эти фишечки Big deal? Имхо не особо.


    Weak maps


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


    Остальное


    Чуть больше консистентности в функциях, где-то немного сахара добавлено, пара функций для работ со строками. И в общем-то всё.


    Подробности можете посмотреть, например, в этой статье.


    По-моему, PHP7.4 выглядел более мажорным и фичастым.


    Вывод


    Всё, что написано в статье — сугубо субъективно. Подытожу:


    PHP — отличный (лучший) язык для написания админок сайтов. С приятным синтаксисом, отличным тулингом и тьмой разработчиков.


    Но для хайлоада, микросервисов и асинхронных штук — язык так себе. И PHP8 на мой взгляд больших практических проблем никак не решает. Поэтому то тут, то там по-прежнему будут присутствовать вставки на nodejs/go для асинхронных задач.


    Мы обязательно обсудим это в следующих выпусках подкаста "Цинковый прод", поэтому не забудьте подписаться.


    Update. Обсудили: https://youtu.be/GKPttdLsCew

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +40
      С интересом наблюдаю, как 20 лет хоронят PHP. Ну да ничего. Ruby пережили, дай бог, и очередной golang переживём.

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

      Здоровья вам и долгих лет!

      P.S. А самого Стогова слабо на подкаст позвать? И в глаза ему сказать, что он фигню делает?
        +4
        Ну вам же сказали про самую нужную фитчу, которую PHP дать не может — поддержание постоянного соединения с вебсокетом, с браузером юзера.
          0

          А как же ReactPHP?

            +6
            Вот пример использования вебсокета на чистом пхп.
            phppot.com/php/simple-php-chat-using-websocket

            Первая ссылка в гугле — но вообще их тысячи.
            Сам лично запускал вебчат на вебсокетах и чистом пхп лет 8 назад — работает до сих пор.
            Ну и писал игру на вебсокетах и тп — всё работало. Проблем с вебсокетами небыло.
            И это всё ещё на пхп 5.2.
            Сейчас ещё проще стало.

            Только фишка в том что вебсокет далеко не всегда нужен.
              +7

              По сути — это вручную сделанный ивент луп. Тут есть ряд проблем. Представьте, что иногда у вас проскакивают долгие запросы в базу. В этот момент система не будет ничего принимать и отправлять, будет ждать ответа. PDO не умееет неблокирующие вызовы. Даже если извернуться и как-то сделать (вроде бы для amphp сделали вручную клиент для mysql), это все выглядит как нагромождение костылей, а не first class citizen

                0

                Если честно, то нагромождением костылей выглядят как раз нативные модули вроде того же mysqli.

                  +1

                  Согласшусь. К сожалению, ассинхронность в php ещё сырая, могу судить по опыту использования amphp в продакшене, и будет требовать неоправданно больших усилий в поддержке, так как текущие библиотеки страдают нестабильностью (amphp/mysql, amphp/artax) и постоянно находятся какие-то ошибки, которых в нативных решениях будет сильно меньше.
                  Не то чтобы что-то реализовать нельзя на php, вопрос, что ряд задач сильно дешевле сделать другим способом.

                    0
                    mysqli умеет асинхрооную работу с бд
                      0
                      Не знаю как с другими СУБД, а с MySQL и PG можно работать в неблокирующем режиме.
                    –6
                    Прошу проверить вашу гипотезу в моем чате, правда нужно авторизоваться с оплатой в 1 бакс :), а потом можете делать выводы о невозможности PHP поддерживать сокеты.
                      –6
                      И забыл оставить линк: my_game with support web-sockets
                      Буду рад еслси кто проведет нагрузочное тестирование.
                        –5
                        Голосование на хабре нужно изменить, если кто то голосует против, то должен оставить пояснение, а так это — устранение неподходящих.
                          +1

                          Вы рассылаете спам на сотню читателей с рекламой своего платного продукта, да еще и просите бесплатно оказать вам услуги по тестированию. Почему вас удивляет, что это кому-то не нравится?

                            –2
                            Я дал ответ про web-sockets, и что может ли PHP держать нагрузку, как я могу еще доказать то что написал в комментарии, не дав линк на работающий проект? А то что кто то видит только спам — не значит что я сказал что то не то и голосование идет за ответ, а не люблю или не люблю(нравиться или не нравиться).
                              0
                              как я могу еще доказать то что написал в комментарии, не дав линк на работающий проект?

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


                              А то что кто то видит только спам — не значит что я сказал что то не то и голосование идет за ответ, а не люблю или не люблю(нравиться или не нравиться).

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


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

                                –1
                                Вы ничего не сделали что бы опровергнуть или доказать что я "обманщик", но уже сильно уверенно утверждаете и за всех посетителей отвечаете. А также зачем мне портить свою репутацию обманывая молодых людей?
                                Во-вторых я не обязан вам предоставлять исходный код. Я хочу что бы молодые ребята не велись на всякие манипуляции в комментариях о PHP и не проверив самостоятельно или посмотрев на проект(мой или чужой) сделали выводы, а также получали опыт.
                                Каждый сам решает платить или нет, почему вас это волнует. Может кто то посчитает что оплатив вход в проект он сам посмотрит как он работает, проверит работу чата и т.д. И я указал что вход платный потому что бы предупредить и не тратить время на регистрацию если она не пустит в проект без оплаты.
                                  0
                                  Вы ничего не сделали что бы опровергнуть или доказать что я "обманщик"

                                  Где именно я сказал, что вы обманщик?


                                  Во-вторых я не обязан вам предоставлять исходный код.

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


                                  не проверив самостоятельно или посмотрев на проект(мой или чужой)

                                  "Посмотреть на проект" означает "посмотреть на исходники". Чьи-то слова "да там точно одно соединение, правда-правда" ничего не доказывают. Может вы просто думаете, что там одно соединение, а работает оно совсем по-другому.


                                  Каждый сам решает платить или нет, почему вас это волнует.

                                  Меня это не волнует. Вы спросили "почему минусы", я дал вам ответ. При этом сам я минус не ставил.


                                  Может кто то посчитает что оплатив вход в проект он сам посмотрит как он работает, проверит работу чата и т.д.

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


                                  Давайте я подробнее объясню. Вы написали комментарий как опровержение утверждения про веб-сокеты в PHP. Он его не опровергает, минусами люди выразили свое несогласие с вашей логикой. Также он содержит излишне необоснованные требования для проверки этого утверждения. Минусами люди выразили несогласие и с этим, проверить утверждение можно бесплатно. А также вы пытались это доказать рекламой своего платного сервиса, что вообще-то запрещено правилами. Вот за все это в совокупности каждый человек поставил один минус, и таких людей было несколько.


                                  и за всех посетителей отвечаете

                                  А как вы представляете ответ на вопрос "за что минусы" на сайте, где у каждого пользователя свой аккаунт? Ну можете считать, что у меня написано не "Люди поставили минус за то-то", а "Я бы поставил минус за то-то". Принципиально это ничего не меняет. Просто я вам объяснил, а остальные не хотят. Потому что никто не обязан вам что-то объяснять. Какие выводы сделать из этой информации, решайте сами.

                                    –1
                                    Ок, я уже не обманщик, значит правду говорю что: "PHP" —
                                    ничего не
                                    может все, и одни только лузеры его используют :) Все по своему правы, но учтете — всегда проверяйте любые факты сами, тогда Ваши шансы обойти мышеловку стороной увеличатся, а и опыта станет побольше.
                        –2
                        Еще в «ушедшем далеко вебе» были убийцы Flash и Silverlight. Хоронителям пора задуматься над тем, что из себя представляет веб на самом деле.
                          +1

                          Несколько раз прочитал, но не понял. Флеш и сервелат разве живые сейчас?

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

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

                          Вторая проблема PHP — люди не хотят глубоко вникать в него, например недавно столкнулся с человеком который считает что yild есть в phyton и нет в php. А вы знаете, что генераторы появились еще в PHP5.5? Вот статья интересная — nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html
                            +1

                            Я так думаю про golang. Он реально прощает многое. Точнее не даёт сделать себе выстрел в ногу. Для справки я занимаюсь 1с. Занимаюсь давно. И вот каждые года 3-4 я пробовал php. Что в первый раз он мне не зашёл ни по синтаксису, ни по парадигме. Когда я взял го, то понял, это тот язык, который мне нравится. Кроме нескольких исключений. Он простой, он лаконичен, он многопоточный, он ограждает меня от многих неприятностей на этапе компилирования. И самое главное синтаксис. Два дня мучений, и я начал такое использовать даже в 1с. Но он не позволяет одной переменной стать сначало строкой, а потом массивом. А 1С и php запросто. Он не позволяет ошибок проектирования.

                              +2
                              Но он не позволяет одной переменной стать сначало строкой, а потом массивом.
                              С этим ошибок в тех ЯП, где такое возможно, у меня не было связано. Не то, чтобы это было хорошая фича, но вреда по факту тоже не несёт (если не писать божественные функции).
                              Он не позволяет ошибок проектирования.
                              Забавно регулярно оду типизации Go читать. Видимо, всё от разработчиков, всю жизнь писавших на динамических ЯП. Попробуйте Rust. Или хотя бы Typescript. Go слишком примитивен для каких-то там гарантий компиляции. И он нарочно примитивен.
                              Можете даже попробовать PHP + Psalm со всеми ошибками.
                                0
                                Go слишком примитивен для каких-то там гарантий компиляции.

                                Поясните подробней? На раст давно смотрю, руки не доходят. Из разряда сам не пробовал но осуждаю. Вижу примеры кода, и синтаксис ужасный по мне. Похоже он ближе к низким ЯП. Таким как c++. А мне не очень хочется заниматься выделением/освобождением памяти. И прочими весёлыми операциями.

                                  +2
                                  А мне не очень хочется заниматься выделением/освобождением памяти
                                  Да, это убийство производительности в С, но в Rust это происходит полуавтоматически, и за соблюдением правил владения в коде следит анализатор компилятора. Условно говоря, вы можете использовать только умные ссылки и только правильно. Церемоний немного больше и обучения правилам намного больше, чем в Go.
                                  В принципе да, немало низкого уровня у этого улучшенного С, в отличие от Haskell. Там вообще думаешь только о задаче, но в менее привычных условиях.
                                  Поясните подробней?
                                  В Go ведь очень распространено приведение типов из-за невыразительности системы типов, она же там почти как в Pascal. По сути всё есть явно и однозначно типизированные переменные и структуры. И под капотом больше, чем даёт синтакис.
                                  В Rust есть например параметризация типов, тип-сумма, перечисления, абстрактные типы.
                            +1
                            Ну так для справки — по статистике из SO среди профессиональных разработчиков по сравнению с 2019 годом PHP, Ruby, Scala упали а Go, Kotlin, C# выросли. Просто цифры. insights.stackoverflow.com/survey/2020
                              0

                              « Профессиональные разработчики» здесь — это на 95% люди, которые спрашивают, как развернуть связный список. Да и массовость и качество — очень слабо пересекающиеся характеристики.

                            +3
                            То что нет дженериков — просто печаль и беда.

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

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

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

                            Зы а мне нравится роутинг на файлах) я уже разок имел опыт разыскивания аннотаций везде и всюду, а уж какой кайф если кто перепишет поведение аннотации.
                              +2
                              … во вторых магия аннотация меня лично просто убивает.

                              На самом деле, даже для не особо подготовленных спецов по java, это давно уже не магия. Очень много докладов и материалов на эту тематику (например Евгения Борисова, есть стрим где он, в формате лайфкодинга, создавал спринг «на коленке»), которые вдоль и поперек говорят об этой «магии». Было бы желание разобраться.
                                0
                                Спасибо, доклад гляну, но по многим причинам я люблю прозрачный и очевидный код. Аннотации явы это очень мощный инструмент, но он делает код гораздо менее очевидным.
                                  0
                                  Ну справедливости ради, ещё бы дать определение что такое «прозрачный и очевидный код». Здесь скорее зависит от программиста, совокупность его профессиональных навыков и опыта, исходя из этого, любой код становится очевиднее или нет. В любом случае вы можете и не использовать аннотации. Станет ли тогда код более читаемым? Не уверен.
                                0
                                в чем вы видите оверхед явы? если вас смущает потребление памяти контейнерами, сейчас можно собрать стенделоун на quarkus в бинарник мегебайт 20и для рест-сервиса или 50-100 для рест сервиса с субд. И для разработчика это будет выглядеть почти так же чистенько и безлисапедно как спринг бут.
                                  0
                                  а причем тут ява? оверхед у спринга, там один только hubernate даст 200% оверхеда.
                                +2
                                Сильно согласимся с тем, что php переусложнили. Не то что бы мы расстраивались из-за этого прогресса, но смысл в том, что его применение сейчас это не то что привлекало простотой когда он начинался. С другой стороны чего мы хотели — не один десяток лет прошел.

                                А вот хоронить php из-за «один процесс на один вызов», пожалуй, всё же не стоит. Демоны на php работают месяцами, если писать их грамотно и не аттачить кучу либ у которых память течет, в чем блин проблема?.. Сокет к демону прикрутить? Да хоть свой колхоз набросать не так уж сложно- нас в свое время эта habr.com/en/post/331462 статья на это сподвигла (спасибо morozovsk кстати ), хоть сторонние инструменты использоват — основной код-то всё равно останется тем же.
                                Да, go/nodejs более нативны в этом смысле, но у них свои нюансы есть.
                                  +13

                                  Я благодарен php за быстрый вход в тему в 2003 году. Профессионалом на нем не стал — ушел в другие языки. Но того опыта хватило, чтобы сделать свою страницу. Если бы мне тогда попалась java, то я бы стороной обошел web-разработку.
                                  Сейчас я понимаю, что php — отличный язык, который помогает кормить не одну семью. Долгих лет жизни. И, кстати, fb и vk были написаны изначально на php, насколько я помню)

                                    +3

                                    Они всё ещё испольщуют его.

                                      +1

                                      Специально покопался чуть-чуть. Судя по всему, фб и вк сделали траслятор php-> cpp. Язык остался, а среда выполнения — уже иная.

                                        0

                                        Del

                                          +1
                                          Не совсем. В 2010 году они действительно сделали компилятор HPHPc, но он им в итоге не зашел и через год они решили просто запилить собственный интерпретатор HHVM с JIT. Сам интерпретатор получился годным, а вот с JIT возникли проблемы, и еще через пару лет попыток подружить JIT и PHP они плюнули и создали свой диалект языка под названием Hack, с которым JIT работал лучше. Какое-то время они поддерживали обратную совместимость HHVM с PHP, но после выхода php7 интерес сообщества к HHVM пропал и они забили. Теперь у них свой самобытный язык и исполняющая среда, которые за рамками самого фейсбука никто не использует.
                                            0

                                            Интересно, рассматривают ли они возможность перехода на PHP8

                                              0
                                              Вряд ли компания, которая так сильно вложилась в собственную технологию, сможет легко от нее отказаться.
                                                0

                                                Хорошие менеджеры обычно умеют вовремя фиксировать убытки и закрывать тупиковые проекты.

                                                  0
                                                  На данном этапе тупиковость проекта не очевидно. Они сделали JIT на 10 лет раньше команды PHP и все это время развивали его, а так же 5 лет выстраивали инфраструктуру вокруг своего языка Hack, к которому они привыкли и для которого у них есть все необходимое. В этой ситуации плюсы возврата на PHP весьма сомнительны.
                                                    0
                                                    Странно другое, почему они свой Hack не пропагандируют активно? Ведь им выгодно, чтобы в мире больше хак-истов.
                                                      +1
                                                      Потому что как отдельный самостоятельный язык программирования он не нужен, а как php на батарейках потерял актуальность с выходом php7.
                                      +9
                                      Есть, конечно, ReactPHP, Swoole, Amphp, но это по сути костыли, с помощью которых можно попытаться обойти ограничения PHP. Однако это не сам язык, а именно костыли.
                                      А что голая нода и го дают работать с вебсокетами из коробки, никаких сторонних пакетов для этого не надо?
                                        +3

                                        Го точно даёт. Стандартная библиотека. https://golang.org/x/net/websocket

                                          0
                                          Всё же не совсем стандартная, но с гарантированной поддержкой последней версии языка. https://github.com/golang/go/wiki/SubRepositories
                                            0

                                            Тут вопрос был про стандартную библиотеку. Я дал ответ. Я бы использовал гориллу. И по моему даже в официальной документации дают ссылку на неё и ещё какую то библиотеку.

                                          +1

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

                                          +4
                                          или же вообще выбросить php полностью и написать ВЕСЬ проект на конкурирующей технологии

                                          Вот такое обычно плохо заканчивается.
                                            +20
                                            Автор кодер (даже не программист, ибо не видит ничего дальше кода)

                                            1) Единственная причина почему пхп развивается так, а не иначе — это желание бизнеса, который начинался в гараже и смог выжить — с минимальными усилиями поддерживать свою кодовую базу. Ибо гораздо проще переписать старый проект на php, на Symfony с новой версией php, чем полностью менять стек.

                                            Поэтому, ребята из Symfony и Doctrine просто копируют основную функциональность Spring + Hibernate. Ибо бизнесу на php нужно то же самое, что бизнесу на Java, но на php. Откройте спонсоров Symfony и все станет понятно.

                                            2) Если автор ничего в жизни на php не писал кроме адинок, то значит он херовый кодерок. Открываешь по Москве вакансии на php с ценником 140к и выше, везде хайлоад проекты на php. Естественно, там пайплайны выносят на go, очереди на реббите или кафте, кеши и мапы на редисе, логи на эластике и прочее. Но основная кодовая база на php. И знаешь, как-то работает все и приносит деньги. И даже новые разработчики приходят и продолжают развивать проект без боли.

                                            3) Восьмерка php с её jit — это еще один шаг к тому, чтобы сделать из php java. Почему это хотят сделать? Читаем пункт номер 1.
                                              +2
                                              Я как раз-таки писал на php разное, в том числе и микросервисы. И что-то вроде прокси делал однажды. И хайлоад-проект развивал.
                                              И пришел к осознанному выводу, что php плох в этом. Гораздо проще заюзать другие технологии.

                                              А вот там, где есть сложная однопоточная бизнес-логика без особой нагрузки — php рулит.
                                                –10
                                                «Гораздо проще заюзать другие технологии» — кому проще? Какому-то криворукому программисту, что не умеет готовить ПХП — возможно. Но не бизнесу, у которого попросят бюджет на рефакторинг. И не тех-диру, которому придется уволить всех разработчиков и нанять ребят с другим стеком и опытом, либо ждать пока существующие пересядут на другой стек.

                                                Если у тебя понимание, как у хлебушка, а язык это синтаксический сахар и «асинхронность ибо круто» — иди лучше в другую сферу, программирование не твое.
                                                  +4

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


                                                  Программисты с мозгами легко осваивают новые языки, тем более такие простые как go. Более того, каждый второй php-шник уже попробовал сделать helloworld на Go (сужу по своей команде и по опыту проведения собеседований)


                                                  Про nodejs я вообще молчу — js в каком-то виде знают все, примеров по вебсокетам в инете полно.


                                                  Ждать ничего не надо, попробуйте, это совсем просто.


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


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

                                                    +3
                                                    Просто задам один вопрос: если надо будет делать чат службы поддержки на PHP, как вы будете это делать?

                                                    centrifugo
                                                      +3
                                                      Если вы про centrifugo от ребят из Авито (Ну как Авито, от Саши =)), то там Golang под капотом
                                                        +9
                                                        Да. Я его тут привел затем, что для приложения на PHP Centrifugo будет как внешний сервис, доступный через HTTP API. Погружение в go будет совершенно ненужно для решения поставленной задачи (создания чатика). Достаточно умения развернуть Centrifugo и сделать к нему запросы. Centrifugo поможет с удержанием постоянных соединений до клиента.
                                                      –22
                                                      Дайка подумаю, как же я сделаю чат службы поддержки на PHP. Ну наверное также, как и ребята из Avito/LiveTex/LivePerson/Zopim/JivoSite/Shopify и прочих.

                                                      Сделаю бизнес-логику и API на PHP, сделаю чат-сервер демон на node.js/go/java, который при старте загрузит информацию через API (написанное на php) в контекст и будет гонять все через веб-сокеты, а по окончанию чата сбросит все в базу опять же через апи написанное на PHP.

                                                      ___

                                                      У тебя, конечно, написано, что ты тим-лид и прочее. Но не позорься, удали пост и иди в яндекс-такси потаксуй лучше. Раз банальные бизнес-кейсы, которые уже решены десять раз не знаешь, как сделать.
                                                        +4
                                                        Ну т.е. не на php, а на смеси php с нодой и го.
                                                        О чем собственно и статья. Если бы в php встроили асинхронные штуки, то можно было бы обойтись без ноды и го.

                                                          +6

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

                                                          0
                                                          Просто задам один вопрос: если надо будет делать чат службы поддержки на PHP, как вы будете это делать?
                                                          Ratchet может быть?
                                                            +2
                                                            Расскажу свой случай. У нас была задача такая: от пользователя сообщения должны были приходить через некую прослойку, которая в итоге посылала сообщения через NATS в наше приложение. При этом наше приложение должно было держать вебсокет до админки системы (чат службы поддержки)

                                                            Т.е. по сути php должен был слушать сразу два места: NATS и Websocket и реагировать на них. Все что пришло через вебсокеты, отправлять в NATS, всё что пришло из NATS отпроавлять в вебсокеты. Попутно сохраняя в базе.

                                                            Мы нашли библиотеку для NATS, но она делала что-то вроде `$client->wait(1);` типа жди сообщений. Но как при этом еще и сообщения вебсокетов ждать — это вопрос.

                                                            Мы конечно придумали адову схему с очередями и кучей демонов. Но потом поняли, что на go это делается элементарно. И поддержка вебсокетов/nats там лучше. И контейнер с гошным демоном весит очень мало (только сам бинарь по сути). Одни плюсы для таких задач.

                                                            С тех пор наша команда стала PHP/GO

                                                              +2
                                                              Даже в примере PHP NATS — есть пример как слушать без того чтобы зависать на этой строке.

                                                              github.com/repejota/phpnats

                                                              $client->subscribe(
                                                                  'sayhello',
                                                                  function ($message) {
                                                                      $message->reply('Reply: Hello, '.$message->getBody().' !!!');
                                                                  }
                                                              );


                                                              Так что может быть проблема в том что в вашей библиотеке не было нужного функционала или же вы его не нашли?

                                                              Но в любом случае, вы выбрали конкретный нишевый пример который у вас, в вашем проекте был. 99% программистов даже не слышали про NATS и он им не нужен
                                                                +1

                                                                Э-э-э, нет, это так не работает. Даже я со своим нулевым опытом в PHP вижу, что без вызова wait никакой subscribe работать не будет.


                                                                Во-первых, общие соображения: кто-то все равно должен "крутить" цикл чтения, и если он внутри библиотеки — то он и окажется "точкой зависания".


                                                                Во-вторых, быстрый поиск по репозиторию показывает, что чтение сообщений из сокета в библиотеке именно в этом методе wait и находится.

                                                                  +1
                                                                  вот этот wait можно вызывать с параметром 0
                                                                  и в этом случае он не будет блокировать выполнение.

                                                                  Но даже если бы блокировал — это проблема ПХП или же проблема библиотеки?
                                                                    0

                                                                    Да нет, всё равно будет блокировать. Представьте, что из сокета пришло "MSG" и всё — тогда wait начнёт читать пришедшее сообщение и будет ждать пока придёт основная часть.


                                                                    Плюс любая запись в сокет блокирующая.


                                                                    Плюс не вполне понятно в какие моменты времени этот wait(0) нужно дергать, делать это в бесконечном цикле — тоже так себе затея.


                                                                    Кстати, там на самом деле надо не wait(0) писать, а wait(-1), потому что 0 означает "читать до закрытия сокета". Да и wait(-1) тоже не так как хотелось бы работает...


                                                                    Но да, это всего лишь одна неудачная библиотека.

                                                                      0
                                                                      Там есть функция:
                                                                      \Nats\Connection::setStreamTimeout которая позволяет ставить таймаут на сокет, т.е. получается что receive вылетит по таймауту в этом случае.
                                                                        +2

                                                                        Но задача-то заключается в реагировании на сообщения из веб-сокета сразу же, а не между тайм-аутами Nats

                                                                          –1
                                                                          А можно узнать, зачем в одной точке слушать два источника сразу?
                                                                            0

                                                                            Потому что это не точка, а канал между двумя точками.

                                                                              0
                                                                              CQRS не, не работает?

                                                                              Почему надо страдать и делать двунаправленный канал. Когда можно поднять два однонаправленных канала?
                                                                              Какие у нас ограничения на это?
                                                                                +1

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


                                                                                Что же до страданий — то, собственно, в этом и проблема: простейший двунаправленный канал — это страдания, хотя казалось бы, что там сложного-то?

                                                                                  –1
                                                                                  Не-не. Речь выше шла о том что мы должны слушать 2 разных канала в одной точке.
                                                                                  nats + websocket

                                                                                  И вот я пытаюсь понять — зачем люди пытаются страдать?
                                                                    –1

                                                                    Неблокирующему IO в PHP уже лет 20 минимум. Да, это всего лишь биндинг к select и ко. Можно биндинги к libevent прикрутить. В общем в таких постановках задачи на PHP решаются. Другое дело, что очень многие PHP-разработчики, без навыков, скажем так, разработки на C, за разумное время с приемлемым качеством не смогут разработать что-то вроде шлюза между, например, веб-сокетами, раббитом и попутным хождением в веб-сервис.

                                                                      0

                                                                      Куда бы биндинги не были прикручены, операция ожидания где-то должна быть — не дело скрипту жрать весь процессор без сетевой активности.


                                                                      Эта операция может быть внутри прикладной библиотеки или снаружи. Если она внутри — то код будет на этом вызове зависать независимо от типа используемых сокетов. А если она снаружи — то API библиотеки неизбежно будет выглядеть сложнее чем у PHP NATS (ну или у библиотеки будет зависимость от какого-нибудь ReactPHP, что также не наблюдается).

                                                        +2
                                                        Единственная причина почему пхп развивается так, а не иначе — это желание бизнеса

                                                        Дико плюсую: недавно был отличный доклад на эту тему на онлайн-митапе.
                                                          +8
                                                          Восьмерка php с её jit — это еще один шаг к тому, чтобы сделать из php java. Почему это хотят сделать? Читаем пункт номер 1.


                                                          Сделать из PHP Java, только хуже. Java в свою очередь сейчас «собирается» из Scala и Kotlin (если смотреть JVM-мирок), только хуже, чем они.

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


                                                          И всего вышесказанного выходит, что PHP — лучший выбор для legacy проекта, который по «причинам бизнеса» не вариант рефакторить на что-то адекватное.

                                                          везде хайлоад проекты на php


                                                          Совсем очевидно, что новый проект с уклоном в хайлоад никто в здравом уме не будет делать на PHP. И не потому что язык плохой — а потому что конкурентный асинхронный код всегда будет эффективнее. Нормальная система типов всегда будет давать больше качественных абстракций и (что самое главное) гарантий работоспособности кода.
                                                            +2
                                                            А на чём бы вы начали писать новый проект для веба? Всё-таки на старте обычно непонятно будет хайлоад или нет. А PHP — это не только язык, но и куча готовых решений для веба, Symfony/Laravel/Yii, куча библиотек в composer и т.д.
                                                              +2

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


                                                              Я бы начал на Go. Многие пробуют Elixir или даже раст, но порог входа выше при неочевидных плюсах...


                                                              Дополнительный плюс статической типизации — сложнее накосячить и проще рефакторить.

                                                                –3
                                                                Я бы начал на Go. Многие пробуют Elixir или даже раст, но порог входа выше при неочевидных плюсах...

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


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

                                                                  +1
                                                                  Плюсы статической типизации — это миф. Сейчас хайпово повторять эту мантру, но никаких доказательств этому нет, и быть не может.


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

                                                                  Конечно, никто не дает вам 100% гарантий. Это реальный мир — тут всегда есть погрешности и трейдоффы. Но просто сравните строго типизированный язык с динамически типизированным — и там и там есть типы, просто во втором случае они в голове у автора кода… т.е. грубо говоря — эти знания разработчик не коммитит в проект, а уносит с собой по окончании рабочего дня. Не трудно догадаться, что с точки зрения работодателя это такая себе ситуация и ему хотелось бы, чтобы все знания оставались в проекте.
                                                                    –5

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


                                                                    Строгая статическая типизация — это и есть доказательство работоспособности.

                                                                    Да-да. 2.0 * π * R как формула для вычисления площади круга сразу же будет завернута компилятором, как только вы укажете, что входной параметр — float.


                                                                    во втором случае они в голове у автора кода

                                                                    Да-да. Про типы все слышали, про документацию пока не все.


                                                                    с точки зрения работодателя это такая себе ситуация

                                                                    Мне не надо догадываться, я принимаю непосредственное участие в выборе стека.

                                                                      0
                                                                      Про типы все слышали, про документацию пока не все.


                                                                      Пишем типы в комментах?) Великолепное решение (нет). Если код нельзя читать и понимать без доков, то у меня плохие новости. Я не имею ввиду какую-нибудь опенсорс библиотеку. Я про внутренний проект и документация\типизацию именно внутреннего проекта.

                                                                      как формула для вычисления площади круга сразу же будет завернута компилятором


                                                                      Не уверен, что понял вас.

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


                                                                      :)
                                                                      Каким большинством? Имеется какая-то статистика? Как минимум не очевидно, что большинство (разработчиков я так понимаю?) пишет на статически типизированных языках. А про тезисы «да-да» лучше умолчать.
                                                                        –2
                                                                        Пишем типы в комментах?

                                                                        Нет.


                                                                        Если код нельзя читать и понимать без доков, то у меня плохие новости.

                                                                        В код докера загляните. Да просто в любую библиотеку чуть сложнее лефтпада.

                                                                          +1
                                                                          Возможно вы не успели заметить — я дописал одно предложение к моему комменту:

                                                                          Я не имею ввиду какую-нибудь опенсорс библиотеку. Я про внутренний проект и документация\типизацию именно внутреннего проекта.


                                                                          Кажется, что у опен сорс проектов своя специфика и там действительно нужно более подробно все документировать. В корпоративной разработке зачастую просто нету столько ресуров. Но повторюсь: чем больше знаний закоммичено непосредственно в проект — тем лучше, и не важно что это: типы, доки.
                                                                            –4
                                                                            В корпоративной разработке зачастую просто нету столько ресуров.

                                                                            Я не пропущу код без внятной документации интерфейса на код ревью.


                                                                            чем больше знаний закоммичено непосредственно в проект — тем лучше, и не важно что это: типы, доки

                                                                            Ну а так-то да, с этим никто и не спорит. Просто это совсем не то же самое, с чем вы в эту ветку пришли.

                                                                              +3
                                                                              Ну а так-то да, с этим никто и не спорит. Просто это совсем не то же самое, с чем вы в эту ветку пришли.


                                                                              Эм, у меня там было пару тезисов. Уточните тогда с чем это не стыкуется

                                                                              Я не пропущу код без внятной документации интерфейса на код ревью.


                                                                              Ну, окей. Но это ваш личный опыт, применительно к проектам, в которых вы проводите код ревью.

                                                                              А вот компилятор не пропустит в продакшен код с тайп-еррорами любого проекта, который его использует. И количество таких проектов, скажем так, значительно больше, чем то, что может проревьювить 1 человек.
                                                                        +1
                                                                        Да-да. 2.0 π R как формула для вычисления площади круга сразу же будет завернута компилятором, как только вы укажете, что входной параметр — float.

                                                                        Почему?


                                                                        То есть, я могу придумать ряд причин, почему, но мне интересно, что вы имеете в виду.

                                                                          0
                                                                          что вы имеете в виду

                                                                          Я, как всегда, имею в виду сарказм.


                                                                          Чтобы компилятор его правильно завернул, нужны типы «длина» и «площадь», и правильное определение функции area (а не выведенный тип, который окажется для такой формулы длиной, и это можно и не заметить и пропустить, в принципе).


                                                                          Но адепты максимы «типы — это панацея» часто ограничиваются флоатом, потому что флоат — это уже тип, а типы нас спасают от всего, кроме геморроя (ходят слухи, что скоро начнут спасать вообще от всего).

                                                                            0
                                                                            Так а кто мешает ввести пользовательские типы? Смысл наличия типов ведь в том, что компилятор может проверить их, а не в том, что в каком-то условном ЯП перечислены все возможные их варианты.
                                                                            А ваш пример — это ошибка в правильном указании типов. Да, от таких ошибок статические ЯП не защищают…
                                                                              +2
                                                                              Мне кажется, автор комментария выше говорил про то, что если вы запишете в коде неправильную логику (формулу), то компилятор не проверит её по Вселенской Базе Данных и не упадёт при несовпадении с наблюдаемой реальностью, а примет как факт. В принципе, логично, как и то, что компилятор не сможет проверить, что заказчик просил у вас платежный шлюз, а вы написали таймер для йоги.

                                                                              Наверно это может проверить только вероятностная логика какой-нибудь нейронки: «что-то это не выглядит как платёжные шлюзы, с которыми у меня был опыт». Можно использовать бионейронки и называть это QA.
                                                                        –1

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

                                                                          +1
                                                                          причем даже в очень хамских статьях


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

                                                                          Плюсы статической типизации переоценены


                                                                          Поделитесь ссылкой если у вас получится объективное сравнение, мне будет очень интересно почитать, особенно с точки зрения сложных (больших) проектов с длительным жизненным циклом (регулярные релизы\рефакторы) или проектов из области критических бизнес-процессов (важно чтобы работало корректно)
                                                                        +1
                                                                        В го кооперативная многозадачность

                                                                        Кажется с 1.14 уже не так. Не давно читал.


                                                                        Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. This is supported on all platforms except windows/arm, darwin/arm, js/wasm, and plan9/*.
                                                                  0
                                                                  swoole. посмотрите фреймворк hyperf, поддерживает psr. Coroutine на swolle даже быстрее чем на golang.
                                                                    0
                                                                    Я не пытаюсь сказать, что PHP какой-то уж совсем медленный. Беглое гугление говорит, что swoole — довольно интересный инструмент, но так или иначе — нужно разбираться в том, как работают все эти инструменты, чтобы эффективно использовать их в проде. Кажется, что swoole не переварит блокирующие операции (хотя может я и не прав).

                                                                    В общем, мой поинт остается в том, что если Вам реально нужна производительность, то асинхронщина + мультитрединг Вам в руки. А лучше всего они будут работать на тех языках, где это из коробки есть (а не приделано сбоку).

                                                                    быстрее чем на golang

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

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

                                                                        0
                                                                        Производительность бывает разная.

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

                                                                        где многопоточность её наоборот просадит

                                                                        В целом — да, потому что не всегда многопоточку можно сделать красиво и правильно.
                                                                          0
                                                                          В целом — да, потому что не всегда многопоточку можно сделать красиво и правильно.

                                                                          Я скорее про те случаи, когда оверхед на работу с потоками будет больше, чем обсчитать всё линейно в текущем. Как многопоточность не готовь, она не будет бесплатной.

                                                                        0
                                                                        Как это не переварит блокирующие операции. Я же говорю, корутины. В этом из и суть. Свул уже поддерживает корутины для mysql, Redis, http,…
                                                                  +8

                                                                  Интересно наблюдать как из года в год всё хоронят PHP. А всё потому что нет его понимания.
                                                                  Это кстати частая проблема "тим-лидов" приходящих из других ЯП: ожидание, что выработанная картина мира подойдёт везде..


                                                                  PHP — это не про чаты или real time с gRPC. PHP про бизнес логику. На текущем уровне развития языка, real time лучше оставить для рассчитанных на это ЯП.


                                                                  Также стоит упомянуть, что на обычном кейсе с множеством запросов в БД — PHP неплохо тягается с упомянутыми автором Go, Java и C#.
                                                                  Например, по ссылке ниже, можно заметить, что Go идёт только за PHP.
                                                                  https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query&l=zijn99-1r
                                                                  Исходники и описание окружения в описании.

                                                                    0

                                                                    Я вот только не пойму, почему на более чистом и простом (в смысле синтаксиса) Python эта бизнес логика будет хуже? Или ее будет сложнее написать? При том что в Python async/await отлично работают.


                                                                    Например, по ссылке ниже, можно заметить, что Go идёт только за PHP.

                                                                    Тут надо понимать что какой ценой был получен этот результат. И если говорить про БД то с PHP приходится использовать сторонние пулеры для Postgres.

                                                                      –1

                                                                      Сложнее. Или в Python сделали приватные и защищенные методы? Да и с ORM не всё хорошо было, насколько помню — ничего похожего на Doctrine.

                                                                    +1
                                                                    Давно витала такая мысль. С каждым php дайджестом замечаю, что в 8 версию добавляется только сахар, который можно реализовать существующими средствами. Все эти фичи только усложняют язык, который по мне уже достаточно хорошо в 7 версии.
                                                                      +3
                                                                      А чем плох сахар? Грубо говоря, есть же С, и С++ — на них то точно можно реализовать всё что угодно, существующими средствами. Но нет, придумали кучу других языков, чтобы ускорить и упростить разработку. Вот и с «сахарком» так.
                                                                        +2
                                                                        Сахар повышает порог входа в язык, пусть и не значительно. Ну и с сахаром важно аккуратно обращаться — нет нужды объяснять, что насыпав в чашку сахар до половины — чай получится не самый лучший.

                                                                        На текущий момент в PHP с сахаром кажется всё хорошо. Но важно не перейти эту тонкую грань, когда сахара слишком много. По моим ощущениям — PHP как раз ходит на этой грани.
                                                                      –2
                                                                      и это говорит тим лид? тим лид забыл что инструмент выбирается под задачу? не хватает возможностей PHP100500? возьми Golang,nodejs для поддержки вебсокетов. Это будет тупой сервис который через какой-то прокси(база, редис, кафка, что угодно еще) прокидывать нужные данные в основную кодовую базу.

                                                                      Нужна скорость, реальная скорость для обработки, ну скажем картинок, Rust или С в помощь, но при этом кодовая база остается на PHP.

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

                                                                        +9
                                                                        ( Блин, в каждом втором комментарии переход на личности или апеляция к аворитетам. Какая разница — тимлид или хрен с горы, важны только аргументы)

                                                                        Да так и делаю часто, смесь технологий. О чем и написал в статье.

                                                                        Но было бы круче, чтобы php сам умел решать типичные веб-задачи, сам умел общаться с вебсокетами и кафкой одновременно, причем из коробки.
                                                                          –4
                                                                          так… умеет… почему нет. делаете демона, плодите чайлдов, которые в свою очередь общаются со всеми и вся, общаетесь с кем хотите.

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

                                                                            Если на других языках это делать удобнее, то зачем это делать на том, на котором неудобно? Вы мазохист?
                                                                              +1

                                                                              Делать на них может и удобнее, но это надо:


                                                                              • выбрать что-то конкретное: Node.js (с TypeScript или без?), Java, Kotlin, C#, Go, Python, Ruby, C, C++ — вот какой из них подходит лучше всех для таких задач я не знаю. Как выбрать?
                                                                              • изучить самому, обучить минимум двух человек в команде и не факт, что они прямо рады будут, что не услышишь "я на PHP пришёл программировать!" или "тогда снимай с меня задачи остальные на месяц — я курсы будут проходить в рабочее время", а в дальнейшем при ротации или росте учитывать это в требованиях.
                                                                              • время от времени переключаться между синтаксисами и семантиками, что может приводить к идиотским по меркам языка ошибкам. Вот в PHP пустой массив приводится к false, а в JS/TS к true. И у любого JSника возникнет, как минимум, недоумение при виде условия if (items) {},
                                                                        –1
                                                                        Увы и ах, как ни ускоряй PHP, но под каждый HTTP-запрос выделяется отдельный процесс — это поведение прибито гвоздями


                                                                        Это ложь. Удалите пожалуйста свою статью. Вы вводите в заблуждение молодые не окрепшие умы и их детскую психику.
                                                                          +3
                                                                          Т.е. вы хотите сказать, что один php-fpm worker может обрабатывать сразу несколько http-запросов?
                                                                            +4
                                                                            php-fpm это fastcgi — он не обрабатывает http запросы. HTTP запросы обрабатывает веб сервер.
                                                                              0
                                                                              Ok. Веб-запросы обрабатывает nginx, nginx делает запросы к phpfpm. Phpfpm обрабатывает каждый запрос отдельным процессом.
                                                                                0

                                                                                Есть же не только php-fpm

                                                                                  +3
                                                                                  Phpfpm обрабатывает каждый запрос отдельным процессом.

                                                                                  Попробуйте запустите php-fpm с pm.static где будет 1 дочерний процесс. И выполните 2-4 HTTP запроса одновременно. И вы увидите что всё ок и ваше утверждение ложь.

                                                                                  А еще вы можете написать свой веб-сервер на php который будет обрабатывать одновременно >= 2 rps. Можно сделать его на чистом exec и pipeах. И всё это будет работать одновременно. Если нужно покрасивей и побольше контроля, можно взять pcntl. Но если вам нужно шарить данные между http запросами, вы можете использовать pthreads.

                                                                                  Делаем вывод что ничего в php гвоздями не прибито. Кроме того вы можете написать extension как на PHP, так и на C. И это будет очень быстрое решение.
                                                                                  Пожалуйста удалите статью или исправьте недочеты.
                                                                                  Не вводите людей в заблуждение.
                                                                                    0
                                                                                    Или взять уже готовый amphp/cluster.
                                                                                      0
                                                                                      можете использовать pthreads
                                                                                      Он умер. Вместо него теперь parallel.
                                                                                        +6
                                                                                        Вы сами то попробуйте. Ваши запросы, хоть и выполнятся в конце концов, но будут делать это по очереди.

                                                                                        Возьмите скрипт, который делает sleep 5 сек, а потом записывает в лог время
                                                                                          –2
                                                                                          Непонятно про что именно Вы (в комменте на который Вы отвечали несколько вариантов), но если Вы про pcntl, то все вполне выполняется одновременно…
                                                                                            –4
                                                                                            $ mkdir tmp && cd tmp
                                                                                            $ echo "<?php exec('php '. __DIR__ . '/worker.php'.' > /dev/null 2>/dev/null &');" > ./server.php
                                                                                            $ echo '<?php sleep(5); file_put_contents(__DIR__."/test.log", date("H:i:s")." -> worker_id =".uniqid()."\n", FILE_APPEND);' > ./worker.php
                                                                                            $ php server.php
                                                                                            


                                                                                            Через 5 секунд появится файлик test.log.
                                                                                            Можете запустить из >= 2 терминалов и увидите
                                                                                            $ cat test.log 
                                                                                            15:41:27 -> worker_id =5ed648f71c829
                                                                                            15:41:27 -> worker_id =5ed648f71d05e
                                                                                            


                                                                                            Код веб сервера будет чуть посложней, но смысл тот же.
                                                                                            UPD: можно использовать встроенный в php web сервер для демонстрации
                                                                                            $ php -S localhost:3111 server.php
                                                                                            

                                                                                            И обратитесь одновременно через curl -v localhost:3111
                                                                                            Также увидите что worker_id будет разный.
                                                                                            Для большей очевидности «асинхронности» можно добавить в server.php ответ
                                                                                            $ echo "<?php exec('php '. __DIR__ . '/worker.php'.' > /dev/null 2>/dev/null &'); die('test\n');" > ./server.php
                                                                                            

                                                                                              +2

                                                                                              Но ведь ваш server.php создаёт по процессу на каждый запрос!

                                                                                                –3
                                                                                                Я отвечал на вопрос о одновременности, а не о количестве запросов на процесс.
                                                                                                  –5
                                                                                                  вот скрипт код который обрабатывает много запросов одновременно не «порождая других процессов»
                                                                                                  <?php
                                                                                                  
                                                                                                  $socket = stream_socket_server("tcp://127.0.0.1:3111", $errno, $errstr);
                                                                                                  
                                                                                                  if (!$socket) {
                                                                                                      die("$errstr ($errno)\n");
                                                                                                  }
                                                                                                  $log = __DIR__ . '/test.log';
                                                                                                  while ($connect = stream_socket_accept($socket, -1)) {
                                                                                                      file_put_contents($log, date('d.m.Y H:i:s').' -> request_id = '.uniqid()."\n", FILE_APPEND);
                                                                                                      fwrite($connect, "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\nHELLO");
                                                                                                      fclose($connect);
                                                                                                  }
                                                                                                  
                                                                                                  fclose($socket);
                                                                                                  

                                                                                                  Я еще раз повторюсь — этот код публикую для ответа на некорректную инфомрацию в статье о том что HTTP запросы можно обрабатывать 1 процессом. Некорректно сравнивать кол-во запросов на процесс, с кол-вом долгих процессов и асинхронностью в php.
                                                                                                    0

                                                                                                    А где здесь php-fpm?

                                                                                                      0
                                                                                                      Но он это сделает не одновременно. Сначала выполнится один, потом второй.
                                                                                          –1
                                                                                          Он их выполнит последовательно. Воркеры не умираю после выполнения запроса (но фпм может убить воркер после того, как он обработает N запросов, это как настроишь).
                                                                                        +2
                                                                                        А знает ли средний PHP-шник что-нибудь про ReactPHP? Нет!

                                                                                        Тем, кто захочет узнать, посоветую скринкасты, цикл блогпостов или книгу Сергея Жука из Skyeng про основы.
                                                                                          0
                                                                                          Кстати, Сергей Жук на каком-то выступлении прямо сказал, что для таких целей зачастую лучше использовать другие языки
                                                                                            +2
                                                                                            Сергей Жук на каком-то выступлении прямо сказал, что для таких целей зачастую лучше использовать другие языки

                                                                                            Если вы о докладе на митапе ростовского PHP-сообщества, то речь шла о выборе для новых проектов. Вот этот кусок выступления — youtu.be/2TBrGX1-mJY?t=12195

                                                                                            «Если говорить про выбор технологии, то… если у вас новый проект, и стоит вопрос, что выбрать, конечно, не ReactPHP, потому что это сбоку сделано. И даже, наверное, не ноду»

                                                                                          +1
                                                                                          Ниша по сути — это админки со сложной бизнес-логикой (т.е. на Golang такое писать нецелесообразно) и не особо нагруженные сайты. Здесь PHP — лидер.

                                                                                          … и это 90% современного веба
                                                                                            +5
                                                                                            99% веба это интерфейс доступа к базе данных в том или ином виде

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

                                                                                              Так все программирование по сути — чтение/обработка/запись данных в том или ином виде.

                                                                                            –2
                                                                                            Я согласен с автором только в одном — то что ПХП не совсем подходит для асинхронных задач, где нужно await/async и тп. Но моё мнение — это даже хорошо.

                                                                                            Основная фишка ПХП — это всё же то что на нём достаточно просто программировать и достаточно легко его использовать для решения бизнеса. (мы же помним, что программист должен решать задачи бизнеса, а не программировать на работе ради развлечения? )

                                                                                            Давайте немного отойдем от синтаксиса языка и подумаем про экосистемы.

                                                                                            В данный момент (по моему мнению!), основные крупные экосистемы в ВЕБЕ это: PHP, Python, NodeJs, GO?, Java, .NET, Ruby.

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

                                                                                            Java — корпорации только, писать с нуля небольшой проект на нём — надо быть очень фанатом.

                                                                                            Ruby — вроде бы его популярность идёт вниз последнее время, но, насколько я знаю, он никогда небыл сильно популярен, могу ошибатся.

                                                                                            GO — вроде бы хайп начинается на его тему, но даже на этом фоне, он нишевый язык, для определённых задач. На нём писать обычные сайты, а не микросервисы — насколько это легко вообще? Есть ли темплейты для хтмла, ORM, и тп из коробки (в любом крупном фреймворке). Язык создан в 2007 году, но за 13 лет он не набрал большого хайпа и я бы не заметил огромной экосистемы для него, в которой можно найти библиотеки для подключения ко всему чему угодно. Писать НЕ хайлоад на GO — насколько удобно?

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

                                                                                            NodeJs — по своему язык хорош: Быстрый, есть многие вещи из коробки, много библиотек. Из минусов — слишком молодой, местами достаточно нестабилен, node_modules-hell (слишком много зависимостей), очень много разных библиотек сомнительного качества. Нет строгой типизации и соответствющие проблемы с этим. Промисы добавляют тоже достаточно много проблем — читать бактрейсы выполнение их — то ещё удовольствие.
                                                                                            Огромный плюс — интеграция с react & angular, в частности server side rendering.

                                                                                            Typescript — решает проблему строгой типизации nodejs, но добавляет кучу других проблем. В частности то что часть библиотек используют её, а часть нет. Очень много вариантов синтаксиса, в частности, при изменении конфига — возможно придётся менять все импорты. Вхождение в язык далеко не простое.

                                                                                            PHP — тут я предвзят конечно же .
                                                                                            Из плюсов — стабильность, много библиотек, много серьёзных фреймворков в которых все есть из коробки (Laravel, Yii, Symphony, десятки менее известных), много информации, производительность адекватная для больишнства случаев, относительно легко начинать и найти дешёвых разработчиков. Из минусов — нет промисов, асинхронности, невозможно использовать в других сферах.

                                                                                            Все плюсы и минус конечно субъективны, и я не хочу никого обидеть. Каждый язык которым пользуются — он чем то хорош. В этом месте стоит вспомнить что нет серебрянной пули… Микроскопом так же неудобно забивать гвозди, как и с помощью молотка рассматривать микробы.
                                                                                              +4

                                                                                              .NET Core уже отвязан от Windows и неплохо так дружит с контейнерами.

                                                                                                0
                                                                                                Насколько удобно разрабатывать под .NET чисто под маком и под линуксом? :)
                                                                                                И насколько это идеологически правильно?

                                                                                                Я не про запускать на сервере, а именно разрабатывать. Есть ли нативные средства разработки?
                                                                                                  +4

                                                                                                  не пробовал, но предположу, что с использованием JetBrains Rider проблем быть не должно.

                                                                                                    +1
                                                                                                    Насколько удобно разрабатывать под .NET чисто под маком и под линуксом?

                                                                                                    Есть ли нативные средства разработки?

                                                                                                    JetBrains Rider — вполне зрелая кроссплатформенная IDE для разработки под .NET.
                                                                                                      0

                                                                                                      Я не фанат C# но писал для него под маком в Visual Studio Code и тулзами от net core очень уверено и удобно. Т.е. к тулзам и окружению не было никаких претензий.

                                                                                                    0

                                                                                                    Что-то про .NET вы написали очень устаревшую информацию. У .NET Core уже третья версия вышла, и скоро выйдет пятая...


                                                                                                    Ладно первую версию .NET Core можно было нестабильной считать, но сейчас-то...

                                                                                                      0
                                                                                                      я нигде не писал что .NET нестабилен.
                                                                                                        0

                                                                                                        Но вы писали что для .NET нужны серверы на винде.

                                                                                                          0
                                                                                                          тоже это не писал.
                                                                                                          Я писал про то что .NET связан с Микрософтом и сопутствующей экосистемой.
                                                                                                          Насколько в нём легко делать вещи linux way? Разрабатывать под маком и линуксом, использовать не виндовс мир решения и тп?
                                                                                                          Т.е. можете ли вы работать под .NET вообще никогда нигде не используя виндовс, его компоненты и тп?
                                                                                                          Насколько это будет удобно?
                                                                                                            0

                                                                                                            Ну нет, вы написали вот так:


                                                                                                            Из минусов — не на любой хостинг поставишь. Т.е. требует отдельных серверов.

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

                                                                                                              0

                                                                                                              Ну так-то да — не на любой. Зато PHP вообще везде есть, даже, не к ночи будь помянут, на nic.ru

                                                                                                              0

                                                                                                              мы же про web-разработку? где в ней место windows, ее компонентам и т.п.? если подразумевался IIS, то .NET Core приложения прекрасно работают без него. соответственно, никаких выделенных серверов под них не требуется. про дружбу с контейнерами я уже писал выше.

                                                                                                                0
                                                                                                                Насколько в нём легко делать вещи linux way?

                                                                                                                Что под этим подразумевается здесь?
                                                                                                                0
                                                                                                                Есть у меня пара знакомых, которые под .NET работают. Практически все про линукс только слышали, но в живую никогда не видели, не то что запускать на нем что-то или тем более разрабатывать. С одним плотно работали вместе, он параллельно на php писал, много с mysql и постгрес работал. Потом уволился и ушел на чистый .NET. Через несколько месяцев я ему статью с хабра по настройке разработки.НЕТ под линукс кидал, он покрутил пальцем у виска и сказал — никто в здравом уме такое в прод не потянет, людям работать надо, а не в игрушки играть…
                                                                                                                  0

                                                                                                                  Тут он, конечно, погорячился — но причина такого ответа вполне понятна. Если у него уже есть винда и настроенная среда разработки — ради чего вообще играться со сменой ОС и всех инструментов?


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

                                                                                                                    +1

                                                                                                                    А у меня перед глазами несколько команд, которые пишут микросервисы на .NET Core и деплоят их в линуксовых контейнерах в прод. Это они в игрушки играют?
                                                                                                                    ps: или речь именно про настройку рабочего окружения для разработки? если да, то что мешает для разработки использовать windows? разработчики на PHP же не ставят себе тот линукс, что будет на хостинге.

                                                                                                                      0
                                                                                                                      Либо разговор был давно, либо ваш знакомый несколько отстал от жизни: крупный бизнес и правительство сейчас режут затраты и наоборот требуют поддержку Linux и PostgreSql и перед разработчиками на .Net встает выбор или доучиваться до .net core или переучиваться на другой язык. Так что это Linux для серьезного .Net разработчика сейчас это не «игрушки играть», а must have.
                                                                                                                        0
                                                                                                                        А у меня есть примеры, что разработчики разрабатывают на .NET/.NET Core на Windows, а деплоят это и на Linux, и на Windows. Т.е. используется мультитаргет, а запускается где удобнее. И волосы густые и шелковистые.
                                                                                                                  0

                                                                                                                  Delphi забыли!!!

                                                                                                                    0
                                                                                                                    Вы путаете строгую и статическую типизации. p.s. питон не то что можно хоть куда поставить, а даже больше — он уже почти везде стоит.
                                                                                                                      0
                                                                                                                      Если язык позволяет выполнить
                                                                                                                      def sign(x): return (x > 0) - (x < 0)
                                                                                                                      или
                                                                                                                      not []
                                                                                                                      , то о какой строгой типизации может идти речь?

                                                                                                                      Да, в Python меньше, чем в PHP, автоматических преобразований типов, но они есть. В остальном же контроль типов в Python отсутствует полностью: тип переданного в подпрограмму параметра можно проконтролировать только вручную; уровень даже не PHP, а JavaScript.
                                                                                                                        0
                                                                                                                        Вы привели примеры перегрузки операторов 'not' и '>', '<'. Причём тут строгая типизация?
                                                                                                                          0
                                                                                                                          Если вы не поняли первый пример, то там происходит арифметическое вычитание логических значений — при котором False неявно преобразуется в 0, а True — в 1. И это демонстрирует типичную слабую типизацию.

                                                                                                                          Что касается not, то в семантику языка изначально зашита автоматическая трактовка значений большинства (как минимум) типов как boolean. И такая семантика логических операций — не перегрузка, а ещё один пример типичной слабой типизации а-ля JavaScript (и дополнительный источник ошибок в коде).
                                                                                                                            +1

                                                                                                                            Что интересно, и то, и другое присутствует и широко используется в C++. Теперь у C++ слабая типизация?


                                                                                                                            Показателем силы типизации можно считать как часто строки неявно приводятся к числам или наоборот. Так вот, в Python этого, кажется, вообще не происходит. В отличии от Javascript и PHP.

                                                                                                                              0
                                                                                                                              Да, в C++ слабая типизация — доставшаяся в наследство от C.
                                                                                                                              Слабость типизации определяется не числами и строками, а:

                                                                                                                              1. наличием в языке механизмов автоматического неявного преобразования типов
                                                                                                                              2. отсутствием контроля типов параметров

                                                                                                                              Так что Python немного выигрывает у PHP в первом пункте и безнадёжно проигрывает во втором.

                                                                                                                              P.S. Языком с действительно сильной типизацией является Go.
                                                                                                                                0

                                                                                                                                Ну и откуда взялся второй критерий?

                                                                                                                                  0
                                                                                                                                  Например, отсюда: Liskov, B; Zilles, S (1974). «Programming with abstract data types». ACM SIGPLAN Notices. 9 (4): 50–59.

                                                                                                                                  При желании легко найти множество источников.
                                                                                                                                    –2

                                                                                                                                    Ну, видимо, в 1974м году терминология ещё не устоялась.

                                                                                                                                      0
                                                                                                                                      Только вот этот тезис никто так и опроверг. Так что он актуален и в 2020-м году.
                                                                                                                                0

                                                                                                                                В Си и плюсах можно легко прибавить int8 к int16 и получить невесть что в итоге. От этого столько багов бывает что ужас.


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

                                                                                                                                  0

                                                                                                                                  Такс такс такс тред о типизации.


                                                                                                                                  Теперь у C++ слабая типизация?

                                                                                                                                  Ну вообще-то да.


                                                                                                                                  Кстати, список или вектор напрямую в bool не кастуется.

                                                                                                                                  0
                                                                                                                                  Если вы не поняли первый пример, то там происходит арифметическое вычитание логических значений — при котором False неявно преобразуется в 0, а True — в 1

                                                                                                                                  Так в питоне как такового нет отдельного булевого типа, он наследуется от целочисленного.
                                                                                                                                  docs.python.org/3/reference/datamodel.html#types
                                                                                                                                  www.python.org/dev/peps/pep-0285
                                                                                                                                    0
                                                                                                                                    Это и есть «слабая типизация» в чистом виде.
                                                                                                                                  +1

                                                                                                                                  Безотносительно перегрузки операторов, строгость типизации — это про то, как легко вам как программисту гарантировать, что программа делает то, что надо, и не делает того, что не надо. И тут что питон, что go весьма далеки от идеала.

                                                                                                                                    0
                                                                                                                                    строгость типизации — это про то, как легко вам как программисту гарантировать, что программа делает то, что надо, и не делает того, что не надо

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

                                                                                                                                      0
                                                                                                                                      строгость типизации — это про то, как вы указываете типы, а кусок железа за вас пишет идеальный доказанно корректный код

                                                                                                                                      Например.

                                                                                                                                        0

                                                                                                                                        Я в курсе, что в академически-чистых примерах это возможно. Экстраполяция на все случаи жизни портит все впечатление.

                                                                                                                                          0

                                                                                                                                          Это понятное дело. Скорее так, шутка, не воспринимайте это как универсальный ответ.

                                                                                                                                            –1

                                                                                                                                            Я-то и не воспринимаю. Восторженные неофиты воспринимают.


                                                                                                                                            Я вчера как раз встрял в длинную дискуссию, не пойми зачем, про рекурсию (сейчас поясню, при чем тут это). Ну вот люди смотрят в JS, а потом сразу в хаскель. И пишут фибоначчи на условном эликсире без TCO. Ты им говоришь: чувак, у тебя тут все взорвется на сравнительно больших числах. А они в ответ: нет, вот смотри: [ссылка на то, что TCO не делает код быстрее] и [ссылка на то, что в хаскеле TCO чаще вредит].


                                                                                                                                            Ты сначала офигеваешь, а потом мямлишь невпопад: так хаскель ленив, там в 99% случаев правильный выбор — guarded recursion, а в JS как ни выделывайся — все взорвется, но даже в хаскеле TCO нужен если вычисления жадные, и вот foldl, в отличие от guarded foldr… И тут внезапно выясняется, что твой оппонент даже не понимает, что такое стек и почему оно взрывается.


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


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


                                                                                                                                            Так и тут: мне не нужен помощник, чтобы не передать кортеж туда, где ждут список. Да, после плюсов — это все выглядит волшебной магией. Но не более. Нельзя сказать, что «легко вам как программисту гарантировать, что программа делает то, что надо, и не делает того, что не надо». Увеличивает этот показатель на проценты, пусть десятки процентов у вовсем новичка — да. Но «гарантировать» — это мимо. См. пример про TCO.

                                                                                                                                              +1
                                                                                                                                              мне не нужен помощник, чтобы не передать кортеж туда, где ждут список.

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

                                                                                                                                                –1

                                                                                                                                                А, типы в качестве документации? — Да, их ровно для этого и придумали. А документацию придумали, чтобы какой-нибудь записной остряк создал мем про самодокументированный код.


                                                                                                                                                Мой преемник прочитает документацию, а не станет наобум слать абы что, и смотреть на ошибки компилятора.

                                                                                                                                                  0

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


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

                                                                                                                                                    –2
                                                                                                                                                    понятной IDE документации

                                                                                                                                                    Ясно, свидетели секты IDE. IDE нужен только тем, кто не умеет писать код, простите уж, ничего личного, просто опыт.


                                                                                                                                                    будет долго гадать, где же тут описание вот этого, одного из тысячи, методов и что за десять параметров в него передаются

                                                                                                                                                    Да-да. Я ровно так код и проектирую. Зато типы сразу превратят мою лапшу — в понятные хорошо изолированные три метода с одним параметром.


                                                                                                                                                    Ясно.

                                                                                                                              0
                                                                                                                              NodeJS часто видел как Middleware. Условно, у вас есть много микросервисов, но на фронте, нужно собрать определенную логику, и на NodeJS крафтиться middleware api.
                                                                                                                              Те кто раньше писали на RoR, кажется что начинают переходить на Phoenix/Elixir.
                                                                                                                              Java — для маленьких проектов не плох. Сейчас все равно почти все упаковывается в контейнеры. А у Java в этом плане все отлично. Тотже проект Quarkus. Тулинг просто отличный. IDE поддержка радует. Материалов к изучению много. Много книг и best practices. Да и сама Java пошла семи мильными шагами.
                                                                                                                              +3
                                                                                                                              Опять же, мы тут всё обсуждаем с точки зрения насколько хорош язык с точки зрения синтаксиса.

                                                                                                                              А если обсудить насколько хорош язык с точки зрения бизнеса?

                                                                                                                              из плюсов:
                                                                                                                              • бесплатный, не требует лицензий
                                                                                                                              • не требует дорогих серверов — можно поставить на любой хостинг или виртуалку за 5 долларов в месяц.
                                                                                                                              • легко найти программистов любого уровня — от начинающих (для простого сайта), до серьёзных которые напишут что угодно.
                                                                                                                              • а можно вообще не искать программистов, попросить эникейщика поднять вордпресс и на нём сделать сайт. вордпресс поставить на любой хостинг за 20 долларов в год.
                                                                                                                              • Если брать бизнес покрупнее, то всё равно язык позволяет выполнять 99% задач бизнеса без особых проблем. Есть крупные, стабильные фреймворки на которые можно легко найти разработчиков.
                                                                                                                              • Обновление языка — достаточно легко, почти нет крупных несовместимых изменений (обновление пхп 5.х до 7.3 проходит почти без проблем)
                                                                                                                              • язык стабилен, нет страха что через 5 лет потребуется всё переписыв