@leston

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

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

Плюсы:
  1. Строгая типизация
  2. Результат компиляции - один бинарь
  3. Довольно интересный проброс ошибок (многим не нравится, мне понравился)
  4. Высокая скорость
  5. Низкое потребление памяти
  6. Есть потоки
Ответ написан
Delgus
@Delgus
Я только один раз слышал что "бизнес-логику нельзя писать на Go, вы же умрете". Я подошел и спросил этого человека, как много он писал на Go. Он ответил - "ну писал как-то месяца 2( ". Смотрите кого вы слушаете, а то повесят лапши на уши)

Вы не найдете человека который 10 лет пишет на Go. А только время покажет хорош ли Go на самом деле. Google же пилят на нем много всяких сервисов и не жалуются. Думаете у Гугла легкая бизнес-логика)))

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

А если вы пилите стартап то PHP c фреймворками вам в помощь.

За Java и C# не знаю - нет опыта)
Ответ написан
@rustler2000
погромист сикраш
Нет
Ответ написан
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
Так больше Go ни для чего не подходит.
Ответ написан
Всё зависит от разработчика. Можно использовать Go, при этом большую часть бизнес логики реализовать в SQL запросах например.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы