Я пишу на php около 12 лет и это превосходный язык программирования, на нем написано 90% сайтов всего интернета. Почти каждая популярная CMS написана на PHP.
Почему же я перешел (вернее перехожу) на Go?
Многопоточность
В принципе здесь всё понятно. Многопоточность даёт колоссальные преимущества языку программирования. В Go многопоточность реализована очень просто и выразительно. В следующем пункте раскрою преимущества затрагивающие разработку сайта.
Окружение
Что мне нужно чтобы поднять обычный сайт на php?
Сервер на Linux, установить Nginx, иногда и Apache, поставить PHP, расширения, базу данных, Memcache, настроить Cron. Чтобы не было мучительно больно обслуживать сервер ставлю все в Docker. Вот так выглядит мой обычный Docker проект на PHP.
Знакомо?
Что нужно чтобы поднять обычный сайт на Go?
Сервер на Linux и установить Go. Всё. Круто? Так происходит потому что Go многопоточный и любой функционал можно вынести в отдельный поток, например веб-сервер, микро-сервисы, очереди, крон и т.п. Многие вещи уже реализованы в базовых пакетах.
Как же у меня выглядит Docker проект для Go? По сути его вообще нету. Я кладу Docker файлы прямо в папку с кодом сайта или сервиса. Если сайт имеет дополнительные микро-сервисы (например для работы с очередями) то в папку с этим сервисом кладется свой Dockerfile.
Порог вхождения
Выучить язык Go очень просто. Всю документацию можно пролистать за пару часов и понять принцип работы языка без углублений. Я думаю у Go самая короткая документация из популярных компилируемых языков.
На официальном сайте можно пройти тур по изучению, который раскроет все аспекты языка.
Углубить свои теоретические знания до профи можно за очень короткое время. Рекомендую курсы от Mail.ru на YouTube.
Читаемость кода
Было ли у вас такое, что вы открываете чужой код, модуль, плагин и т.п. и понимаете, что ничего не понимаете. И чтобы разобраться в тонкостях нужно как минимум с дебагом пройтись по основному коду.
В Go в большинстве случаев открывая какой-нибудь лютый код на 200 файлов и каждый файл полотенце кода, удивляешься тому что ты его способен понять слёту.
IDE
Писать в IDE JetBrains под PHP и под Go — это совершенно разные вещи. Автодополнение работает всегда и везде (99% случаев). Провалится можно в любой метод, в любой!
Тормозов нет совсем. Словами в общем это трудно описать, нужно попробовать. Когда вы начинаете полноценно писать в Goland то понимаете, что назад в PhpStorm уже не хотите возвращаться.
В позапрошлом году на хайлод я спрашивал у Дмитрия Стогова о планах по внедрению в PHP «нативной» многопоточности и похоже, что мы её не увидим, а жаль.
Отладка и тестирование
Многие разработчики PHP вообще не пользуются отладкой из-за того, что его нужно отдельно ставить как расширение, также нужно правильно настроить и многие просто не заморачиваются и пользуются выводом на страницу. В Go же дебаг встроен, по сути можно и не разбираться как он работает внутри, если вы пользуетесь IDE просто ставите точку остановки и запускаете программу.
С тестированием дела обстоят примерно также, не нужно подключать целый фреймворк к проекту, оно уже встроено в базовые пакеты и IDE.
Производительность
Go по скорости исполнения и потребления памяти намного превосходит PHP. Конечно их сравнивать не правильно, так как Go компилируемый язык. Хорошая статья по сравнению производительности есть на Хабре. К примеру у меня миркосервис в полном Docker окружении, который раньше занимал 100-200 мб оперативной памяти, перейдя на Go занимает 1-2 мб. Прирост скорости в 2-5 раз.
Итог
Я люблю PHP и буду продолжать на нем писать по мере необходимости, но Go стал для меня продолжением развития и если бы я переписал PHP с нуля, он бы стал языком Go.
Комментарии (36)
skymal4ik
04.02.2019 23:03+2Согласен с комментарием выше, веб сервер перед приложением может быть полезен (балансировка, tls termination, редиректы и т.д.)
А как в go с поддержкой web? Надо ли учить какой-то фреймворк? Или прямо в самом языке есть средства для работы с http, cookies, сессиями, формами и так далее?
calisto
04.02.2019 23:29На мой взгляд в go хорошая стандартная библиотека, которая содержит всё необходимое для веба: http, cookie, формы, шаблоны. Часть своих проектов для web у меня на «чистом go», т.е. все написано средствами стандартной библиотеки. Как правило это довольно простые сервисы с небольшим функционалом, но со всеми «атрибутами» web-а: cookie / JWT, формы, генерация страниц по шаблонам. Для чего-то сложно можно взять фрэймворк, если он реализует необходимую рутину. Например, для разработки микросервисов или приложения на базе плагинов.
eugenk
05.02.2019 03:49-2А что с поддержкой веб в java? А что с поддержкой веб в C? Я сейчас довольно часто вставляю в свои поделки простенький веб-сервер. Во-первых через браузер очень приятно писать GUI. Во-вторых однажды, когда ваял некоторое средство шпионажа для iOS, это меня просто спасло, ибо иным путем достать оттуда лог было невозможно. И ничего. Пишу всё что мне надо ручками и не жужжу. Например последний проект — контроллер электрической печки (плюс куча дополнительных функций кроме печки) на esp32. Поднял веб-сервер ручками на esp32 на чистом С. Что, мне apache туда надо было ставить?
r00tGER
05.02.2019 09:52Как то у вас всё в кучу. Встраиваемые системы с ограниченными ресурсами, и админкой на одного пользователя и высоконагруженные сервисы с кучей параллельных сессий.
Причем, по контексту статьи прекрасно понятно о каком именно случае идет речь.
UncleAndy
04.02.2019 23:36+4«Сервер на Linux и установить Go.»
Вот это не совсем понятно. Если подразумевается работа с docker, то нужен только сервер с docker и все. А в образ достаточно разместить сам исполняемый скомпилированный файл (на go его можно сделать самодостаточным — без необходимости внешних библиотек) и, возможно, какие-то внешние данные в файлах для него. Т.е. это свойство запускаемого файла на go (отсутствие зависимостей) подразумевает что можно использовать минималистичный образ alpine в качестве основы.
Естественно, если речь идет о развертывании на сервере без docker, все описанное справедливо и для сервера — размещать на нем нужно только исполняемый файл приложения. Go на нем ставить не нужно.
Опять-же, если подразумевается что разработчик работает на Windows, а бинарник приложения ему нужен на Linux, то и это можно делать (насколько я знаю) не разворачивая Go на Linux сервере — кросскомпиляция в Go просто шикарная. Врать не буду — из Windows линуксовые бинарники не делал. Но из Linux виндовые — вполне.
dok2d
04.02.2019 23:53+7Когда же вы, наконец, выберете лучшую платформу для разработки сайтов и начнёте уже работать?
eugenk
05.02.2019 03:59-4Замечание не в тему. Я например просто ВЫНУЖДЕН писать такие вещи на php, ибо все мои поделия в области сайтостроения адресованы нищему российскому юзеру, которому у хостера кроме php и mysql ничего недоступно. Но такая работа мне не доставляет абсолютно никакого удовольствия. Если для фронтэнда сейчас стало получше (появился typescript и ещё много чего), то с серверной стороной увы. Приходится писать на том что есть.
Compolomus
05.02.2019 04:32Если вы до сих пор на php5+, то гляньте в сторону php7+. Это совсем разные уровни. Ну и нормальный код в шторме не сложно отследить. Конечно старый быдлокод в нем сложно редактировать
eugenk
05.02.2019 04:48Да нет, я на 7-м сейчас. Почти то же что 5-й, единственно стал существенно шустрее. Впрочем ничего сложного я на нём не пишу. Просто принять от клиента команды, сделать sql-запросы, что-то сохранить, что-то выдать и т.п. Ну и да, сделать антикеширующую обработку перед стартом, чтобы браузер не закешировал старую версию приложения. Вычислительную часть я переношу в клиента. А там с появлением языков, компилирующихся в js стало существенно проще. Единственно надо помнить все многочисленные class-ы и id-ы в GUI (на страничке) но это требует только чуть больше тестирования. А так — почти привычная среда java, C/C++ и т.п.
И да, пишу я не в шторме а в vscode. Потрясающая по удобству вещь! Кстати php там очень неплохо поддержан. И в отличии от шторма лёгкая и шустрая.Compolomus
05.02.2019 05:14Ну тогда ffi точно Вам зайдет)
eugenk
05.02.2019 05:42-1Вопрос будет ли это поддерживаться обычными дешевыми хостерами. Я ведь на php и сейчас пишу только потому, что делаю кое-что для обычной нищей публики, а не для корпоративных клиентов, которым я могу сказать мол ставьте выделенный сервер с jvm. Так что тут что есть, тому и рады :)
sha4
05.02.2019 09:04Эм..., а причем тут «нищие»? Есть физические лица и юридические, и у них всегда будут разные бюджеты и разные запросы.
Если вы не можете низкобюджетному клиенту подсказать, что кроме былдохостингов с закрученными гайками есть vps за пять баксов, то вы сам себе злобный буратино.eugenk
05.02.2019 09:07-1Как бы специфика там немного другая. Не хотелось бы вдаваться в подробности, но поверьте, что такой вариант тут не подходит.
enzain
05.02.2019 09:25делаю кое-что для обычной нищей публики
Я так понимаю, эта публика вас кормит, от части… В свете чего подобные выражения выглядят странно ...
Не сообщите, кто Вы в жизни, дабы обойти Вас ежели вдруг встретимся?:)
Зачем такого человека отвлекать, пусть работает на гугл… :)
eugenk
05.02.2019 09:45Пока не кормит. Есть расчет на то что будет кормить, но пока сама поделка не готова. Но точить её приходится на публику заведомо самую небогатую. Потому серверная часть и на php. От подробностей, если не возражаете, всё-таки хотелось бы воздержаться. Ибо штука что называется «на грани».
aeeneas
05.02.2019 08:30+1Поиски «той самой» платформы больше похожи на страдания плохого танцора. По факту с 80-х основные концепции мейнстримового программирования почти не изменились, поэтому выбор инструмента в-основном определяется встроенными батарейками для конкретной задачи, распространённостью и поддержкой.
По этим параметрам PHP вполне оптимален, поэтому он по-прежнему широко используется в реальном сайтостроении, вопреки ценному мнению любителей экзотики.
eugenk
05.02.2019 08:50Батарейки это вообще не в тему ибо определяются исключительно существующими библиотеками, а не языком. И php тут оптимален не потому что это такой прекрасный язык, а исключительно из-за того, что он изначально под сайтостроение точился и эти самые батарейки в нем с самого начала. Будь у меня выбор в проектах для простой публики, писал бы на java или scala. Там «батарейки» для веба тоже очень неплохие. Но увы, дешевые хостинги jvm не предоставляют. Поэтому приходится плюясь и матерясь на php.
enzain
05.02.2019 09:27Ну как по мне, так писать надо на том, на чем умеешь…
Умеешь лучше на шарпе — так пиши на шарпе а не на пхп… :)
Compolomus
05.02.2019 01:05Ну с каждой версией php что то, да добавляет в "коробку"
Не всегда нужна многопоточность, опять же при желании можно добавить, а так "коробка" и так не маленькая.
Гляньте что творят Бадушники :)
Не за горами php8eugenk
05.02.2019 03:55-2Гляньте что творят Бадушники :)
Не за горами php8
Со статической типизацией и нормальной многопоточностью ???Compolomus
05.02.2019 04:11Я может не пишу на разных ЯП, не могу сказать эта нормальная, а это не нормальная многопоточность, но она есть в php и даже тут можно почитать, статьи три видел.
Ну и типизация подтягивается, в 7.4 обещали типы для свойств
https://wiki.php.net/rfc/typed_properties_v2eugenk
05.02.2019 04:21Дай-то Бог, которого нет :)) На php мне приходится писать довольно редко, и только для себя (никогда по работе), но каждый раз это мучение, которое я выбираю, если других вариантов вообще уже нет. В 7-м хоть с производительностью стало получше. Если типы появятся, будет вообще классно.
enzain
05.02.2019 09:29Типизацию б ему как в шарпе… ну или как в паскале ..:D
Было б сильно приятнее ....eugenk
05.02.2019 09:50Без статической типизации я вообще уже зарекся делать что-либо серьезное. Было дело начал проект на js, так на третьей тысяче строк запутался. Хорошо добрые люди с форума по javascript подсказали про typescript. Он в те времена был ещё новьем.
SerafimArts
05.02.2019 02:55+1Сервер на Linux, установить Nginx, иногда и Apache, поставить PHP, расширения, базу данных, Memcache, настроить Cron. Чтобы не было мучительно больно обслуживать сервер ставлю все в Docker. Вот так выглядит мой обычный Docker проект на PHP.
Что-то как-то слишком субъективно. Как и для запуска пыха достаточно поставить один голый пых, работая через builtin, кастомные серваки, вроде реакта или под хайлоад дособрать swoole какой-нибудь, так и для go для работы с каким-нибудь MySQL надо установить, внезапно (sic!), ещё и сам MySQL…
eugenk
05.02.2019 03:38-2О главном забыли. В Go статическая типизация. Именно поэтому поэтому в IDE нормально работает автокомплит и всё прочее. Тут уже была где-то осенью статья о сравнении в этом смысле typescript и javascript. Я очень ждал и надеялся что хотя бы кто-то из любителей js скажет хоть слово в защиту его утиной типизации но так и не дождался. Вы только ещё раз подтвердили, что динамическая типизация это Абсолютное Зло и должна умереть в программировании.
immaculate
05.02.2019 04:22-2В Go в большинстве случаев открывая какой-нибудь лютый код на 200 файлов и каждый файл полотенце кода, удивляешься тому что ты его способен понять слёту.
Когда-то давно Python не был так распространен, как сейчас, и я был искренне убежден, что на нем невозможно написать плохой код. Когда популярность Python выросла, начиная где-то с 2006-го года, я регулярно стал сталкиваться с абсолютно нечитаемой адской лапшой на Python.
Дурак (или просто неопытный человек) на любом языке напишет плохо. Нет серебряной пули… Есть языки, на которых, мне кажется, 80-90% кода ужасны (Perl, PHP, Javascript), но нет языка, на котором любой код будет хорош.
На Go просто пока что пишут большие энтузиасты из любви к искусству. Когда в него потянутся любители легких денег (потому что много привлекательных вакансий), станет так же, как и с любым другим языком: нечитаемая лапша, функции на четыре страницы с 5-10 кратно вложенными
ifи/или циклами, архитектура в стиле Big Ball of Mud, и т.д. и т.п.
Кстати, я вот хотел сделать сайт на Go, но не нашел пока какого-то красивого фреймворка, с большим количеством встроенных батареек. Чтобы можно было сосредоточиться на написании сложной функциональности, а все тривиальные задачи фреймворк взял на себя. Может кто-нибудь посоветовать, на что посмотреть?
KTG
05.02.2019 06:22А в чем смысл топить за Go?
Сравнительный анализ хорошо, как-то статью находил PHP vs Ruby vs Go vs Java. И по многопоточности там Go не так уж и хорош был. Правда там то же вызвало вопросы некоторые вещи.
Видел как и на Pascale делали вещи, которые другие на С не могли. И дело было вовсе не в языке, а в том, что легче далось/что оказалось под рукой/что знаешь.
Но мы же о веб-разработке говорим…
90% задач решаются одним и тем же способом на любом языке, они немного отличаются синтаксисом, и глубоких знаний в общем-то и не требуют. И есть подозрения что в ближайшем будущем в этом плане изменений не предвидится.
А судя по подобным статьям, оставшиеся 10% это видимо ресурсы с миллионами одновременных обращений в секунду. Но что-то обилие таких в интернете замечено не было. Много ли их открылось за последние 3 года? Хотя отрицать не будем, у всех разные задачи и амбиции и перспективы развития, мало ли.
Ещё один вопрос, если отказаться от PHP и перейти на Go то много ли измениться, если использовать будем фреймворки, а они в свою очередь всё те же общие библиотеки? jQuery, Ajax, TinyMCE?
И я до сих пор не пойму чего плохого в динамической типизации?
Сравнивая с искусством так вообще, подобные статьи смахивают на то что школа Рембрандта одна единственная верная, а Дали и Пикассо — быдлокодеры. Я за понятный и чистый код, без перегруженной логики, в остальному пусть кто как хочет так и кодит.
Докопаюсь до предыдущего комментария:
и я был искренне убежден, что на нем невозможно написать плохой код. Когда популярность Python выросла, начиная где-то с 2006-го года, я регулярно стал сталкиваться с абсолютно нечитаемой адской лапшой на Python.
Дурак (или просто неопытный человек) на любом языке напишет плохо. Нет серебряной пули…
Подозреваю человек переживает за плохой нечитаемый код.
Но думаю он вряд ли заглядывал или разбирал внутрянку:
Кстати, я вот хотел сделать сайт на Go, но не нашел пока какого-то красивого фреймворка, с большим количеством встроенных батареек.
Тогда смысл переживать?
eugenk
05.02.2019 07:31-1Народ тут интересный. Понаставили кучу минусов, а возражений ПО СУЩЕСТВУ я пока что-то не видел. Религия не позволяет?
gnomeby
05.02.2019 08:16Ну это наивная статья, которая сравнивает несравниваемое:
* Связку из асинхронного nginx+php и многопоточность языка. (Отдачу статических больших файлов автор тоже видимо на Go с нуля реализовывать будет с поддержкой докачки.)
* Количество файлов в проекте для компилируемого и транслируемого языка
* Скорость работы IDE для статической и динамической типизации
А Порог входжения в язык вообще не является критерием чего-либо.
Что тут обсуждать-то? Убрать в черновики и не позориться.
qRoC
05.02.2019 08:47* Сказано далее — критика статьи, и никак не раскрывает моё отношение к данным языкам.
Многопоточность даёт колоссальные преимущества языку программирования.
Простите, на какие преимущества то? C++ это или Go, многопоточность в любом случае добавляет немалой сложности как на этапе разработки, так и на этапе тестирования.
Даже на производительность нельзя упереться. Возьмите тот же «супер быстрый» valyala/fasthttp и посмотрите как его рекомендуют запускать — по инстансу на ядро.
Что мне нужно чтобы поднять обычный сайт на php?
Сервер на Linux, установить Nginx, иногда и Apache, поставить PHP, расширения, базу данных, Memcache, настроить Cron.
Сервер на Linux и установить Go.
1) Для приложения на Go всё кроме PHP может так же присутствовать.
2) Зачем устанавливать Go на сервере где разворачивается приложение написанное на данном языке?
3) Тогда уже можно сказать про `php -S`
Так происходит потому что Go многопоточный и любой функционал можно вынести в отдельный поток, например веб-сервер, микро-сервисы, очереди, крон и т.п.
А как потом вы собираетесь горизонтально масштабироваться? Да и Вы в курсе что каждый такой «поток» будет забирать процессорное время?
В Go в большинстве случаев открывая какой-нибудь лютый код на 200 файлов и каждый файл полотенце кода, удивляешься тому что ты его способен понять слёту.
Видно у Вас дар. Я, например, так сразу разобрать метод в котором 300 строк кода, и который на половину состоит из «err != nil» — не могу. Но про полотенце Вы правы.
В Go же дебаг встроен, по сути можно и не разбираться как он работает внутри, если вы пользуетесь IDE просто ставите точку остановки и запускаете программу.
Забавно, я всегда производил дебаг через GDB или Delve. А оказывается есть встроенный, как его вызвать, простите?
В целом, статья похожа на «вброс».
tuxi
Я бы поспорил бы насчет «ненужности» прокси сервера перед web-приложением на go. Давеча, при тестировании нагрузкой простейшего сервиса на go, связка nginx + go отработала лучше (показала бОльшую производительность) нежели чем чистый go.
Я не отрицаю, что имея хороший практический бекграунд на go, nginx может и не потребуется, но в контексте «с php на go», имхо это скорей вредный совет.
Ghost_nsk
Если мы говорим про нагрузки, то для nginx+go надо два сокета на одно соединение, а они очень не бесконечны. Но да, это скорее не про «с php на go».