Слышал, что go не очень подходит для написания сервисов с большим количеством бизнес логики, какое мнение у вас?

Question

[leston]

Очень хочется услышать развернутый ответ, почему go не подходит/подходит в данной ситуации.

Answer 1

[Александр Павлюк]

Потому что go довольно низкоуровневый язык с минимумом абстракций и отсутствием дженериков.

Comments

[leston]

Насчет низкоуровневости не совсем согласен, чем он низкоуровневее чем та же java например?
Отсутствие дженериков кажется, действительно, неудобным.

[Александр Павлюк]

Тем, что в отличие от джавы выполняется не на виртуальной машине и работает с настоящими указателями, например

Answer 2

[Владимир Коротенко]

Может быть

Comments

[leston]

Очень хочется услышать развернутый ответ

[Владимир Коротенко]

leston, Сравнивайте сложность сервиса, время разработки и знание языка.
В конце концов получите ответ

Answer 3

[Дмитрий Свиридов]

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

1. В большинстве микросервисов бывают довольно простые запросы к базе данных и удобно было бы использовать что-то вроде Doctrine или SQLalchemy. В go, к сожалению, инструментов такого уровня нет. Gorm лично мне не понравился совершенно.
   
2. Недавно была необходимость запилить сервис, взаимодействующий со Sphinx, но нормальных библиотек для Go для этой задачи внезапно не оказалось. Есть вот такая, но она устарела (еще не позволяет ее нормально юзать в несколько потоков). Неустаревшей и нормальной библиотеки вообще нет. Либо я плохо искал.
   
3. Сложно сделать нормальную структуру проекта, чтобы не было циклических зависимостей. По крайней мере, вскоре начинает не покидать ощущение, что пишешь какой-то код низкого качества. Хотя может это субъективно или проходит с опытом.
   
4. Если не запилить что-то типа контейнера зависимостей, то покрывать тестами проект становится неудобно, т.к. тесты при запуске в параллель начинают юзать одни и те же глобальные переменные. Опять-таки может и это субъективно.
   
5. Во фреймворке gin/gonic сложно запилить нормальную валидацию для json. Если в структуре, на которую маппишь, поле типа int, а ты передал в json число в кавычках (строку вместо числа по сути), то поймать такую ошибку и выдать нормальную ошибку валидации невозможно, т.к. валидация там (в этом фреймворке) запускается после маппинга.
   

Плюсы:

1. Строгая типизация
   
2. Результат компиляции - один бинарь
   
3. Довольно интересный проброс ошибок (многим не нравится, мне понравился)
   
4. Высокая скорость
   
5. Низкое потребление памяти
   
6. Есть потоки
   

Comments

[di]

Недостатки:
1. в большинстве микросервисов простые запросы? я вам завидую)))
2. вот здесь согласен, ну что поделать, язык молодой и не такой популярный)
3. для сложных сервисов используйте hexagonal architecture.
4. глобальные переменные - зло.
5. не передавайте в json число в кавычках)

[Дмитрий Свиридов]

Alex, не совсем правильно выразился насчет первого пункта) Конечно, я имел в виду, что в любом микросервисе, как ни крути, будет достаточно большой процент простых запросов, которые крутить через ORM-ку было бы удобно.
3 - спасибо, учту
4 - ну так инициализирую сервис, допустим, в пакете - пишу его адрес в переменную. Где ее хранить?
5 - а вы пользователям API это скажите. Одно дело, когда API какое-то внутриконторное - это ладно, но API бывает и публичным. И такое себе, если оно крашится на таких вещах.

[Дмитрий Свиридов]

pygame,
1. Там, где хайлоад и производительность, там не только ORM нет, но и запросов в базу практически не делается, т.к. данные, в основном, берут из кеша, а в базу ходят редко (когда кеш протух). Чтобы заполнить кеш, можно раз в N минут ORMкой в базу сходить - обычно это не проблема. К тому же в любом проекте бывает все равно достаточно много простых запросов. ORM - это ведь не только тяжелый квери-билдер. Например, пилить самостоятельно гидраторы и т.п. не сказал бы, что удобно. Вот делаешь join-запрос нескольких таблиц 1-1, например - и чего, руками на структуры маппить? А в java, где нужна производительность, Hubernate, кстати, не юзают разве?
2. Так и есть, но есть легаси проекты, которые все равно поддерживают, делят на сервисы, переписывают и т.п. Если был там исторически Сфинкс, то не всегда есть реальная возможность его поменять на, скажем, Эластик. Как будто Вы сами с таким никогда не сталкивались)
3. Вполне вероятно, я потому и уточнил, что это субъективно.
4. Так, собственно, и делаю.
5.

Привыкайте к строготипизированным языкам.

То есть это так везде? В java-проектах тоже такая проблема имеется? За jsoniter спасибо - погляжу.

Answer 4

[Дмитрий Шицков]

Да

Comments

[leston]

Очень хочется услышать развернутый ответ,

Answer 5

[rustler2000]

Нет

Comments

[leston]

Очень хочется услышать развернутый ответ,

Answer 6

[uvelichitel]

Так больше Go ни для чего не подходит.

Answer 7

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

Всё зависит от разработчика. Можно использовать Go, при этом большую часть бизнес логики реализовать в SQL запросах например.