LINUX.ORG.RU

Стек технологий бекэнд разработки на Go

 , , ,


0

3

А расскажите мне Goты, какой у вас стек технологий, которые вы используете в типичном бекэнд проекте на Go?

Судя по статистике от JetBrains самым популярным фреймворком у вас является Gin. А где же IoC и прочие аналоги того, что есть в Spring Boot?

Возможно, мой последний вопрос не вполне корректный и неправильно искать прямые аналоги того, что есть в Java в Go. Мне просто хочется понять специфику бекэнд разработки на Go и её отличия от таковой на Java.


Необходимость в Spring Boot существует из-за скудных возможностей Java как языка. В других языках оно нафиг не сдалось

slyjoeh ★★★
()
Ответ на: комментарий от hummer

На голой Java никто не пишет. Потому, что стандартную библиотеку проектировали в 00-ом году, с тех пор много воды утекло… и в моде всякие Node.js, асинхронность, миросервисы, быстрый старт бекенда и его смерть, вот это вот всё…

Java в энтерпрайзе с кучей легаси лапши, в которой пишут на монстрах, где абстрактные фабрики на других абстрактных вещах верхом сидят. Сравни тот же Netty, где нет вменяемой документации и Node.js, где все кишки на C,C++ + js и всё летает, комплируется JIT на лету и стартует с полпинка, а в Go всё основное для сети есть в стандартной библиотеке и всё удобно и быстро, только сам язык, конечно, оставляет желать лучшего

menangen ★★★★★
()
Ответ на: комментарий от menangen

Я просил подробности про Go, а не про Java.

hummer
() автор топика
Ответ на: комментарий от rupert

Вроде бы готы и гопники уже давно вымерли лет так 10 назад не?

bhfq ★★★★★
()

Твоя страница «статистики» попахивает результатом работы телеметрии в IDE.

bhfq ★★★★★
()
Ответ на: комментарий от slyjoeh

из-за скудных возможностей Java как языка

Go, как язык, имеет гораздо больше возможностей, без сомнения!

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от slyjoeh

Необходимость в Spring Boot существует из-за скудных возможностей Java как языка. В других языках оно нафиг не сдалось

Ахахахаа, ржали всем офисом! Ну давай, рассказывай, какие киллер фичи есть в Go, которые позволяют быстро писать бекэнд без фреймворков и при этом это не будет похоже на говно?

ilinsky ★★★★★
()
Последнее исправление: ilinsky (всего исправлений: 1)
Ответ на: комментарий от ilinsky

Как киллер фичи влияют на количество говнокода? Тут в первую очередь влияет квалификация разработчика

slyjoeh ★★★
()
Ответ на: комментарий от slyjoeh

Причём тут квалификация? Spring Boot позволяет несколькими аннотациями и интерфейсами реализовать то, что в случае написания вручную вылилось бы в большой объём бойлерплейт кода. Это называется декларативным программированием, у которого есть как плюсы, так и минусы, но при решении стандартных задач этот подход позволяет быть очень продуктивным. Проблемы начинаются как только требуется реализовать нечто нестандартное. А как с этим в Go?

hummer
() автор топика
Ответ на: комментарий от menangen

Потому, что стандартную библиотеку проектировали в 00-ом году

в моде всякие Node.js

Где стандартной библиотеки нет вовсе. Некоторые люди рождены, чтобы жрать пропаганду полной ложкой.

anonymous
()
Ответ на: комментарий от slyjoeh

Необходимость в Spring Boot существует из-за скудных возможностей Java как языка. В других языках оно нафиг не сдалось

Если в Java «скудные возможности как языка», как можно охарактеризовать лабу Пайка, коим является Go?

anonymous
()
Ответ на: комментарий от slyjoeh

Расскажи подробнее, почему я из тебя всё вытягивать должен?

hummer
() автор топика
Ответ на: комментарий от anonymous

Чем тебе не стандартная библиотека?

https://nodejs.org/api/dns.html

Надо учитывать, что нода - фреймворк, и я это понимаю. Поэтому корректно сравнивать с Netty, к примеру, который гораздо более жирный, но для java мирка это нормально

menangen ★★★★★
()
Ответ на: комментарий от hummer

Как бы то, что для применения этого «декларативного» программирования пришлось использовать XML вместо языка само по себе намекает на ущербность последнего.

ei-grad ★★★★★
()
Ответ на: комментарий от hummer

В Go при применении декларативного программирования продолжают писать на Go. Yaml / toml / hcl и распределенные системы динамического управления параметрами в runtime - это всё больше для конфигов и конечных пользователей. Когда статически собранный бинарник не хочется модифицировать.

В java это «декларативное» программирование втащили в кишки тех самых фреймворков, потому что вместо статически собранного бинарника (или микросервиса) там jar’ники и монолит.

ei-grad ★★★★★
()
Последнее исправление: ei-grad (всего исправлений: 1)
Ответ на: комментарий от hummer

От boilerplate не всегда удается красиво избавиться, но в целом в Go с этим строже, но при этом проще и приятнее.

ei-grad ★★★★★
()
Ответ на: комментарий от ei-grad

Как бы то, что для применения этого «декларативного» программирования пришлось использовать XML вместо языка само по себе намекает на ущербность последнего.

О каком XML ты вообще говоришь? В Spring уже давно живут без XML.

hummer
() автор топика
Ответ на: комментарий от ei-grad

В Go при применении декларативного программирования продолжают писать на Go.

Можно примеры?

hummer
() автор топика
Ответ на: комментарий от ei-grad

От boilerplate не всегда удается красиво избавиться, но в целом в Go с этим строже

Go - это на 90% boilerplate. О какой строгости речь?

anonymous
()
Ответ на: комментарий от hummer

В Go при применении декларативного программирования продолжают писать на Go.

Можно примеры?

Да гонит он. Какое декларативное программирование на Go? Только если через кастомные кодогенераторы (вершина инженерной мысли - «//go:generate») или reflect, который для ГОферастов как слово на букву N для SJW. Он хотел сказать, что декларативного программирования в Go нет*, поэтому оно не нужно (стандартная логика в их сообществе, глянь на количество постов о том, почему «дженерики не нужны»).

  • Кроме стандартного метода парсинга/энкодинга JSON/XML, который настолько ущербный, что его выбрасывают на помойку, когда нужно обрабатывать что-то сложнее пары полей.
anonymous
()
Ответ на: комментарий от ilinsky

На go для web api никакие фреймворки не нужны. Все есть в языке по дефолту. Что смешного?

untitl3d
()
Ответ на: комментарий от fernandos

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpcore.html

https://github.com/anjmao/netcore-vs-golang

https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zijocd-f

https://developer.51cto.com/art/202011/630459.htm

also cast @WitcherGeralt @hummer

языки очень разные, против друг друга обычно не выставляются, но вот что нагуглил по фасту

я не настоящий .net-прогер, но вообще можем и сами взять микрозадачу и написать бенч :)

раньше гуглил - ява тоже быстрее была, а теперь +/- паритет или даже луз, прогресс?

Ford_Focus ★★★★★
()
Последнее исправление: Ford_Focus (всего исправлений: 3)
Ответ на: комментарий от Ford_Focus

Не я, джаву имел ввиду. В том жк benchmarks-game Go в большинстве тестов впереди. На techempower очевидное сравнение — Gin vs. Spring — разница на лицо, а всё остальное сложно сравнивать, ибо в той или иной степени кастрированное, либо вовсе под бенчмарки заточенное.

На benchmarks-game результаты всратые, лучше смотреть сюда: https://programming-language-benchmarks.vercel.app/go-vs-java

Шарпы я знаю, что быстрые, но мне эта виндовая срань не интересна в принципе. К тому же тут результаты неоднозначные: https://programming-language-benchmarks.vercel.app/go-vs-csharp

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от Ford_Focus

Я просто помню когда-то сравнивали голанг с пхп на уровне одной хеш-функции, в итоге пхп, конечно, победил просто потому, что эта функция была реализована на с в ядре.

Ну и на своём сайте пишут про бенчмарки.

fernandos ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.