Go или PHP как язык влияет на развертывание приложения?

Question

[Алексей Сумин]

Представим, что есть большое сложное web-приложение, типа Jenkins, которое кроме обработки http запросов еще содержит и какие-то фоновые процессы. Приложение должно устанавливаться на стороне пользователя наипростейшим путем (в самом идеальном случае через Debian пакет) т.е. пользователь будет сам его устанавливать.
На каком языке лучше это сделать PHP или GO (можно предложить другой вариант с обоснованием)?
Я сейчас это вижу в таком разрезе:

Плюсы за GO:
1) Вроде бы должно легче устанавливаться: скомпилировал, запустил демон и всё - он и фоновые процессы через горутины сам в себе запускает, и на http запросы отвечает в т.ч. и статику отдаёт, при этом данные через каналы внутри демона можно спокойно гонять. В PHP придется тащить сразу всю связку PHP-FPM + NGINX, плюс в кроне прописывать все скрипты, которые нужно в фоне запускать.
2) Проще управлять зависимости: скомпилировал в свою программу конкретные расширения нужных версий - и оно другим не мешает. В PHP если на той же машине уже что-то крутиться, могут быть конфликты с версиями, недоступными расширениями и прочим.
3) Производительность и экономное расходование ресурсов.

Минусы GO:
1) Сообщество поменьше чем у PHP.
2) Язык бедноват по сравнению с PHP, трудно реализовывать сложную бизнес логику.

Что посоветуете?
Спасибо заранее.

Comments

[Станислав Б]

а в чем смысл впадать в крайность и пытаться сделать установку

большого сложного web-приложение, типа Jenkins, которое кроме обработки http запросов еще содержит и какие-то фоновые процессы.

в 1 строчку? вероятно если пользователь его ставит, то у него есть сервер под линухой(раз говорите про пакет). И обычно тот, у кого есть сервер под линухой и кому нужно сложное приложение, в состоянии прочитать 3 строчки инструкции по установке. а раз оно отвечает на http, то нджинкс там напрашивается в любом случае.

Answer 1

[Леонид Николаев]

Язык бедноват по сравнению с PHP, трудно реализовывать сложную бизнес логику.

Это было хорошо, честно :-)_

Comments

[Алексей Сумин]

То есть такой проблемы нет ?

[beduin01]

Алексей Сумин: все отлично просто! На каждый чих придется тонны говнокода писать)

Answer 2

[Александр Аксентьев]

2) Язык бедноват по сравнению с PHP, трудно реализовывать сложную бизнес логику.

он более низкоуровневый, а не бедноватый. Бедновата стандартная библиотека, но сделать на нем намного больше можно чем на php.

В PHP придется тащить сразу всю связку PHP-FPM + NGINX

в любом смотряшем в сеть демоне надо ставить nginx, какие-нибудь haproxy и всё такое.
Нельзя просто так взять и повесить демон слушать все что ему пришло. Нельзя просто так сделать балансировку на несколько серверов, ну и т.д.
Nginx получше это умеет и для этого сделан.
Так что если не не собираетесь ставить nginx перед сайтом на go, то очень зря.

3) Производительность и экономное расходование ресурсов.

это на 99% зависит от кода, а не от языка программирвоания.

Ставить php софт никто не будет пакетом, это бессмысленно.
Для этого есть композер, гитхаб и т.д.

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

В итоге установка для не очень умного пользователя в обоих случаях довольно геморна.

Comments

[RidgeA]

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

Ни кто не запрещает делать собственную репу

[Александр Аксентьев]

RidgeA:

устанавливаться на стороне пользователя наипростейшим путем

я ж говорю это уже гемор для тех кто не шарит

[Алексей Сумин]

Для GO вроде бы доступна кросс-компиляция без заведения билд-фермы? Т.е. можно предлагать скачивать готовый исполняемый файл.

[Александр Аксентьев]

Алексей Сумин: да, есть такое, так что можно

[beduin01]

Нет, он именно бедный. Синтаксис отсталый и примитивный. Вот вам хороший пример.

Answer 3

[Александр Новиков]

Обойти указанные вами проблемы с PHP можно, если распространять его в докере. Тогда все зависимости, связки и фоновые процессы будут инкапсулированы, а запуск при верном Dockerfile сведется к одной команде.

Answer 4

[Philipp]

Язык никак не влияет на развертывание приложения. Влияют зависимости.
Например, если вы собираетесь создавать Debian-пакет, то вам так или иначе прийдется прописать зависимости от других пакетов. Если какой-то пакет уже установлен, то нет никаких проблем.

Прописывание в крон или создание vhost для Nginx задачи тривиального характера и не должны вас смущать. Это стандартные вещи, как и настройка ротации логов или синхронизация времени на сервере.

Как и Go, PHP тоже можно собрать в один файл. Например так работает Composer.

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

Answer 5

[Alexander Kramov]

Go, Node.js, Rust, C#, да что угодно подходит больше для этой задачи, чем PHP.

Answer 6

[g00dv1n]

PHP + Laravel = profit

Answer 7

[Никита]

Никак не влияет.
Пишите на Fortran.

Answer 8

[beduin01]

Go не простоват, он примитивен. Это фактически обрубок языка. Все наработки в области построения языков создатели Go не осилили и создали что-то тупорное и примитивное. Естественно на проектах сложнее Hello World вам придется дико велосипедить т.к. во взрослых языках программирования все эти вопросы давно решили.

Comments

[devalone]

кто-то не осилил Go?

[beduin01]

̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻ ҉, скорее разработчики Go не осилили Go. В итоге Basic 2.0 получился.

[devalone]

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

[beduin01]

̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻ ҉, смысл осиливать язык с таким ущербным синтаксисом?

[devalone]

beduin01, т.е. признаёшь, что не осилил.

[beduin01]

̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻ ҉, смысл осиливать язык у которого единственное преимущество - маркетинговое?

[devalone]

beduin01, ну не осиливай

[stratosmi]

beduin01,

Естественно на проектах сложнее Hello World

Ну да, Dropbox и Kubernetes - чуть посложнее Hello, World, это да.