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

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

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

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

Программа на golang

func main() {
	// var data []byte
	// var err error
	data, err := os.ReadFile("test.json")
	if err != nil {
		log.Fatalln("Error reading file ", err)
		return
	}
	start := makeTimestamp()

	wg := &sync.WaitGroup{}
	for i := 0; i < 1000000000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			var test *Test
			err = json.Unmarshal(data, &test)

			if err != nil {
				fmt.Println("Error reading file ", err)
				return
			}
		}()
	}

	wg.Wait()
	end := makeTimestamp()

	fmt.Printf("%.3fms \n", (end-start)/1e9)
}

Программа на PHP

<?php

$start = microtime(true);

\Swoole\Coroutine\run(function () {
    $cnt = 1_000_000_000;

    $wg = new \Swoole\Coroutine\WaitGroup();

    $fp = fopen(__DIR__ . '/test.json', 'rb');
    if ($fp === false) {
        echo 'Error' . PHP_EOL;
        return;
    }

    defer(function() use($fp) {
        fclose($fp);
    });

    $result = '';
    while ($line = fread($fp, 1024)) {
        $result .= $line;
    }

    for ($i = 0; $i < $cnt; $i++) {
        $wg->add();
        \Swoole\Coroutine::create(function () use ($wg, $i, $result) {
            $decoded = json_decode($result);
            unset($decoded);

            $wg->done();
        });
    }
    $wg->wait();
});

$end = microtime(true);

file_put_contents('php://stdout', sprintf("%.3fms \n", ($end - $start)));

В результате выполнения этих команд получил:

Golang скомпилированный под локальную машину выполнял команду — 452.430ms

PHP в docker‑образе выполнял команду — 390.859ms

Согласен, что этот пример не доказывает, что PHP быстрее чем Golang, но при этом, он развеивает миф, что golang однозначно лучше PHP.

Также провел замеры при работе http сервера и PHP показал себя с хорошей стороны, в docker‑образе, с подключением к базе данных, вставкой строки в базу и последующим селектом данных и базы и передачей json ответа http сервер на php выдержал 10.000 rps, со средним временем ответа 40мс, максимальным 500мс и минимальным 200 микросекунд, но об этом более детально напишу в следующих статьях.

Какая конечная цель будущего цикла статей:

  • Показать, что PHP хороший язык программирования, на котором можно делать web-проекты

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

  • Создать тестовое приложение, на котором можно будет посмотреть на один из вариантов организации работы в команде, чтобы каждому участнику команды (а для меня это: backend-разработчик, frontend-разработчик, devops-инженер, qa-инженер, бизнес/системный-аналитик и product-owner/manager, архитектор)

  • Показать пример unit-экономики, разделения продуктовых фич, расчета стоимости разработки и содержания проекта на разных языках программирования. (Опираться буду на PHP и Golang)

Следующая статья — какие варианты PHP‑сервера существуют, что нужно о них знать разработчику.

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

Комментарии (422)


  1. gro
    21.07.2024 19:00
    +76

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


    1. xenon
      21.07.2024 19:00
      +19

      Моя теория умирания языков программирования - у языков программирования может быть очень сильная инерция. Главное, что надо понимать - хорошесть/плохость языков - штука условная и почти всегда любой "плохой" язык тоже вполне сносен.

      Если язык "взлетел", оброс большим количеством проектов, в том числе коммерческих, умирать он будет долго, медленно. Даже если мы представим, что вдруг внезапно всем очевидно, что (неважно, но для примера, допустим) Golang 100% лучше, чем PHP, все равно, PHP может умирать еще десятилетия!

      Если в бизнесе уже есть приложение на умирающем языке, никто в здравом уме не будет его переписывать просто потому, что язык уже не моден. Работает - и хорошо! Соответственно, есть спрос на программистов, работающих на этом языке (кто-то же должен обслуживать и развивать это ПО). Более того, этот похапешный отдел скорее всего и новые проекты будет на похапе делать (потому что мозгу так проще, иметь в голове одну модель языка, а не переключаться). Можно даже в каком-то смысле воспринимать ЯП как вирус - если контора заболела каким-то "плохим" языком программирования в детстве - есть риск, что она будет так болеть вечно. И еще может быть в ходе агонии породит новые проекты на этом "условно умирающем" языке, в том числе и более-менее успешные.

      Помните, такой язык как Perl? Если про PHP можно спорить про его умирание, то Perl, наверное, более мертв (чем PHP)? Однако, до сих пор SpamAssassin на множестве почтовых серверов в мире - на перле. И инсталляшки дебиана его, вроде используют. И чтобы с ними как-то что-то делать - востребованы программисты на Perl. Инерция.


      1. CherryPah
        21.07.2024 19:00

        Perl с сетью хорошо работает. хBSD во многом жива по тем же причинам.


        1. RighteousHippie
          21.07.2024 19:00
          +6

          буквально вчера на одном сайте видел в адресной строке что-то типа /cgi-bin/stat.pl?ses=111&uu=222&pp=333

          Так что даже web приложения на perl где-то ещё работают


          1. WST
            21.07.2024 19:00
            +16

            Вовсе не факт. Иногда старые URL-ки просто сохраняют для совместимости (чтобы работали старые ссылки), а на деле под капотом может быть PHP или Python + Django или что угодно ещё, ведь маршрутизацию URL можно как угодно настроить.

            Мы с друзьями делали URL-ки, заканчивающиеся на *.jsp, и ещё в заголовках отдавали «X-Powered-By: Apache Tomcat» вообще чисто забавы ради, т.к это был бэкенд.


            1. printf
              21.07.2024 19:00
              +2

              О да, я хулиганства ради на Node.js делал урлы, заканчивающиеся на .php.


            1. ef_end_y
              21.07.2024 19:00

              Факт - uu pp и ses это штаны от моего проекта, которому 15 лет минимум (лом смотреть сколько) - и им пользуются провайдеры


      1. senfiaj
        21.07.2024 19:00

        Да, и половина экономики США держится на COBOL.



        1. sdramare
          21.07.2024 19:00
          +1

          А вторая на excel


          1. senfiaj
            21.07.2024 19:00

            Моя любимая БД =)


      1. rg_software
        21.07.2024 19:00

        Буквально вчера понадобилось обрезать PDF от пустых полей по краям. Подходящий инструмент оказался уже на компьютере: pdfcrop из поставки LaTeX, тоже написан на Perl.


  1. Cere8ellum
    21.07.2024 19:00
    +32

    Люблю php. Начинал с него. Он ни беден, ни велИк, он - самодостаточен, красив и мудр. И его не победить,...наверно :).


    1. OlegMax
      21.07.2024 19:00
      +4

      Про PHP я могу сказать только одно... но пятью разными способами


      1. NickyX3
        21.07.2024 19:00
        +3

        Это про Perl, там способов будет 10, 5 из которых вообще даже автор не прочитает через месяц


  1. Revertis
    21.07.2024 19:00
    +17

    Но ведь PHP создан, чтобы умирать. А среди меня PHP давно заменён на Rust. Всё, что я когда-то скриптовал на PHP, теперь делаю на Расте.


    1. TTkachev
      21.07.2024 19:00
      +6

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


      1. MadL1me
        21.07.2024 19:00
        +19

        Rust один из лучших языков для бекенда

        Серьезно?) Один из лучших языков для того чтобы шиппить в прод в 20 раз медленнее чем на любом другом япе


        1. Revertis
          21.07.2024 19:00
          +7

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


        1. Gorthauer87
          21.07.2024 19:00
          +6

          А что там не так с шиппингом? С помощью sccache полная сборка среднего проекта будет длиться минут 5-7 на ci.

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

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

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


      1. kenoma
        21.07.2024 19:00
        +3

        Что угодно, лишь бы не осваивать дотнет, ага.


        1. 40kTons
          21.07.2024 19:00

          То чувство, когда с .NET переходишь на Go


          1. sdramare
            21.07.2024 19:00
            +1

            А чем продиктовано такое решение?


            1. 40kTons
              21.07.2024 19:00

              Причины лежат скорее в области ощущений, чем логики

              1. win 10 для меня последняя версия винды, которую я ставил себе на домашний комп. Был и есть ноут с линуксом, но через 3-5 лет и домашний десктоп перекочует на линукс. Просто потому что win 11 не нравится, а у 10ки поддержка рано или поздно будет становиться плачевной. Да и в целом дистанцируюсь от мелкомягких. А .NET и линукс не до конца дружат - gui уже сколько лет не могут завести например.

              2. В целом, сама ситуация с языком - область задач, для которых используют go в коммерческой разработке, наиболее пересекается с областью задач, которые мне было бы интересно решать (эффективные сетевые приложения). Мало легаси - язык то молодой. Востребованность go программистов. Просто нравится результат работы компиляции в виде одного простого бинарника без всякой лабуды


              1. mayorovp
                21.07.2024 19:00
                +1

                На самом деле легаси в go больше чем должно было бы быть. Скажем, api модуля os было стянуто с Питона, где оно на тот момент уже было странным.


              1. kenoma
                21.07.2024 19:00

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

                Про кроссплатформенность это несерьезно начиная с появления .Net Core.
                Для UI есть Avalonia которая хороша чуть более чем полностью, это если про десктопы говорить. Про веб я вообще молчу, упомяну только что есть офигенный Blazor.
                Cовершенно непонятно, чем шарпы неэффективны в "сетевых" приложениях, может речь идет о физических уровнях OSI? Ну и про легаси это веселый пассаж.


              1. Free_ze
                21.07.2024 19:00
                +2

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

                Дотнет умеет в собираться в натив и бандлиться в один файл.