Последние несколько лет на рынке, по моему сугубо личному мнению, 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-сервера существуют, что нужно о них знать разработчику.
Стати планирую публиковать по воскресеньям. От Вас, уважаемые читатели Хабра, было бы здорово получить обратную связь, интересно ли вам это направление, в комментариях.
Комментарии (79)
Cere8ellum
21.07.2024 19:00+15Люблю php. Начинал с него. Он ни беден, ни велИк, он - самодостаточен, красив и мудр. И его не победить,...наверно :).
Revertis
21.07.2024 19:00+8Но ведь PHP создан, чтобы умирать. А среди меня PHP давно заменён на Rust. Всё, что я когда-то скриптовал на PHP, теперь делаю на Расте.
TTkachev
21.07.2024 19:00+3Пошел тем же путем. Искренне убежден, что Rust один из лучших языков для бекенда. Но первый опыт бекенда лучше получить на ООП языке. И PHP прекрасно для этого подходит.
MadL1me
21.07.2024 19:00+6Rust один из лучших языков для бекенда
Серьезно?) Один из лучших языков для того чтобы шиппить в прод в 20 раз медленнее чем на любом другом япе
Revertis
21.07.2024 19:00При наличии опыта разработка на Расте не медленнее, чем на других языках. Я тоже заблуждался как вы когда-то.
Gorthauer87
21.07.2024 19:00А что там не так с шиппингом? С помощью sccache полная сборка среднего проекта будет длиться минут 5-7 на ci.
Абстракции там хорошие, тулзы удобные, поддержка со стороны ide хорошая. Библиотеки вполне себе есть в наличии.
Защита от дурака сильная. Какие вообще могут быть сложности в типовом проекте? Не типовой же в принципе нельзя быстро шиппить, да и не получится при всем желании.
Больно может стать если вот вдруг задача на сложные графы с циклами, но это не типовая задача.
MzMz
21.07.2024 19:00+2Golang скомпилированный под локальную машину выполнял команду - 452.430ms
PHP в docker-образе выполнял команду - 390.859msодин вызов я так понимаю? то есть заодно померяли инициализацию виртуальной машины тоже?
> Так же провел замеры при работе http сервера и PHP показал себя с хорошей стороны, в docker-образе, с подключением к базе данных, вставкой строки в базу и последующим селектом данных и базы и передачей json ответа http сервер на php выдержал 10.000 rps, со средним временем ответа 40мс, максимальным 500мс и минимальным 200 микросекунд, но об этом более детально напишу в следующих статьях.
Так а что тут мерялось? Подключение к БД и вставку строки?
koksharov Автор
21.07.2024 19:00Это просто пример, в котором PHP обогнал golang. В реальной жизни совершенно другие задачи. Замеры были только выполнения кода по десериализации json, не более того.
На счет http-сервера - это спойлер к будущей статье, в которой уже более детально об этом расскажу
tuxi
21.07.2024 19:0010000 rps 40мс со вставкой в бд и чтением на коленке? А чем нагружали?
Что-то тут нечисто. 10т реквестов на одной машине уже нетривиально сгенерить. Хочется посмотреть как это делалось.
koksharov Автор
21.07.2024 19:00+1k6 использовал для нагрузки
база postgresql, для подключения использовал пул соединений
tuxi
21.07.2024 19:00На одной и той же машине?
koksharov Автор
21.07.2024 19:00+1да, все в docker
tuxi
21.07.2024 19:00И операционной системе хватило сокетов?
koksharov Автор
21.07.2024 19:00+1да, за счет того, что ответы были быстрые и не было лага по ответу, за пределы соединений на одной машине не уходило, поэтому сокетов хватило.
Если вопрос к http2, что количество сокетов было снижено, то - нет, запросы были http первой версии
DashBerlin
21.07.2024 19:00+6помню и node.js тоже был с такими же амбициями, так что и go переживет )
Последние несколько лет на рынке, по моему сугубо личному мнению, golang вытесняет PHP с рынка, а многие компании считают, что проекты, которые сейчас написаны и работают на PHP должны быть переписаны на golang, чтобы было хорошо.
ничего глупее не встречал, те из одного болота нырнуть, в другой, вопрос, а зачем?
был случай, когда я проходил собеседование в одну из компаний экосистемы Сбера, прошел все мыслимые и немыслимые собеседования со специалистами и менеджерами проекта, на этапе подготовки офера, заявляют, якобы пых не входит в список доверенных ЯП по версии службы безопасности, мол надо будет перевести проект на js и чуть ли не за месяц. Я немного охренел, говорю, если такая позиция у СБ, давайте тогда на шапры переведем, это будет более грамотная миграция, в общем офер не получил. Через неделю получил офер в другую компанию из той же экосистемы, где пых был в почете :)
Последние несколько лет на рынке, по моему сугубо личному мнению, golang вытесняет PHP
Здесь не согласен, просто, подавшись хайпу, народ то на node.js, то на go, то на битрикс делает, потом волна спадает, приходится искать специалистов для поддержки проекта, а мигрировать на новый стек, это очень дорого. Поэтому компании едят кактус и плачу, но продолжают есть.
posledam
21.07.2024 19:00+2Вы так говорите, как будто компании это некие инопланетные организмы, которые принимают неправильные решения :) Это ведь те же самые люди, как мы, разработчики, программисты, которые принимают какие-то стратегические решения, которые сверху очень сложно валидировать без глубоких инженерных познаний и опыта. Поэтому всё зависит от того, адепты какой платформы сидят у руля. И всегда и везде будет тот самый фатальный недостаток.
Другими словами, дело в людях, а не технологиях. Если в компанию придёт команда со знанием стека руби, и при этом заимеет внутри-политически сильные позиции, значит в компании будет основным ЯП Руби, и совершенно плевать, насколько он подходит и выгоден ли для решаемых задач. Главное, что команда его знает, и не знает ничего другого. Значит будет Руби, а не Go или PHP. Даже если придётся городить костыли.
Смена технологий меняется с переосмыслением технологий у людей.
Ivan22
21.07.2024 19:00у людей переосмысление тоже не особо происходит, смена технологий происходит скорее со сменой людей
DashBerlin
21.07.2024 19:00Мы примерно об одном говорим, но, но есть нюансы. Компания это не всегда технически подкованные люди, им все равно на чем написано, чистый там или грязный код, им нужен продукт, причем вчера И тут попадается некий разработчик, более голосистый, более убедительный, кстати про это были статьи на хабре. Он убеждает, что надо сделать, условно на чем-то, что по его словам эта технология, за которым будущее и все крупные вендоры перешил на него. Проект запущен, разработчик уходит и тут возникает вопрос, а как его поддерживать и развивать? Наступает момент истины, надо кого-то искать, hh начинает пестрить вакансиями, а переехать куда-то это очень накладно и болезненно для компании.
GoodGod
21.07.2024 19:00Для сравнения Golang и PHP вы взяли дополнительное расширение для PHP - Swoole.
Подскажите, это расширение 100% совместимо с популярными PHP фреймворками, на которых пишут современные веб приложения - Symfony (особенно интересно, т.к. люблю этот фреймворк), Laravel, Yii. Имеется ввиду, что приходится расширять код фреймворков, где расширение кода не предусмотрено, или перегружать функции из стандартной библиотеки PHP, т.е. "черные" хаки.
Спасибо.
koksharov Автор
21.07.2024 19:00+1Да, для ускорения использовался Swoole, он работает на основе event-loop (очень похоже на nodeJS), за счет этого получилось быстро выполнить программу.
Полная документация по swoole есть на их официальном сайте https://wiki.swoole.com, также есть большое количество composer-пакетов, которые позволяют подключить этот модуль к проекту.
Важный момент, простое подключение swoole в рабочий проект будет равносильно использованию php-fpm или apache или другим web-серверам.
Более подробно как можно писать код, какие есть нюансы, за счет чего можно показать высокую производительность, как интегрировать это в существующий проект и хочу написать в следующих статьях. Планов много, этой статьей хочу узнать у людей, интересно ли это или нет
DashBerlin
21.07.2024 19:00+4Это еще та китайская суходр..ка. Был проект, наелся, была версия, где даже xdebug нельзя было прикртить. Изначально пых был сделан для другого, нужна асинхронщина, почему не использовать другие технологии, заточенные под это?
DimoniXo
21.07.2024 19:00+14Помню как здесь, лет 10 назад был хайп вокруг Ruby, который вот-вот убъёт php. Как дела?
Alexsey
21.07.2024 19:00+1Нашел свою нишу и вполне себе живет до сих пор - на нем написаны GitHub, GitLab, Shopify, Stripe.
xenon
21.07.2024 19:00+2Это - ниша? Вот, например, как я понимаю сравнение python и golang: на Python проще, легче, быстрее и дешевле сделать почти все. И модернизировать - тоже проще. Но жрать ресурсов будет больше и работать медленнее. Соответственно, любой новый проект лучше делать на пайтоне, а дальше по ситуации - если мы готовы почти "заморозить" функционал, но хотим снизить расходы на железо - то переписываем узкие места на golang. Ниша пайтона - быстрая разработка, ниша golang - высокая производительность и параллельность. Их нельзя поменять местами, их ниши - объективны.
А в случае перечисленных выше проектов, я не вижу, чем они особенны, почему там уместнее руби, чем тот же пайтон? Это не ниша, а исторические причины - первый программист в компании на момент создания проекта предпочел Ruby. Выбор во многом эстетический и субъективный.
FanatPHP
21.07.2024 19:00+15Для всех тех, кто пришел сюда прочитав заголовок, но не читая статью. Пых давно убит морально. Статьи про fractal of bad design и картинки с молотком из двух гвоздодёров сделали своё дело. Он не существует в информационном поле. А точнее существует в виде "какой-то старпёрский язык для говнокода". На Stack Overflow даже индусы сейчас не задают вопросов по пхп, передав эту пальму синьор-девелоперам из Центрально-Африканской республики. Да, сейчас он не имеет ничего общего с тем языком, про который писались ругательные статьи. Да, он все так же является основным языком бэкенд разработки веб-приложений. Но информационную войну он проиграл давно и прочно, и это со временем скажется и на его использовании.
Alexsey
21.07.2024 19:00+4Да, он все так же является основным языком бэкенд разработки веб-приложений.
Сомнительное утверждение. В бэке, в плане старта каких-то новых проектов, его уже давно подвинула компания состоящая из nodejs, .net, java, python. Разумеется я сейчас говорю про глобальный рынок и про какие-то custom решения, а не поднятие интернет магазина методом накидывания плагинов на wordpress.
PHP будет жить еще долго, но жить он будет, в основном, за счет легаси, и не в последнюю очередь легаси для широкой публики - джумлы, вордпрессы, вот это вот все.
Crimento
21.07.2024 19:00Адепты Laravel с вами не согласятся
Но да, публичности бы им явно побольшеFanatPHP
21.07.2024 19:00+1Речь, разумеется, не про адептов, а про остальной мир. В /r/php регулярно, раз в месяц, появляются посты "ой, я весь колледж слышал со всех сторон, что пхп - это параша, а сейчас пишу и нормальный язык". Есть в мире такая штука, как клише. Например, что Раша - это медведи и балалайки. И ты хоть усрись доказывая, что в Канаде медведей на бэкъярдах на порядки больше, но уже сложившуюся картинку не перешибёшь.
falconandy
21.07.2024 19:00Golang скомпилированный под локальную машину
Операционка то какая? Тестируйте в одинаковом окружении.
Gorthauer87
21.07.2024 19:00+4Вроде же PHP всегда славился низким порогом входа, а тут в примере создаётся асинхронный event loop, который вот совсем не простой для понимания.
То есть, мы фактически из php сделали go. Ну, наверное, это хорошо. Но вот это усложняет понимание и увеличивает шансы выстрела в ногу.
Go то хотя и простой язык, но ошибаться на нём тоже довольно просто.
posledam
21.07.2024 19:00+6Но ведь Swoole написан на Go... А если я PHP скомпилирую под .NET (PeachPie), сравнение будет валидным?
Вообще "сравнение" максимально нелепое, сравнивать надо в тех кейсах, которые имеют какой-то практический смысл. А именно, производительность приложения, надёжность, отказоустойчивость, стабильность, качество и скорость разработки, не требовательность к ресурсам, независимость от других инструментов. PHP не помрёт ещё много лет, но проблемы у него имеются. Отрицать это, значит не заниматься развитием языка, и тем больше с него уйдёт разработчиков. Надо признавать факты и работать над улучшением, может даже изменить слегка парадигму под современные условия и требования. А не ходить и прикалываться "опять хоронят". Эти звоночки не с потолка берутся.
GoodGod
21.07.2024 19:00Статья про то, что - все проблемы PHP можно победить - имея хороший инструмент (стек) и код. Но например у меня опыта в стеке, который победит все проблемы PHP - нету.
posledam
21.07.2024 19:00+1Не очень понятно, зачем что-то побеждать, если можно взять другой стек, где не надо бороться, превозмогать, чтобы побеждать. А опыт нарабатывается, нужно просто уметь выходить из зоны комфорта, использовать подходящие для своих задач инструменты, пробовать, учиться. Материалов в интернете вагон.
GoodGod
21.07.2024 19:00Да, согласен надо искать инструменты, которые дают серьезные преимущества, т.е. прорывные инструменты, а не побеждать проблемы.
Статья - инфоповод. Попытка что-то "пережевачить" (от слова жевачка для мозгов) идею - мысль, посмотреть ее с разных сторон еще раз что-то обсудить. Если бы на хабре не минусили, тут были бы такие интересные дискуссии в комментариях.
koksharov Автор
21.07.2024 19:00+2Swoole не написан на go, возможно вы сравниваете с roadrunner
https://github.com/swoole/swoole-src - ссылка на модуль
posledam
21.07.2024 19:00+6Да-да, перепутал с RR. Но тут C++, тоже по сути ни разу не PHP.
Получается, что код на Go полностью самодостаточен, он компилится и работает, ничего не требует для своей работы (кроме непосредственно ОС). А тут надо ещё прикорячить Swoole/RR/php-fpm+Nginx, которые писаны совершенно на других ЯП. И зачем такие сложности? Тут собственно и ответ, почему Go.
А по тестам. Давайте подадим нагрузку 1000 запросов в одно время на PHP и Go с обращениями в БД, посмотрим что получится? Какой будет профиль утилизации, сколько запросов вообще не отработает или отвалится?
tuxi
21.07.2024 19:00+1а еще у go есть https://github.com/valyala/fasthttp
Я понимаю, докеры и все такое. Но бинарник на go это и вебсервер сразу.
santanico
21.07.2024 19:00+3Если вопрос нужны ли такие статьи, то ответ «да» возможен при одном условии. Надо разобраться и рассказать почему такие «неожиданные» результаты.
Можно конечно просто вкинуть как есть, но если в комменты придет профи, то будет неприятно)
Dmitri-D
21.07.2024 19:00+5это неадекватный тест и сравнение совершенно разных ситуаций с т.з. процессора, отсюда и слоновый проигрыш go. Напишите асинхронно с пулом и go сделает php на пару порядков.
gudron
21.07.2024 19:00+5выскажу непопулярное мнение, но го победил простотой. пока весь мир упарывался сложными конструкциями ооп, награмождением других сущностей поверх классического ооп... вызовом на все это стал простой и немногословный в плане словаря язык...
я когда щас смотрю на php код - диву даюсь от сложности ... классы, наследование, абстрактные клаcсы, трейты, статические методы, статические поля, магические методы, магические поля, анонимные классы, методы классов под флагом final, магия вокруг клонирования объекта, ... все это безусловно продиктовано потребностями реального мира. Но в довесок приходят фреймворки без которых никуда в мире php...и они приносят еще несколько слоев сложности...как на уровне архитектуры так и на уровне оберток к стандартным функциям php...
ну и не забудем, что правила хорошего тона велят нам используя фреймворк - городить все по паттернам проектирования...больше абстрактых сущностей богу сущностей...
ушел из php уже лет как 10...даже не представляю какой кошмар сейчас представляет из себя собеседования на вакансию php-разработчика..
user87644
21.07.2024 19:00+5Таки паттерны проектирования это благо, бери любой проект на spring, angular, symfony, nestjs, и уже сразу примерно знаешь, где что лежит. А вот разобраться в рандомном проекте без фреймворка, легко можно убить неделю другую просто распутывая чью-то лапшу
FilIvanov
21.07.2024 19:00А вот разобраться в рандомном проекте без фреймворка, легко можно убить неделю другую просто распутывая чью-то лапшу
Вам хочется в это верить, ибо это "правильная" точка зрения, академическая. Но даже самописы бывают изумительны в архитектурном плане и просты в плане поддержки. Фреймворки не гарантируют отсутствие говнокода, но добавляют сложность, зависимости от внешних вендоров и усложняют код, если нужно выйти за рамки типовых решений.
user87644
21.07.2024 19:00+4Изумительный самопис это большая редкость, не все могут в архитектуру. Ну и паттерны не зря так называются, нет никакого смысла каждый раз по разному писать решение одной и той же задачи, это скорее минус. Даже если вы один на проекте, для внесения правок каждый раз нужно вспоминать, что именно там за велосипед. Коллега тем более спасибо не скажет. По поводу сложности, паттерны это "сложность" только в первый раз. Ну и фреймворк это конечно не гарантия отсутствия говнокода, но отсутствие фреймворка это значит 100% велосипед, легаси в плохом смысле.
artptr86
21.07.2024 19:00+4Если это будет архитектурно изумительный самопис, то что-то мне подсказывает, что большинство архитектурных решений в нём будет аналогично популярным фреймворкам, а потому знающий такие фреймворки разработчик легко разберётся и в самописе.
FilIvanov
21.07.2024 19:00+1ушел из php уже лет как 10...даже не представляю какой кошмар сейчас представляет из себя собеседования на вакансию php-разработчика..
Я не ушёл из php 10 лет назад и да - Вы правы, там кошмар:
В требованиях (99% встречающихся вакансий) могут присутствовать как минимум 3 ведущих фреймворка. И если ты не изучал их все (в свободное время), на тебя смотрят как на какого-то неправильного php-программиста.
Если ты работал с Laravel, но не работал с Symfony- тебя не возьмут на работу.
Если ты работал с Larvael 7, но не работал с Laravel 9 - тебя не возьмут на работу.
Могут легко задать вопросы по внутренней архитектуре фреймворка и собеседующие искренне не понимают, почему я использую фреймворк чисто "по документации", как клиент, и почему я, как программист, не горю желанием разбираться в кишках его архитектуры.
Но в довесок приходят фреймворки без которых никуда в мире php...и они приносят еще несколько слоев сложности...
Совершенно верно.
Вообще, PHP хороший язык, но графоманы-фрейморкоклепатели очень, очень сильно усложнили жизнь программистам на этом языке, ибо теперь знаний одного языка недостаточно. Все эти фреймворки нужно изучать, но по сути это всё не стандарт, а филькина грамота, которая сегодня популярна/востребована, а завтра - нет. И тратить время на изучение фреймворка просто из принципа не хочется.
FanatPHP
21.07.2024 19:00+1графоманы-фрейморкоклепатели очень, очень сильно усложнили жизнь программистам
Очень, очень неортодоксальная точка зрения.
petejones83
21.07.2024 19:00Это, скорее, проблемы собеседований. Меня однажды на собеседовании про джаву спросили вопрос о том, как себя ведет такой-то код на экзотичной легаси-архитектуре (какой-то HP пятнадцатилетней давности).
a-tk
21.07.2024 19:00Это глобальный тренд, справедливый для практически всех языков. И, что характерно, в вакансиях чаще именно фреймворки указываются.
fo_otman
21.07.2024 19:00+17 лет опыта на PHP, этим летом уволился, искал работу. 30+ собеседований, всего 2 оффера. Еще штук 20 компаний отказали сразу, без собесов. 3 года назад, когда у меня было намного меньше опыта, взяли на второй день после активации резюме на Хабр.Карьере и hh.ru.
rkfddf
21.07.2024 19:00+6Почти все серверы поддерживают php из коробки/ по умолчанию, хостинг для php гораздо дешевле любых других языков, достаточно проработанные системы разработки, сделать магазин проще чем на wordpress не встречал, множество готовый материалов. И есть много - много действительно готовых пакетов, тем, шаблонов и прочего и это бесплатно или почти бесплатно и попробуйте сделать магазин на golang хотя бы за 10 раз больше времени, чем на php.
А скорости работы разных языков - ну редко когда нужно миллион раз в цикле чего-то разобрать. Так что на счёт скорости в реальных проектах - вроде бы golang быстрее, а может и нет, поскольку считается не только время, но и процессорные ресурсы, память, дисковое пространство и другое.
И вроде бы php вовсе не сдаёт позиции уже много лет подрят и даже неплохо развивается и даже может излишне усложняется без внятных объяснений зачем так делают.
posledam
21.07.2024 19:00+2Ну так это сравнение тёплого с мягким.
Но по существу ваших тезисов:
Go везде будет работать. Хостинг для Go это вообще любая кофеварка. Да его на будильнике можно запустить. Ему не нужно ничего. Никаких nginx, php-fpm и прочего. Только голая ОС.
Скорость работы языков сравнивать вообще моветон. Надо сравнивать производительность в конкретных типах задач. Производительность это сколько полезной работы может выполнить приложение в единицу времени. Обычно, это количество запросов с какой-никакой полезной нагрузкой (чаще всего бизнесу нужны походы в БД, в другие службы, ну или чтение/запись с диска на крайний). И сколько ресурсов ему для этого потребуется.
Вот в примере автора, никакая полезная нагрузка не приложена. Некая строка c JSON десериализуется в некий объект,.. чтобы что с ним сделать? А ничего. Оптимизатор может вообще эту инструкцию выкинуть, или использовать кеш. Сравнивать надо уметь, а неумеючи можно натянуть сову на глобус, что собственно автор и делает в статье. А ещё и без ссылок на код, из разряда "верьте мне".
PHP свои позиции сдаёт, но это процесс не быстрый, учитывая колоссальное количество бекграунда, написанных решений, поддерживаемых проектов и огромной армии разработчиков. Да, это правда, поднять средней руки интернет-магазинчик на небольшую аудиторию, выгоднее сделать на PHP, при чём даже без особых знаний этого языка, или с минимальными познаниями.
Но напрашивается вопрос. Если пыха такая непобедимая и непотопляемая, зачем и откуда развиваются другие ЯП семимильными шагами и активно внедряются в процесс разработки ПО? Ведь от добра добра не ищут. Не задумывались об этом? Я не к тому, что пыха всё, а к тому, что надо трезво смотреть на вещи не с позиции "здесь и сейчас", а ретроспективно и перспективно.
CherryPah
21.07.2024 19:00+1Хостинг для Go это вообще любая кофеварка. Да его на будильнике можно запустить. Ему не нужно ничего. Никаких nginx, php-fpm и прочего. Только голая ОС.
Только виртуалка с голой ОС стоит дороже шаред-хостинга с nginx (на примере хетцнера более чем в 2 раза).
Ну и в каком-нить ISPmanager/Vesta тебе сразу и вордпресс, и почтовик, и днс, и летсенкрипт и все в 2 клика мышью.
posledam
21.07.2024 19:00+1Ну вы ещё с low-code хостингом сравните. Или с хостингом уже готового интернет-магазина, сайта, блога, который вообще на чём угодно может быть написан, просто покупайте и пользуйтесь. В два клика, без знаний какого-либо ЯП в принципе.
Сегодня уже интернет-магазины, которыми так любят хвастаться "за 3 минуты на коленке на Wordpress" уже давно уступили маркет-плейсам и готовым SaaS-решениям. Блоги тем более атавизм. Сайты-визитки? Я вас умоляю.
Весь этот дешёвый хостинг с ISP, почтовиком с каждым днём становится всё менее востребован. Даже забесплатно.
Разработку сложного ПО, если на внешнем хостинге, ведут в облаках (контейнеры), и там Go побеждает, безапелляционно. Ибо весит копейки, ресурсов ест минимально, не требует ничего, а с учётом тарифов на память и вычислительные ресурсы, это имеет серьёзный вес.
posledam
21.07.2024 19:00+1Вот пример базовый образ
bitnami/php-fpmвесит ~340Mb, а с далеко не самым сложным приложением легко доходит до 1Гб и выше. Базовый образ для приложения на Go, напримерalpine, весит... ~7Мб. Чувствуете разницу? И это не считая, что пыхе также нужен nginx, или ещё какой веб-сервер. На одном единственном экземпляре приложения может не так чувствуется, но когда идёт активная разработка CI/CD, а экземпляров много, уже ощущается неприличное давление и требовательность к ресурсам. И по времени развёртывания, и по хранению и прочее прочее.
Upsarin01
21.07.2024 19:00$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; }А вот это все разве нельзя по аналогии с golang заменить на:
$some_path_to_file = "....";
if (is_file($some_path_to_file)){
$line = file_get_contents($some_path_to_file);}else{
throw new Exception('file not found...');
}
но я типа не сеньер... ))) Но на больших файлах и дисковых накопителей чтение по 1024 байта - может работать очень долго.
ParaMara
21.07.2024 19:00Показать, что PHP хороший язык программирования, на котором можно делать web-проекты
Можно и нужно - вещи разные. Это я оставлю, а то, что почти собрался писать про тесты выполняющие не написаное на тестируемых языках - опущу и перейду сразу к выводам. Для тех, кого подобное тестирование убедит что нужно выбрать PHP, PHP действительно лучший язык и его нужно выбрать. Всё хорошо.
Fahrain
21.07.2024 19:00Php убивает сам php. Самая важная фича языка - отсутствие типизации, толерантность к ошибкам в данных (сделать из числа строку или массив и работать с этим дальше - легко!) и простота языка позволяют писать то, что на других языках превращается в огромную портянку кода.
Разработчики взяли курс на принудительное внедрение строгой типизации.
Теперь нельзя вызвать count() на не-массиве потому что он, внезапно, not-countable - причем десятилетия это не было проблемой, но теперь всё падает с ошибкой. В итоге тот код, который раньше нормально переваривал любые входные данные теперь требует дополнительных приседаний, чтобы убедиться, что эти данные - корректны (т.е. получилось как во всех остальных языках).
Сделан очень большой упор на классы везде: причем все новые фичи языка завязаны именно на классы, при том что бОльшая часть старой кодовой базы - процедурно-ориентированная.
... и еще много всякого
В итоге php постепенно превращается в какой-то c++ на минималках, даже js уже выглядит лучше.
Vitaly48
21.07.2024 19:00+6Golang интересный язык, но опишу пункты которые мне в нём не понравились
Отсутствуют исключения, из-за этого код превращается в лапшу с постоянными проверками err != nil
Отсутствует полноценное ООП, нет наследования, интерфейсы имплементируются не явно, а с помощью утиной типизации
Нет полноценных фреймворков как Laravel иди Symfony
Если честно я не понимаю почему все говорят что PHP разработчикам легко переходить на Golang, я постоянно чувствовал отторжение, в тоже время когда я сел за проект на Kotlin, то я почувствовал себя как дома, все тоже самое что и в PHP, только с бОлшими возможностями
gudvinr
21.07.2024 19:00Отсутствуют исключения, из-за этого код превращается в лапшу с постоянными проверками err != nil
Зато не превращается в лотерею "из кишков какой библиотеки вылетело необработанное исключение и положило программу"
Отсутствует полноценное ООП, нет наследования, интерфейсы имплементируются не явно, а с помощью утиной типизации
Это проблема только если вы пытаетесь применять ООП. В го используется композиция, а не наследование.
Если не пытаться натянуть ООП и использовать то, что предлагает язык, то все вполне себе ок. Да, неудобно, если вы всю жизнь писали на ООП, но это проблема не в го. Никто же на хаскел не ругается, что там неправильный ООП.Нет полноценных фреймворков как Laravel иди Symfony
Во-первых, есть. Во-вторых, они просто никому не нужны потому что стандартная библиотека позволяет сделать примерно всё, что надо, без фреймворков.
А если не позволяет, есть библиотеки, которые позволяют. При этом не возникает необходимости тянуть фреймворк.Все ваши претензии - это не проблемы языка или экосистемы, это проблемы конкретно вас. И тут дело такое: программисту на Яве будет неудобен ПХП, программисту на Руби будет неудобна Ява, и т.д.
Из зоны комфорта выходить всегда неприятно, но если не хочется то и не надоFanatPHP
21.07.2024 19:00+1из кишков какой библиотеки
А разве имеет значение из какой? Вы наверное имели в виду просто "превращается в лотерею "вылетело необработанное исключение и положило программу"?
Мне кажется, для фатальных ошибок это нормально, и таких большинство. Не вижу смысла продолжать работу, если у вас нет соединения с БД. А в тех отдельных случаях, когда модуль второстепенный и ошибку можно проигнорировать, обращение к нему заключим в трай.
xenon
21.07.2024 19:00Go надо воспринимать как чуть более удобный С. Исключений нет, потому что их нет на самом деле на "железном" уровне, эта абстракция создается языками высокого уровня, а Golang - низкого. На C их тоже нет. По вопросу ООП - так же. Ну и да, это неудобно для человеческого мозга. Но если golang развивать до уровня удобства пайтона, мы пайтон в итоге и получим, со всеми его плюсами и минусами.
rcl
21.07.2024 19:00Человечество постоянно переписывает софт с одного языка на другой. В этом нет ничего сверхестественного. Однско в этом переписывании есть несколько проблем:
Потеря знаний массами программистов (существовало огромное число библиотек, написанных на языках Algol, FORTRAN, и теперь они не могут служить в качестве учебников для современнях программистов, а вся математика теперь в таких вещах, как Mathematica, Mathlab, ...)
-
Чрезмерные финансовые затраты (корпорации мечтают о создании языков, удешевляющих работу программистов, однако, затраты на портирование старых программ огромны. Пример: COBOL, программы на котором уже, 10 лет как назад, пора портировать из-за естественного вымирания программистов)
А в остальном прогресс - это хорошо. Но совершать его надо с умом и осторожно.
posledam
21.07.2024 19:00+4Что-то тут не чисто. Я решил из любопытства исполнить приведённый код на Go на своей локальной машине (i7-13700, 64gb ram, win11). Так как автор не удосужился представить полных исходников и пример JSON файла, я руками сделал самый простейший.
package main import ( "encoding/json" "fmt" "log" "os" "sync" "time" ) type Test struct { Value1 int `json:"Value1"` Value2 string `json:"Value2"` } 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 := time.Now().UnixMicro() 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 := time.Now().UnixMicro() fmt.Printf("result = %d microseconds \n", (end-start)) }test.json
{ "Value1": 123, "Value2": "test2" }И у меня получилось вот так
result = 271338709 microseconds~271 секунда, Карл!
В результате выполнения этих команд получил:
Golang скомпилированный под локальную машину выполнял команду - 452.430msОткуда тут пол секунды получилось?
И для сравнения, сделал подобный тест на dotnet 8.0
using System.Diagnostics; using System.Text.Json; var file = File.ReadAllText("D:\\Sources\\TestVsPhp\\test.json"); var sw = Stopwatch.StartNew(); var last = Enumerable.Range(0, 1000000000) .AsParallel() .Select<int, Test>(_ => JsonSerializer.Deserialize<Test>(file)) .LastOrDefault(); Console.WriteLine($"result: {sw.ElapsedMilliseconds} milliseconds"); public record Test(int Value1, string Value2);с результатом
result: 25600 milliseconds25.6 сек, быстрее в 10 раз. Если брать байты, а не строку, то ~22 сек.
Мутная история какая-то с этим тестом, с его адекватностью, и представленными результатами.
blind_oracle
21.07.2024 19:00+2Зачем делать 1000000000 горутин? Это ж там только на шедулинг сколько оверхеда будет.
illiatovpeko
21.07.2024 19:00Фигасе у тебя перерыв: до этого последний раз публиковался в 2011. Чего раньше на связь не выходил, опытом не делился ...?)
Rive
21.07.2024 19:00Вроде пользователи никаких обязательств при регистрации не дают по регулярному развлечению друг друга.
gro
Бедная похапешечка, сколько раз её убивали.
xenon
Моя теория умирания языков программирования - у языков программирования может быть очень сильная инерция. Главное, что надо понимать - хорошесть/плохость языков - штука условная и почти всегда любой "плохой" язык тоже вполне сносен.
Если язык "взлетел", оброс большим количеством проектов, в том числе коммерческих, умирать он будет долго, медленно. Даже если мы представим, что вдруг внезапно всем очевидно, что (неважно, но для примера, допустим) Golang 100% лучше, чем PHP, все равно, PHP может умирать еще десятилетия!
Если в бизнесе уже есть приложение на умирающем языке, никто в здравом уме не будет его переписывать просто потому, что язык уже не моден. Работает - и хорошо! Соответственно, есть спрос на программистов, работающих на этом языке (кто-то же должен обслуживать и развивать это ПО). Более того, этот похапешный отдел скорее всего и новые проекты будет на похапе делать (потому что мозгу так проще, иметь в голове одну модель языка, а не переключаться). Можно даже в каком-то смысле воспринимать ЯП как вирус - если контора заболела каким-то "плохим" языком программирования в детстве - есть риск, что она будет так болеть вечно. И еще может быть в ходе агонии породит новые проекты на этом "условно умирающем" языке, в том числе и более-менее успешные.
Помните, такой язык как Perl? Если про PHP можно спорить про его умирание, то Perl, наверное, более мертв (чем PHP)? Однако, до сих пор SpamAssassin на множестве почтовых серверов в мире - на перле. И инсталляшки дебиана его, вроде используют. И чтобы с ними как-то что-то делать - востребованы программисты на Perl. Инерция.
CherryPah
Perl с сетью хорошо работает. хBSD во многом жива по тем же причинам.
RighteousHippie
буквально вчера на одном сайте видел в адресной строке что-то типа /cgi-bin/stat.pl?ses=111&uu=222&pp=333
Так что даже web приложения на perl где-то ещё работают
WST
Вовсе не факт. Иногда старые URL-ки просто сохраняют для совместимости (чтобы работали старые ссылки), а на деле под капотом может быть PHP или Python + Django или что угодно ещё, ведь маршрутизацию URL можно как угодно настроить.
Мы с друзьями делали URL-ки, заканчивающиеся на *.jsp, и ещё в заголовках отдавали «X-Powered-By: Apache Tomcat» вообще чисто забавы ради, т.к это был бэкенд.