Как стать автором
Обновить

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

Я бы поспорил бы насчет «ненужности» прокси сервера перед web-приложением на go. Давеча, при тестировании нагрузкой простейшего сервиса на go, связка nginx + go отработала лучше (показала бОльшую производительность) нежели чем чистый go.
Я не отрицаю, что имея хороший практический бекграунд на go, nginx может и не потребуется, но в контексте «с php на go», имхо это скорей вредный совет.
Если мы говорим про нагрузки, то для nginx+go надо два сокета на одно соединение, а они очень не бесконечны. Но да, это скорее не про «с php на go».
Согласен с комментарием выше, веб сервер перед приложением может быть полезен (балансировка, tls termination, редиректы и т.д.)

А как в go с поддержкой web? Надо ли учить какой-то фреймворк? Или прямо в самом языке есть средства для работы с http, cookies, сессиями, формами и так далее?
На мой взгляд в go хорошая стандартная библиотека, которая содержит всё необходимое для веба: http, cookie, формы, шаблоны. Часть своих проектов для web у меня на «чистом go», т.е. все написано средствами стандартной библиотеки. Как правило это довольно простые сервисы с небольшим функционалом, но со всеми «атрибутами» web-а: cookie / JWT, формы, генерация страниц по шаблонам. Для чего-то сложно можно взять фрэймворк, если он реализует необходимую рутину. Например, для разработки микросервисов или приложения на базе плагинов.
А что с поддержкой веб в java? А что с поддержкой веб в C? Я сейчас довольно часто вставляю в свои поделки простенький веб-сервер. Во-первых через браузер очень приятно писать GUI. Во-вторых однажды, когда ваял некоторое средство шпионажа для iOS, это меня просто спасло, ибо иным путем достать оттуда лог было невозможно. И ничего. Пишу всё что мне надо ручками и не жужжу. Например последний проект — контроллер электрической печки (плюс куча дополнительных функций кроме печки) на esp32. Поднял веб-сервер ручками на esp32 на чистом С. Что, мне apache туда надо было ставить?
Как то у вас всё в кучу. Встраиваемые системы с ограниченными ресурсами, и админкой на одного пользователя и высоконагруженные сервисы с кучей параллельных сессий.
Причем, по контексту статьи прекрасно понятно о каком именно случае идет речь.
«Сервер на Linux и установить Go.»

Вот это не совсем понятно. Если подразумевается работа с docker, то нужен только сервер с docker и все. А в образ достаточно разместить сам исполняемый скомпилированный файл (на go его можно сделать самодостаточным — без необходимости внешних библиотек) и, возможно, какие-то внешние данные в файлах для него. Т.е. это свойство запускаемого файла на go (отсутствие зависимостей) подразумевает что можно использовать минималистичный образ alpine в качестве основы.

Естественно, если речь идет о развертывании на сервере без docker, все описанное справедливо и для сервера — размещать на нем нужно только исполняемый файл приложения. Go на нем ставить не нужно.

Опять-же, если подразумевается что разработчик работает на Windows, а бинарник приложения ему нужен на Linux, то и это можно делать (насколько я знаю) не разворачивая Go на Linux сервере — кросскомпиляция в Go просто шикарная. Врать не буду — из Windows линуксовые бинарники не делал. Но из Linux виндовые — вполне.
Можно даже FROM scratch;
Замечание не в тему. Я например просто ВЫНУЖДЕН писать такие вещи на php, ибо все мои поделия в области сайтостроения адресованы нищему российскому юзеру, которому у хостера кроме php и mysql ничего недоступно. Но такая работа мне не доставляет абсолютно никакого удовольствия. Если для фронтэнда сейчас стало получше (появился typescript и ещё много чего), то с серверной стороной увы. Приходится писать на том что есть.

Если вы до сих пор на php5+, то гляньте в сторону php7+. Это совсем разные уровни. Ну и нормальный код в шторме не сложно отследить. Конечно старый быдлокод в нем сложно редактировать

Да нет, я на 7-м сейчас. Почти то же что 5-й, единственно стал существенно шустрее. Впрочем ничего сложного я на нём не пишу. Просто принять от клиента команды, сделать sql-запросы, что-то сохранить, что-то выдать и т.п. Ну и да, сделать антикеширующую обработку перед стартом, чтобы браузер не закешировал старую версию приложения. Вычислительную часть я переношу в клиента. А там с появлением языков, компилирующихся в js стало существенно проще. Единственно надо помнить все многочисленные class-ы и id-ы в GUI (на страничке) но это требует только чуть больше тестирования. А так — почти привычная среда java, C/C++ и т.п.
И да, пишу я не в шторме а в vscode. Потрясающая по удобству вещь! Кстати php там очень неплохо поддержан. И в отличии от шторма лёгкая и шустрая.

Ну тогда ffi точно Вам зайдет)

Вопрос будет ли это поддерживаться обычными дешевыми хостерами. Я ведь на php и сейчас пишу только потому, что делаю кое-что для обычной нищей публики, а не для корпоративных клиентов, которым я могу сказать мол ставьте выделенный сервер с jvm. Так что тут что есть, тому и рады :)
НЛО прилетело и опубликовало эту надпись здесь
Как бы специфика там немного другая. Не хотелось бы вдаваться в подробности, но поверьте, что такой вариант тут не подходит.
НЛО прилетело и опубликовало эту надпись здесь
Пока не кормит. Есть расчет на то что будет кормить, но пока сама поделка не готова. Но точить её приходится на публику заведомо самую небогатую. Потому серверная часть и на php. От подробностей, если не возражаете, всё-таки хотелось бы воздержаться. Ибо штука что называется «на грани».
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Батарейки это вообще не в тему ибо определяются исключительно существующими библиотеками, а не языком. И php тут оптимален не потому что это такой прекрасный язык, а исключительно из-за того, что он изначально под сайтостроение точился и эти самые батарейки в нем с самого начала. Будь у меня выбор в проектах для простой публики, писал бы на java или scala. Там «батарейки» для веба тоже очень неплохие. Но увы, дешевые хостинги jvm не предоставляют. Поэтому приходится плюясь и матерясь на php.
VPS — 512Mb/1Ghz можно взять за пару евро в месяц, куда ещё дешевле?
НЛО прилетело и опубликовало эту надпись здесь

Ну с каждой версией php что то, да добавляет в "коробку"
Не всегда нужна многопоточность, опять же при желании можно добавить, а так "коробка" и так не маленькая.
Гляньте что творят Бадушники :)
Не за горами php8

Гляньте что творят Бадушники :)
Не за горами php8

Со статической типизацией и нормальной многопоточностью ???

Я может не пишу на разных ЯП, не могу сказать эта нормальная, а это не нормальная многопоточность, но она есть в php и даже тут можно почитать, статьи три видел.
Ну и типизация подтягивается, в 7.4 обещали типы для свойств
https://wiki.php.net/rfc/typed_properties_v2

Дай-то Бог, которого нет :)) На php мне приходится писать довольно редко, и только для себя (никогда по работе), но каждый раз это мучение, которое я выбираю, если других вариантов вообще уже нет. В 7-м хоть с производительностью стало получше. Если типы появятся, будет вообще классно.

Ещё ffi будет и JIT

НЛО прилетело и опубликовало эту надпись здесь
Без статической типизации я вообще уже зарекся делать что-либо серьезное. Было дело начал проект на js, так на третьей тысяче строк запутался. Хорошо добрые люди с форума по javascript подсказали про typescript. Он в те времена был ещё новьем.
НЛО прилетело и опубликовало эту надпись здесь
Сервер на Linux, установить Nginx, иногда и Apache, поставить PHP, расширения, базу данных, Memcache, настроить Cron. Чтобы не было мучительно больно обслуживать сервер ставлю все в Docker. Вот так выглядит мой обычный Docker проект на PHP.


Что-то как-то слишком субъективно. Как и для запуска пыха достаточно поставить один голый пых, работая через builtin, кастомные серваки, вроде реакта или под хайлоад дособрать swoole какой-нибудь, так и для go для работы с каким-нибудь MySQL надо установить, внезапно (sic!), ещё и сам MySQL…
О главном забыли. В Go статическая типизация. Именно поэтому поэтому в IDE нормально работает автокомплит и всё прочее. Тут уже была где-то осенью статья о сравнении в этом смысле typescript и javascript. Я очень ждал и надеялся что хотя бы кто-то из любителей js скажет хоть слово в защиту его утиной типизации но так и не дождался. Вы только ещё раз подтвердили, что динамическая типизация это Абсолютное Зло и должна умереть в программировании.
В Go в большинстве случаев открывая какой-нибудь лютый код на 200 файлов и каждый файл полотенце кода, удивляешься тому что ты его способен понять слёту.

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


Дурак (или просто неопытный человек) на любом языке напишет плохо. Нет серебряной пули… Есть языки, на которых, мне кажется, 80-90% кода ужасны (Perl, PHP, Javascript), но нет языка, на котором любой код будет хорош.


На Go просто пока что пишут большие энтузиасты из любви к искусству. Когда в него потянутся любители легких денег (потому что много привлекательных вакансий), станет так же, как и с любым другим языком: нечитаемая лапша, функции на четыре страницы с 5-10 кратно вложенными if и/или циклами, архитектура в стиле Big Ball of Mud, и т.д. и т.п.


Кстати, я вот хотел сделать сайт на Go, но не нашел пока какого-то красивого фреймворка, с большим количеством встроенных батареек. Чтобы можно было сосредоточиться на написании сложной функциональности, а все тривиальные задачи фреймворк взял на себя. Может кто-нибудь посоветовать, на что посмотреть?

Buffalo видели? Можно ещё тут посмотреть.
Я изучал этот вопрос основательно, остановился на beego
Хотел оставить комментарий, но после этого добавить особо нечего :)

По поводу фреймворков — Beego, Iris, Gin, Revel, Martini, Buffalo. Может, сейчас ещё что-нибудь написали. Особо большого выбора не нашёл, когда интересовался этой темой.
Тут в тему третий абзац комментария — относительно низкая популярность.
А в чем смысл топить за Go?
Сравнительный анализ хорошо, как-то статью находил PHP vs Ruby vs Go vs Java. И по многопоточности там Go не так уж и хорош был. Правда там то же вызвало вопросы некоторые вещи.
Видел как и на Pascale делали вещи, которые другие на С не могли. И дело было вовсе не в языке, а в том, что легче далось/что оказалось под рукой/что знаешь.
Но мы же о веб-разработке говорим…
90% задач решаются одним и тем же способом на любом языке, они немного отличаются синтаксисом, и глубоких знаний в общем-то и не требуют. И есть подозрения что в ближайшем будущем в этом плане изменений не предвидится.
А судя по подобным статьям, оставшиеся 10% это видимо ресурсы с миллионами одновременных обращений в секунду. Но что-то обилие таких в интернете замечено не было. Много ли их открылось за последние 3 года? Хотя отрицать не будем, у всех разные задачи и амбиции и перспективы развития, мало ли.
Ещё один вопрос, если отказаться от PHP и перейти на Go то много ли измениться, если использовать будем фреймворки, а они в свою очередь всё те же общие библиотеки? jQuery, Ajax, TinyMCE?
И я до сих пор не пойму чего плохого в динамической типизации?
Сравнивая с искусством так вообще, подобные статьи смахивают на то что школа Рембрандта одна единственная верная, а Дали и Пикассо — быдлокодеры. Я за понятный и чистый код, без перегруженной логики, в остальному пусть кто как хочет так и кодит.

Докопаюсь до предыдущего комментария:
и я был искренне убежден, что на нем невозможно написать плохой код. Когда популярность Python выросла, начиная где-то с 2006-го года, я регулярно стал сталкиваться с абсолютно нечитаемой адской лапшой на Python.

Дурак (или просто неопытный человек) на любом языке напишет плохо. Нет серебряной пули…

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

Тогда смысл переживать?
Народ тут интересный. Понаставили кучу минусов, а возражений ПО СУЩЕСТВУ я пока что-то не видел. Религия не позволяет?
Ну это наивная статья, которая сравнивает несравниваемое:
* Связку из асинхронного nginx+php и многопоточность языка. (Отдачу статических больших файлов автор тоже видимо на Go с нуля реализовывать будет с поддержкой докачки.)
* Количество файлов в проекте для компилируемого и транслируемого языка
* Скорость работы IDE для статической и динамической типизации

А Порог входжения в язык вообще не является критерием чего-либо.

Что тут обсуждать-то? Убрать в черновики и не позориться.

Ну почему же “сравнивает несравнимое»
Автор показывает преимущества компилируемого языка и типизации на примере Go

НЛО прилетело и опубликовало эту надпись здесь
Забыты пункты про сообщество и экосистему.
Здесь скорее не к языку, а к фреймворкам вопрос. И по ним опрос у сообщества, чем начали пользоваться.
скинь пример как юзать env в go
Не знаю, не приходилось использовать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации