Ловушки для современного PHP


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


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


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


    Примечание


    Далее я буду использовать слово "квалификация" не в ругательном смысле, а как набор необходимых знаний и навыков, необходимых как для работы вообще, так и для работы с некой технологией Х в частности. То есть, разработчик на Symfony квалифицированнее разработчика на Wordpress, потому что ему нужно уметь писать код и работать с БД, а разработчик на Wordpress в целом может во время своей работы из админки и не вылазить.


    PHP для "простых" решений и малого бизнеса


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


    Также язык был крайне нетребователен к инфраструктуре, так как можно было просто поправить нужный файлик на своей VPSке прямо через FTP, без сборок и релизов.


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


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


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


    Где-то здесь находятся и стартапы: имея в начале мало денег и вынужденные выживать среди бесконечных MVP и перестроек, им проще взять что-то максимально простое и дешевое.
    Большинство стартапов, конечно, умирает, но самые удачливые "выстреливают", стремительно обрастая деньгами и более развитыми технологиями, при этом продолжая нести в себе ядро из всем знакомого PHP. Привет, Facebook, VK, Slack, Такси и тд и тп.


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


    PHP для энтерпрайза


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


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


    И всё кажется прекрасным, потому что "энтерпрайзный PHP" действительно даёт возможность нормально писать сложные продукты и даже не сильно при этом страдать, но здесь есть одно большое НО и имя ему Java (либо C#).


    В виртуальную машину Java вложены десятки тысяч человеко-лет, которые делают её лучшей на текущий момент виртуальной машиной в мире. Тулчейн и экосистема джавы развивались годами сразу для “серьезного” языка и тоже множеством людей и компаний, в итоге предоставив огромную и крайне проработанную экосистему (от IDE до стандартов и библиотек), равной которой найти сложно и равной которой экосистема PHP при всех её плюсах не является. На Java пишет намного больше квалифицированных разработчиков, а также намного больше серьёзных энтерпрайз решений, что означает большие рейты, что означает больше квалифицированных разработчиков и тд и тп.


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


    А это означает, что PHP имеет шансы остаться энтерпрайзом второго эшелона, некой “второй Java”. Для меня это вызывает вопрос: зачем в таком случае нужна “вторая” джава, если уже есть первая?


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


    PHP для микросервисов и современных фич


    Оставаясь простым, интерпретируемым и однопоточным, php не то, чтобы успевает за своими более шустрыми и современными конкурентами:


    • PHP быстр, но и golang/nodejs/{any modern lang} далеко не медленнее, а при этом ещё умеют в ассинхронность/многозадачность "из коробки", без внешних расширений языка, велосипедов и воркеров на супервизорах.
    • PHP много чего умеет, но и golang/nodejs/{any modern lang} могут работать через сокеты "из коробки", а вот "слоник" — нет.
    • PHP как бы умеет в функциональщину, но довольно ограниченно, в отличие от современных typescript/scala/kotlin/*.
    • PHP скоро научится в дженерики и аннотации, но эти вещи существуют в той же Java и прочих "современных" языках уже давно, вместе с целым рядом других фич.
    • Ну и уж конечно, в области микросервисов, low latency, выбора и тюнинга сборщиков мусора, замеров аллокаций и прочих элементов разработки действительно высокопроизводительных приложений, php чувствует себя не очень уверенно, будучи изначально не тем (ну не контейнер с nginx, phpfpm и сотней воркеров микросервисом-то называть, в самом-то деле) и не про то.

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


    Это опять возвращает нас к вопросу: а нужен ли сообществу тот, новый PHP? И возможно ли стать новым “крутым” языком с гринтредами, встроенным сервером, монадами и черт знает чем ещё, сохранив свою фирменную нетребовательность?


    Выводы


    Кажется, что PHP пытается усидеть на нескольких стульях сразу: быть и удобным для быстрокодеров на CMS за 10$ в час, и изучаться за две недели вчерашним студентом чтобы завтра же найти работу, и чтобы уважаемые люди серьёзные проекты для других уважаемых и серьезных людей могли делать, и чтобы всё было современно и красиво. Не порвутся ли эти штаны? Не потеряет ли "слоник" старых пользователей, не снискав при этом достаточного внимания новых?
    Непонятно.


    Конечно, даже самый негативный вариант не означает неминуемой гибели: легаси написано уже очень много, а разработчиков, знающих и любящих именно PHP тоже порядочно. Языки программирования способны умирать очень долго и крестражей у них значительно больше семи.
    Но, с другой стороны, ada, smalltalk, delphi и прочие всё же умерли, а тот же ruby, похоже, завис где-то в чистилище, при наличии и множества программистов, и кодовой базы.


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


    Разумеется, даже при самом удачном течении событий, даже успешно совместивший и “старое” и “новое” PHP вряд ли станет языком #1.


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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 63

      +4
      Все же
      — php быстрее java
      — php проще java и позволяет быстрее писать код даже в энтерпрайз, пусть и с оговорками

      позволяет этому языку лидировать в мире бакэнд

      p.s. вы же знаете что такое java, tomcat, сервлеты,… сборщик мусора… чтобы все еще писать на нем?
        0

        Должен отметить, что PHP (с 5.3 вроде) тоже использует сборку мусора.

          0

          C 5.3 его сборщик мусора умеет убирать циклические ссылки.

        +12
        PHP вряд ли станет языком #1.
        А оно зачем надо, быть языком номер 1???
          +15

          Всеобщее признание, деньги, женщины кидают в Вас венки цветов и обсыпают лепестками, восхваляя разработчика на #1 языке.

            0
            Там шутейка

            А ты точно программируешь на PHP?

              +1
              Как по мне, то язык программирования — это в первую очередь инструмент разработки. Не думаю, что есть язык, который превосходен во всем. Это как молоток и пилка. Молотком можно прекрасно забивать гвозди, а вот пилкой нет. А вот пилкой можна спилить дерево, молотком же — нет. Это лично мое мнение
                0
                Так уж повелось, что выбор языка определяет не сама среда разработки а тот набор фреймворков, которые подходят под задачу и главное их своевременная поддержка.

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

                Пример, я сомневаюсь что вы будете писать opencl приложения с использованием php (а ведь такое расширение существует правда без документации и примеров и 8 лет нет развития, точнее есть форки 4-летней давности, т.е. кто то это даже использовал!).
                  0

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

            +8
            Тулчейн и экосистема джавы развивались годами сразу для “серьезного” языка и тоже множеством людей и компаний, в итоге предоставив огромную и крайне проработанную экосистему (от IDE до стандартов и библиотек), равной которой найти сложно и равной которой экосистема PHP при всех её плюсах не является.
            Очень спорное утверждение. При этом никаких подтверждений, ссылок или сравнений. Даже какой бы то ни было методики для сравнения не предложено.
            И здесь же кроется своего рода ловушка, PHP успешно копирует множество удачных решений из Java-мира, увеличивая собственную сложность и строгость. Но сможет ли он побить одного из «королей энтерпрайза» на его собственном поле? Я несколько сомневаюсь.
            А вот вывод на основании того самого неподтвержденного и спорного утверждения. Уж не подмена ли это тезиса?

            PHP быстр, но и golang/nodejs/{any modern lang} далеко не медленнее, а при этом ещё умеют в ассинхронность/многозадачность «из коробки», без внешних расширений языка, велосипедов и воркеров на супервизорах.
            Трэды — www.php.net/manual/ru/book.pthreads.php
            Асинхронность — www.php.net/manual/ru/book.swoole.php
            Асинхронность «из коробки» — amphp.org
            То, что этого нет в составе языка на, мой взгляд, даже плюс — эти задачи нужны не всегда и не всем.

            PHP много чего умеет, но и golang/nodejs/{any modern lang} могут работать через сокеты «из коробки», а вот «слоник» — нет.
            Сокеты — www.php.net/manual/ru/book.sockets.php

            PHP как бы умеет в функиональщину, но довольно ограниченно, в отличие от современных typescript/scala/kotlin/*.
            У языка нет такой цели в принципе.

            PHP скоро научится в дженерики и аннотации, но эти вещи существуют в той же Java и прочих «современных» языках уже давно, вместе с целым рядом других фич.
            А ассемблер уже давно умеет складывать два числа, означает ли это, что Java не сможет с ним в этом конкурировать?

            Ну и уж конечно, в области микросервисов, low latency, выбора и тюнинга сборщиков мусора, замеров аллокаций и прочих элементов разработки действительно высокопроизводительных приложений, php чувствует себя не очень уверенно, будучи изначально не тем (ну не контейнер с nginx, phpfpm и сотней воркеров микросервисом-то называть, в самом-то деле) и не про то.
            Вот именно, изначально такие задачи не ставились перед веб сайтами вообще (в 1995 было сложно представить каким станет веб через 25 лет). Если вы посмотрите ссылки выше, то вероятно, узнаете много нового о том, как это уже работает в современном PHP. Более того, язык релиз за релизом становится только лучше.

            Снова статья, в которой аргументы состоят из демагогии и предположений. Нет ссылок, нет методик, нет сравнения — нет ничего, что можно было бы назвать исследованием. При этом, на основании не подтвержденных предположений делаются выводы о том, что PHP не нужен.
            А это означает, что PHP имеет шансы остаться энтерпрайзом второго эшелона, некой “второй Java”. Для меня это вызывает вопрос: зачем в таком случае нужна “вторая” джава, если уже есть первая?
            Это опять возвращает нас к вопросу: а нужен ли сообществу тот, новый PHP?
            Языки программирования способны умирать очень долго и крестражей у них значительно больше семи.
              +3
              Та ну столько писать человеку (автору), который имеет собственную точку зрения, основанную на его личном опыте, который не коррелирует с большинством всех, кто будет читать эту статью. Всегда будут мода на новые языки, на «энтерпрайзные» языки для «профессссионалов», всегда кто-то будет уходить из какого-то языка из-за того, что он ему не подходит для решения лично его задач, также и будут люди, которые будут слушать/читать мнения других и просто улыбаться, понимая, что язык языком, но бизнесу зачастую плевать на него, бизнес интересует скорость разработки, стоимость разработки и стоимость поддержки кода. Вы все верно сверху написали с технической стороны, я немного дополню со стороны бизнеса: вот в нашей компании мы не будем никогда создавать продукты на Java,C+ и так далее просто потому что это потом выльется в увеличенный бюджет разработки и поддержки, а на php в случае чего я и сам написать на коленке г… код, который будет приводить разработчиков в ужас(не будет, я утрирую), но на 100% будет решит бизнес-задачу и это важнее чем все остальное.

              Просто нужно задуматься над вопросом, а был бы сейчас Фейсбук, если бы его начинали писать на Java(представьте любой). Жалеет ли Цукерберг о выборе языка? Это действительно ли проблема php самая большая для Фейсбука? Выиграет ли стартап от того, что запустит сервис на Go(любой модный) и станет ли бизнес процветать от того, что у сервиса «крутой» язык? А так ругать можно все языки, у всех есть минусы. К примеру, условная Jira (или не условная) отъедает более двух гиг оперативки у сервера, а сайт с немного упрощенным функционалом (грубо говоря просто базовый наиболее используемый функционал) на пап при той же нагрузке будет отъедать 0,5 гига оперативки, кто виноват? Java? Или php? Программисты? Нет — те, кто использует технологии продукты не по назначению и если у языка есть крупная экосистема, которая развивается (а не то что происходит в экосистеме nodejs), значит все же у языка есть задачи, которые он решает лучше всего и их много. А говорить, что неизвестно что-то куда-то идёт потому что мне лично непонятно — это как говорить, а кто покупает такие дешевые или такие дорогие машины.
                +4
                Вы ошибочно посчитали, что главная мысль статьи заключается в том, что «PHP не нужен». При этом даже я сам так не считаю и таких утверждений не писал. Более того, мне нравится и PHP, и то, куда он идет.
                О чём статья писалась, так это о том, что PHP пытается быть «серьезным» языком с ООП, дженериками и прочими штуками, что хорошо для энтерпрайза, но противоречит тому, что и сделало PHP популярным: простоте. Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.

                Детальное же сравнение PHP и Java давайте оставим какой-нибудь отдельной статье, я специально не углублялся в детали, чтобы не раздувать текст техническими подробностями. Да и статья бы тогда называлась «сравнение PHP и Java», больно уж много всего придётся затронуть.
                  –3
                  Если я не понял, то прощу прощения.
                  Это опять возвращает нас к вопросу: а нужен ли сообществу тот, новый PHP?
                  Ярко эмоционально окрашенные фразы вроде этой звучат довольно неоднозначно и очень сбивают с основной мысли статьи в таком случае.

                  Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
                  Опять же звучит крайне голословно. Указание типов, итераторы, генераторы и т.п. совершенно не обязательно использовать. У меня есть проекты, написанные на 5.6, которые отлично себя чувствуют в 7.4. Простого опроса в статье было бы достаточно, чтобы получить обратную связь и подтвердить или опровергнуть гипотезу.

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

                  Фактические ошибки в аргументах против PHP для микросервисов тоже довольно сильно бросаются в глаза.
                    +1

                    Да нормальное ООП, ещё с пятёрки, просто это не значит, что надо все в одном стиле писать.
                    Ну а так, что 10 лет назад, что сейчас, не мешает так же на коленке поднять сервер и начать пилить свой сайтик с знаниями на уровне пару статей почитал, или пол книжки

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

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

                        "Учить фреймворки" лучше сразу, может быть параллельно с развитием навыка "нагуглить вопрос на СО, скопипастить в админку CMS, поиграться пока примерно как нужно не заработает"

                      +2

                      Разрешите вас дополнить!
                      Треды сейчас в экстеншене parallel. Насколько я знаю с pthreads до сих пор всё плохо.
                      Сокеты из коробки — fsockopen и stream_socket_server, расширение sockets всё же не идёт в базовой поставке
                      К асинхронности стоит добавить reactphp, а так же curl_multi и асинхронные драйверы mysql, pgsql.


                      И ещё, в статье не задевается этот вопрос, но в php появился ffi, который закрывает целый ряд вопросов.


                      PS: касаемо асинхронности вынужден признать, что с async/await из коробки было бы намного удобнее.

                      –5
                      Простым быть уже не получится, там Питон крепко укоренился. Опоздали.
                        –5
                        Я не понял, кто минуснул — пхпешники или питонята?
                          +4
                          на мой взгляд, питон соответствует высказыванию «easy to learn, hard to master»
                          +2

                          Вот недавно статью видел, по которой можно прийти к выводу, что php для облачных микросервисов с оплатой по ресурсам хорош. При всей оптимизированности Java (может благодаря ей?) памяти она жрёт как не в себя по дефолту…

                            0
                            Если уж меряться ресурсами, то я бы не останавливался на PHP, а взял бы тот же Golang, который (имхо) будет в целом производительнее и куда экономичнее.
                            А насчёт джавы, то там сразу начинается много вопросов: а как настроили JVM, а какой сборщик мусора взяли и тд и тп. Но да, не спорю, вероятно она будет «есть» больше. С другой стороны, там внутри столько оптимизаций (кстати, стало любопытно и я сходу не смог нагуглить, в PHP есть к примеру векторизация циклов?), то я бы ожидал, что в работе она будет производительнее.
                              0

                              Я больше про целесообразность перехода (полного или частичного) с PHP на что-то ещё. А уж если переходить, то на Java, имхо, проще всего будет, если нравится "ентепрайзная" часть экосистемы PHP.


                              Вопросы я старался убрать заранее оговоркой "по дефолту" — не прокатило :(

                                +2
                                >с PHP на что-то ещё.
                                Ну это от задач зависит, в первую очередь. Вот если вам дадут написать что-то типа IDE — сразу возникает вопрос, а на чем написан PHPStorm? :) А если попросят мобильное приложение — то логичным выбором становится что-то другое. А если компилятор — то третье.

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

                                  Веб-разработка очень широкое понятие очень широкое сейчас, в эпоху когда HTTP lingua franca сервисов и микросервисов на разных ЯП, а очень многие задачи сводятся к, по большому счёту, принять http запрос, чисто преобразовать его в какой-то граф данных, сделать запрос к хранилищу, получить ответ в виде какого-то графа данных, преобразовать в http-ответ и отдать его клиенту.

                                    0
                                    А кто спорит? Несомненно, веба очень много (как самого по себе, так и бэкенда для мобильных приложений). Но другие области разработки тоже имеются, и они тоже сами по себе не мелкие.
                                      0

                                      Вот веб — не ниша PHP, у него там куча конкурентов.

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

                                        Ну и кстати, продвинутые возможности… Возьмем простой случай — подключение к базам данных. Казалось бы, везде есть. Но что в моем понимании энтерпрайз? Это когда к тебе приходят безопасники, и говорят — чтобы через полчаса в лесу было светло, сухо, и медведь (с), в смысле, чтобы завтра все коннекты к ораклу были шифрованные, потому что с завтрашнего дня наш энтерпрайз будет обрабатывать персональные данные… И если некий язык/платформа такого не умеет — они будут в пролете (для таких задач, конечно).
                                          0

                                          За оракл, мс или экзотику не скажу, но для мускуля или постгри под PHP ssl коннекты — вопрос пары-тройки опций обычно в клиентском коде или вообще строке подключения в env переменных или конфиге. Хотя могут быть нюансы, если безопасники хотят странного типа не верифцировать сертификат клиента в принципе. Или если используется минимальная сборка бинарников php — нужно будет добавить ключей компиляции.

                                            0
                                            Ну вот не так все просто. Для некоторых версий оракла в строке эти опции задать нельзя. У jdbc есть отдельное место, где задаются прочие параметры. Ну т.е. я не говорю, что у PHP этого скажем нет (я тут просто не в курсе), я скорее говорю, что вот такая вот «мелочь» может много чего решить в конкретном проекте.
                                              0

                                              Мне это ничего не говорит, но вам, может, скажет: "Это может быть » Easy Connect string, или Connect Name из файла tnsnames.ora, или имя локального экземпляра Oracle." — достаточно?


                                              С другой стороны, слабо представляю как на одном проекте могут встретиться Oracle и PHP

                                                0
                                                Ну, если в проекте нет оракла — на мой взгляд это уже ненастоящий энтерпрайз :) Понятно, что может быть MS SQL, например, ну или даже greenplum, так что это скорее шутка.

                                                Честно говоря, хз. В виде текста это выглядит как-то так:

                                                SQLNET.ENCRYPTION_TYPES_SERVER = (AES256,AES192,AES128)
                                                SQLNET.ENCRYPTION_SERVER = accepted
                                                SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1)
                                                SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

                                                И для каких-то ораклов можно задать прямо в строке подключения, а для старых (типа 11-го) похоже что нельзя.

                                                Я вообще вот совсем недавно с некоторым удивлением узнал, что oracle thin jdbc драйвер умеет прямо вот так:

                                                «jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.us.example.com)(PORT=5561))» +"(CONNECT_DATA=(SERVICE_NAME=itydemo.regress.rdbms.dev.us.example.com)))";

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

                                                  Явно разные у нас понятия об ентерпрайзе :) Есть примеры известных в рунете компаний, которые "почти ентерпрайз", но не дотягивают по организационно-правовым и экономическим показателям, а не признаку использования Оракла? )

                                                    0
                                                    Понятия не имею, если честно. Я практически с 2005 года работаю практически только на банки, и по своему опыту могу сказать, что то что я там видел, выглядело примерно так: Oracle, Sybase+ Sybase IQ, Oracle, DB2, MS SQL, Greenplum, Oracle + MS SQL+ Терадата (примерно в том порядке, что я с ними работал). А все остальное — либо как вспомогательные (типа Hive MetaStore), либо прототипы. Ну т.е. в моем случае можно было найти PostgreSQL в прототипе, и я сам такой делал, но к выходу в пром это все равно был оракл. Почему так? В текущем проекте — потому что у них есть Golden Gate, и достойных альтернтатив ему не то чтобы очень много было видно на горизонте. А вторая причина видимо еще проще — если у вас есть купленные вендорские решения (типа Smartvista), то там у вендора просто написано — мы поддерживаем вот такие СУБД, например. Ну и кто будет рисковать карточными транзакциями, и пытаться ставить неподдерживаемую СУБД?
                                                      0
                                                      То что Golden Gate — в постгресе зовётся pg_logical. Впрочем функциональность наверняка отличается.
                                                        0
                                                        Ну да, по описанию — очень даже похоже. Но по факту, перейти с оракла на postgresql — это будет то еще развлечение для крупного проекта. И дьявол именно в деталях.
                                                          0
                                                          Менять СуБД в любом крупном проекте — всегда ад. Но начать крупный проект вполне можно.
                                                      0
                                                      Ну, можем посмотреть с другой стороны. По вашему, что такое энтерпрайз? По-моему это много разных видов компаний.
                                                        0

                                                        Да, много, но некоторые признаки я бы выделил:


                                                        • жёсткие иерархии подчинения, ответственности и полномочий
                                                        • в целом формализованные процессы
                                                        • в частности бюрократия, планы, отчёты, бюджетирование
                                                          0
                                                          Ну, да. Где-то имеет место. Но я бы сказал, что мне это никогда не мешало. Они уж не настолько жесткие и формализованные, если у компании есть хоть какие-то реальные цели, типа зарабатывания денег, и если ты этих целей реально достигаешь.
                                                            0

                                                            Тут больше не про мешание я, наверное, а про минимальное влияние на продукты компании на рядовых позициях, даже на чисто технические вопросы типа обновление зависимости :)

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

                                                                Насчёт корпоративного хранилища спорно, имхо, ноя про то, что чтобы обновить зависимость с, условно, 7.3.7 на 7.3.9 нужно получить апрув от лида (ведущего инженера, простите), на 7.4.0 от от начальника депратамента, а на 8.0.0 от совета директоров.

                                                                  0
                                                                  >спорно, имхо
                                                                  В интранете, где другого хранилища вообще нет? Не, ну вы можете конечно собрать из артефактов, коорые прислали себе по почте. В процессе разработки. Но идти с таким в пром, ну такое себе решение.

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

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

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

                                                                      Ну и кто вам во внешнем хранилище гарантирует повторяемость сборки? В своем мы заведомо можем запретить менять релизные версии, и это хорошая практика. А поднять условный nexus — это вообще дело 30 минут.
                                                                        0

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

                                            0
                                            Вот веб — не ниша PHP, у него там куча конкурентов
                                            Если бы в PHP добавили строгую типизацию, то конкурентов бы не было.
                                              0

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

                                  0
                                  Ну как бы, если памяти у вас мало (а это скажем что-то embedded), то тем не менее существовала когда-то JavaME, которая работала на телефонах. И существует Андроид, где она тоже работает (не совсем такая же, но это уже не так важно). Т.е. эта проблема — она в принципе решаема, GC можно вообще убрать практически до нуля, как и аллокацию (правда, придется попотеть и подумать головой).

                                  А если памяти у вас много, ну скажем как в моей области больших данных, где 256 гигабайт доступно на узел кластера практически везде, включая кластер разработки — то во многих случаях память и не нужно зря экономить — потому что простое кеширование того, что можно закешировать — это зачастую самый простой и дешевый способ оптимизировать время выполнения. Это не значит, что ее вообще не нужно экономить — это значит, что ее не нужно напрасно экономить, т.е. потратить лишние сотню гигабайт чтобы сократить время обработки с часа до 15 минут — часто это более чем разумный компромисс.
                                  –5
                                  Ruby не в чистилище завис, вышла версия 3.0, которая на фоне PHP 8.0 смотрится великолепно, а на фоне Ruby 3.0, версия PHP 8.0 смотрится как застрявшая в чистилище :)
                                  Я считаю, что PHP либо необходимо не добавлять фичи, а полностью переработать язык, кардинально, не таща всё и ото всюду, либо не тащить всё и ото всюду, а добавлять только необходимые фичи, а не «приколюхи», в ином случае энтерпрайз в конце концов откажется от PHP в пользу альтернатив
                                    +1

                                    Возможность патчинга удалили?

                                    +3
                                    Думаю, PHP отлично сохранится как удачное средство прототипирования и быстрой разработки на стыке бэка и фронта. Эдакий веб-питон :)

                                    Новые фичи 8-ки — это, скорее, возможности, чем обязаловка. К примеру, есть множество успешных проектов на PHP, вообще не использующих объектную парадигму, и написанных в стлие «пиэчпизма» образца 2000 года.
                                      +1

                                      быстрокодеров — норм так завуалировали

                                        +5
                                        В последнее время все чаще на слуху что люди уходят с PHP на Go. Но с чего бы?
                                        На гошке очень тяжело писать декларативно-понятный с первого взгляда код (одни проверки ошибок на каждый чих чего стоят). Неудобно сегрегировать бизнес-логику. Сложно проектировать по DDD (если вообще уместно). Он быстрый, современный, но скриптовый) В самый раз для микросервисов.

                                        PHP все больше становится похож на Java, что делает его очень неплохим языком для написания сложных архитектур на бэке. Плюс он определенно «линдиустойчивый» (Н.Талеб «Шкура на кону»). Можно с высокой вероятностью сказать, что проживет еще столько же.

                                        Оба языка стремительно развивиются и у каждого есть свои плюсы и минусы. Мое мнение — не будет монополиста. Думаю они оба займут свои ниши.
                                          +1
                                          зачем в таком случае нужна “вторая” джава, если уже есть первая?
                                          Вы ответили это в самом начале — очень легко найти сотрудника, и за очень дешево. Корпорации тоже любят считать деньги, и они с радостью возьмут разработчика PHP, если он будет способен сделать тоже самое, что и Java-разработчик, но за меньшие деньги.

                                          Далее, про скорость разработки. Чаще всего она выше у PHP, а это значит, корпорации затратят ещё меньше ресурсов на получение результата. Цифр у меня нет, поэтому пусть это останется лишь моим наблюдением.

                                          Касательно энтерпрайзного Java — да, она сейчас #1, и будет в топе ещё долго. И php совсем не скоро даже догонит его. Но причина почему — так и не была озвучена. А она проста — Легаси. Уже написано слишком много софта на Java, который нужно дальше поддерживать и развивать. И эти системы чертовски сложные и запутанные. Добавляем к этому изначальную сложность Java (по сравнению с PHP), и получаем дорогого разработчика, который готов разбираться во всём этом, потому-что ему платят достаточно для копания.

                                          Вторая причина, почему Java чаще выбирают в мире энтерпрайз — опять же поставщики софта и оборудования (ibm, привет!) часто присылают примеры кода и пакеты для интеграций только на Java/Net, и не готовы что-то там докодить на PHP, и по сути не заявляют о поддержках PHP для интеграций. А так-как поставщики не разрешают (не суппортят) интегрироваться на других языках — то ИТ-директор выбирает то, что поставщик точно будет суппортить. Вот и всё, круг замкнулся.

                                          При этом, как было верно отмечено, сейчас Java умеет слишком многое, до чего PHP либо никогда не дотянется (железо), либо придет не скоро. Но когда нужно сделать что-то не слишком сложное — PHP очень даже годится, и вырывает свой сегмент своими зубами хоботом.
                                            +1
                                            Можете ругать сколько угодно PHP. И не важно на каком он месте.
                                            Я благодарен этому языку, так как он 10 лет был основным инструментом и был моим «кормильцем».
                                              +4
                                              в погоне за тем, чтобы стать «правильным», PHP легко может потерять свою простоту и скорость разработки
                                              Пока что это утверждение спорное. «Наколенный» код, который я писал лет 20 назад для пет-проектов во времена PHP 4, до сих пор без проблем крутится теперь уже на PHP 8 без существенных переделок (не считая разве что миграции с расширения mysql на PDO примерно во время выхода PHP 5.4, ну и мелкие правки вроде неправильного порядка аргументов в implode, который раньше разрешал менять их местами). Так что теперь есть два способа писать на PHP — быстро но костыльно и медленно но качественно. Новые фичи не ломают старые, а признанные устаревшими убираются не сразу, а сперва на пару мажорных версий помечаются, как устаревшие, давая разработчикам несколько лет на то, чтобы отловить в логах предупреждения и пофиксить.
                                                0
                                                Вопрос по КДПВ. Зачем указывать @var boolean перед константой?
                                                  0

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

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

                                                    Вы про какой, Python? JavaScript (за вычетом TypeScript)?

                                                      0
                                                      Python, JavaScript уже не так активно растет

                                                  Only users with full accounts can post comments. Log in, please.