Насколько Golang подходит для больших проектов?

Question

[turbolizard]

Доброго дня, коллеги.
Много читал про плюсы и общие цели этого замечательного языка, работу с сетью и системную направленность, но сейчас хочу обратиться непосредственно к адептам: насколько уместно использовать Go в большом кровавом энтерпрайзе-монолите на миллион строк кода со всякими REST, кэшами, работой с базой и так далее? Понятное дело, что для микросервисов язык подходит как нельзя кстати, однако интересен практический опыт стартапного плана, возможные подводные камни и недостатки.

Answer 1

[Иван Шумов]

У go одно применение - highly network intensive applications. GRPC, protobuf, триллионы rpc вызовов в секнду. Применяется он когда есть или сразу подобные требования или бизнес вырос до этого уровня.

Для стартапов чаще всего требуются Rapid Applcation Development фреймворки. Язык при этом скорее вторичен. Можешь быстро слепить - молодец. Но чаще выбирать приходится из того что знаешь.

В кровавом Энтерпрайзе в основном правит старичок Java (за редким исключением) по тому что есть требования к заменяемости сотрудников и большой легаси ландшафт проектов, которые переписывать никто не будет

Comments

[turbolizard]

Очень ёмко, спасибо!

Answer 2

[Станислав Бодро́в]

Насколько Golang подходит для больших проектов?

У него это на генетическом уровне. Один из его создателей уже имел опыт создания крайне успешного языка программирования, который пошёл довольно хорошо в крупные проекты. И ещё в создании операционной системы поучаствовал. Как раз на это языке. Очень успешная ОСь получилась.

насколько уместно использовать Go в большом кровавом энтерпрайзе-монолите на миллион строк кода со всякими REST, кэшами, работой с базой и так далее?

У него изначально архитектурно заложено быть в лютом кровавом энтерпрайзе и даже в монолите на туеву гору строк кода. Любая СУБД по сути монолит. И на Go наверное с десяток наберётся довольно успешных баз, которые применяются в энтерпрайзе.

Понятное дело, что для микросервисов язык подходит как нельзя кстати

Микросервисы это методология разработки для больших, часто разрозненных проектов. И по большому счёту индиффирентно на каком ЯП будет сверстан микросервис. Хоть на ассемблере, если это оправдано. Обычно микросервисы это про несколько ЯП на проект.

однако интересен практический опыт стартапного плана, возможные подводные камни и недостатки.

Как бы для стартапа не рекомендуется микросервисы прям сразу. Его бы хотя бы оживить и заставить как задумывалось работать. А потом уже переходить к микросервисам. Но это отступление. Беда может выползти из прошлых навыком и знаний. Golang реализует свою модель ООП, которая не совсем понятная для тех кто писал на ООП ориентированных языках (Java, Python. PHP). Очень туго приходится после языков с динамической типизацией. Модель параллельного программирования тоже многим не сразу даётся.

Comments

[turbolizard]

Примерами успешных больших проектов на голом Go поделитесь? Имеется в виду полноценные сервисы, а не системна консольщина.

[Ромзес Панагиотис]

turbolizard, гляньте тут: https://github.com/avelino/awesome-go

[GK566]

turbolizard, AdGuard Home есть на Go. Работает у меня такой на роутере Keenetic (платформа mipsle) с установленным Entware. Считаю, что достаточно серьезный проект.

[Станислав Бодро́в]

turbolizard, Kubernetes - вполне, крайне вполне полноценный сервис.
База данных CockroachDB, стэк сервисов для мониторинга TIG и тот же Prometheus c кучей экспортёров сюда же. Это из того что на слуху или постоянно под рукой.
Кстати, постоянно под рукой и многие другие продукты этой компании.

Answer 3

[Everything_is_not_so_bad]

Go часто используется как язык, на котором строят программы для оптимизации узких в плане ограничения ЦПУ / памяти мест в больших проектах. Нередко его выбирают, когда основная часть кода написана на языках с динамической типизацией и, при этом, все работает медленно и потребляет много памяти. Проще выбрать "быстрый" язык, который одним махом решит проблему и поэтому мало кто желает вкладывать силы в реструктуризацию и поиск проблемных мест в проекте.
Так что, перед использованием Go я бы предложил для начала убедиться, что из используемой вами технологии вы уже выжали все возможное. Возможно, достаточно переосмыслить подход в построении проекта, переписать проблемные части с нуля.
Хотел бы еще добавить, что по сравнению с тем же Ruby писанины кода куда больше. Чисто по ощущениям, раз в 3-5. Бизнес логика описывается в Go не так компактно, как в Ruby.

Answer 4

[alfss]

Если это не бизнес логика с кучей условий и вычислений, то отлично подходит.
В противном случае это ад.

Comments

[turbolizard]

И бизнес логика в том числе.

[alfss]

turbolizard, не понимаю вашего комментария.

[turbolizard]

alfss, имелось в виду, что бизнес логика является неотъемлемой частью проекта, поэтому да, куча условий обязательно будет присутствовать. А не подскажете, что именно адом оказалось?

[alfss]

turbolizard, код и навигация по нему.

[Everything_is_not_so_bad]

alfss, а это точно свойственно языку или все же конкретному проекту?