Golang в крупных проектах возможен (back)?

Встречал мнение, что этот язык плохо для этого подходит.

Это всё злые языки, т.е. хейтеры. Собственно, а чего он не подходит то? Кто-то с того же php, переписывает на Go. Хоть на микросервисы, хоть нет. В интерпрайзе уже давно им обмазываются и тоже норм.

Ну мы знаем довольно крупный проект написаный в основном на Си. Фреймворков уровня Laravel/Spring я на сях не знаю (может есть?). ООП тоже, кстати, нет.

Linux Kernel?

Вообще для задач ближе к железу как оказалось не нужно ООП?

Энтерпрайз только на Golang и сидит (и вообще на Modula-2 based).

сотни и тысячи энторпрайзных оперденей на гo эвривеа

ООП срачи в 2025м совершенно бессмысленны ибо каждый вкладывает в это понятие то, что считает нужным. Скажите шёпотом на пустом стадионе «ООП», и менедленно откуда-то появится фриковато выглядящий гражданин, который будет закатывая глаза и тыча пальцем в небо вспоминать какого-то Алана Кея, какой-то смоллтолк и какие-то сообщения. Тут же непонятно откуда материализуется чувак с чашкой кофе и заголосит, что ООП - это Наследование + Инкапсуляция + Полиморфизм. У него из-за спины выползет дядя в бороде Столлмана и поведает, что ООП можно готовить хоть на ассемблере, и правильные пацаны только так его готовят, ну на крайняк на си. И вообще, вот вам ГТК и скажите, что он не ООП. На всё это помалкивая в сторонке будет взирать группка подростков, которые не вдуплят о чем речь, потому что всю жизнь считали, что самый передовой ООП это джаваскипт.

В любом нормальном языке есть та или иная идея организации маленьких кусочков кода в большую программу. И совершенно неважно, это ООП или ПЖМТ и ХБСТВ. Нравится язык - бери и кодь.

Go в крупных проектах возможен. Бизнес-логику на Go писать можно. Язык для этого хорошо подходит. Фреймворки в Go использовать не принято, принято использовать стандартную библиотеку. Отсутствие ООП не мешает его юзать. Можно обойтись текущими средствами Go.

Пожалуй единственный нюанс, который омрачает написание кода на Go это необходимость после каждой строчки добавлять

if err != nil {
  return fmt.Errorf("Couldn't do something: %w", err);
}

Но это не настолько большая проблема, чтобы от него отказываться.

Некоторые идеи ООП используются во многих проектах на C, включая Linux Kernel.

struct super_operations {
        struct inode *(*alloc_inode)(struct super_block *sb);
        void (*destroy_inode)(struct inode *);

        void (*dirty_inode) (struct inode *, int flags);
        int (*write_inode) (struct inode *, int);
        void (*drop_inode) (struct inode *);
        void (*delete_inode) (struct inode *);
        void (*put_super) (struct super_block *);
        int (*sync_fs)(struct super_block *sb, int wait);
        int (*freeze_fs) (struct super_block *);
        int (*unfreeze_fs) (struct super_block *);
        int (*statfs) (struct dentry *, struct kstatfs *);
        int (*remount_fs) (struct super_block *, int *, char *);
        void (*clear_inode) (struct inode *);
        void (*umount_begin) (struct super_block *);

        int (*show_options)(struct seq_file *, struct dentry *);

        ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
        ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
        int (*nr_cached_objects)(struct super_block *);
        void (*free_cached_objects)(struct super_block *, int);
};

Вот кусок из ядра какой-то версии. Очень напоминает interface из Java.

Видел топик на первой странице

Озон-банк сделан на гошке.

Встречал мнение, что этот язык плохо для этого подходит.

Враньё.

Там нет фреймворков уровня Laravel/Spring?

Есть, но со своей спецификой.

Отсутствие привычного ООП мешает его юзать?

Нет.

Нельзя обойтись текущими средствами Go?

Смотря что имеется ввиду под «текущим». Если стдлиб, то возможно, хотя не всегда. Если всей опенсорцной экосистемой, то можно.

В enterprise например

b2b проект на ~400k loc сойдёт?

ТLaravel/Spring [..] Отсутствие привычного ООП

Нафик не сдалось.

ваши коннекторы и прочия шляпа смысл которой в перекладывании пакетиков это не энторпрайз

Озон-банк сделан на гошке.

круды

а вся бизнес логика в базе.

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

Если мне нравится способ обработки ошибок в го, то со мной же все хорошо?

Я и вправду считаю такой способ удобнее, минималистичнее

В enterprise например, да и вообще где нужно много бизнес-логики? Встречал мнение, что этот язык плохо для этого подходит

Вес, тырпрайз сейчас как раз на гошку перелазит. С жабы и прочего шарпа. Крупные интерент компании еще лет 5 назад полностью перелезли. Потому-что быстро, дешево, просто, и при этом работает хорошо. Задродские старадания вроде ООП-а бизнесам никогда интересны не были.

Трудно охарактеризовать микросервисы как «круды с бизнес-логикой в базе». На таком масштабе круды - это уже бизнес-логика.

Если мне нравится способ обработки ошибок в го, то со мной же все хорошо?

Кто-то скажет «нет», кто-то скажет «да». Думай за себя. Важно понимать механизмы, связанные с гошным стилем обработки ошибки. И исключениями, если хочешь их критиковать.

В целом, мне лично нравится упрощённый control-flow, это ценное достижение относительно увеличенной многословности (if err != nil), хотя лично я не застал проекты, в которых исключения слишком сильно его усложняли.

b2b проект на ~400k loc сойдёт?

Какой адрес репозитория?

Иш, каков! Может тебе ещё и пин от счёта, где деньги лежат? ;)

ЗЫ: 400k – это без комментариев и пустых строк.

голанг вообще мало к чему подходит. им увлечение это не его достоинства, а скорее пороки конкурентов.

ну и вера, что тулзы с низким порогом вхождения, спасут гигантов мысли от говнокода. что как раз наоборот - чем проще стать разрабом, приходя с улицы, тем больше говнокода вам обеспечено.

kubernetes - это достаточно крупный проект? Или, может, это не достаточно back?

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

Всё это уже проходили с похапе, нет снова давай на грабли прыгать. Необучаемые. Хотя теперь же можно ИИ прикрутить к канпелятору, чтобы сразу говнокод рефакторил. Так что не всё пропало!

400k – это без комментариев и пустых строк

Из которых половина это тупорылое протягивание ошибок через весь стек. Вообще для набивания LOC этот недоязычок очень хорош.

Go не просто подходит для энтерпрайза, он для него изначально создан.

Максимально дубовый синтаксис, в котором можно сделать то что тебе надо строго одним способом, чтобы у джуна не было шанса навертеть нечитаемого говнокода. Туда же встроенные гайдлайны (форматирование из коробки, неиспользуемая переменная - ошибка, регистр названий методов имеет значение). Статическое компиляние всего в один файл, чтобы не было проблем на сервере при апгрейде какого-нибудь пакета. Встроенные корутины для микросервисов. Сборка мусора - сразу видна ориентация на бизнес-логику, где не так важно выжать последний такт производительности. Куча прикладного добра в стандартной библиотеке, чтобы не возиться с зависимостями. И т.д. и т.п.

тут уже много написали про его массовое использование в крупных проектах. скажу лишь за фреймворки - есть вялые попытки запилить аналоги django/laravel и прочие спринги, но зачастую все используют стандартную либу с пачкой внешних обвесов в виде gin/grpc.

за свой фреимворк (ergo framework) скажу, что он не про очередной велосипед в мире веб разработки. это про акторную модель и всякий distributed с сетевой прозрачностью. он для больших компаний подходит (собственно, там и применяется). мелкому и среднему бизнесу обычно слихвой хватает того, что дает го из коробки.

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

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

Мое ощущение от Go такое, что писать идеоматический код сложней чем на той же Java. Нужно больше усилий вкладывать в дизайн и архитектуру. Например, в Go нужно продумывать типы ошибок, где в Java можно просто кинуть runtime исключение в любом месте и как-то в логе оно да появится. Требуется больше дисциплины.

Там есть ооп, очень своеобразное. Он скорее для микросервисов, переписания чего-то критического с java, php, python или nodejs

бред. код на любом языке, написанный математиком, не читаем

корутины. горутины отличаются от питоновских очень сильно. в нем нет низкоуровневого разделения на потоки и треды, это все само управляется, поэтому язык не подходит для создания игр и gui-приложений. это интырпрайз или им считается только ява-дрисьня с покрытием 666% и тестами ради тестов?

где в Java можно просто кинуть runtime исключение в любом месте и как-то в логе оно да появится.

Ага появится. Хватит уже наразбирались с этой фигней :( В логе то есть а кто и когда это сотворил фиг разберешься :(

как можно переписать с максимально оопэшной жавки на голанг? есть успехи?

там наследование так выглядит:

type Foo struct {}

type Bar struct {
  Foo
}

Инкапсуляция сама собой есть как и публичные (с большой) и приватные поля (с маленькой). Нет ORM как в питон и трай/кеча, последнее вроде как жирный минус, если привык исключения не перехватывать, надеясь, что где-то, кто-то все перехватит. Если ты писал все «правильно», то разницы особой и нет, если как все, то язык жутко неудобный

там наследование так выглядит

серьёзно? То есть Foo является базовым типом для Bar и переменная типа Bar может использоваться в любом вызове ожидающем Foo?

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

Если хочется программировать по книжкам для джавы и на собесах спрашивать SOLID, то просто бери джаву.

нечитаемого говнокода

https://github.com/go-pg/pg/blob/v10/listener.go - вам вот с первого раза понятно, что там они навертели вокруг NOTIFY/LISTEN ? Все гошники такое по 10 раз в день пишут?

вам вот с первого раза понятно

по ссылке вполне понятный код

Конечно подходит, он для этого и создан.

Ага появится. Хватит уже наразбирались с этой фигней :( В логе то есть а кто и когда это сотворил фиг разберешься :(

Хм. Регулярно разбираю такие ситуации и практически всегда видно причину (условный NPE). Да, может не хватить дефолтной глубины stack trace, но это можно настроить.

Это просто структура с указателями, для логической организации разрешённых вызовов. Зачем ты сюда ООП приплёл да ещё назвал это заимствованием идей из ООП непонятно. Если оно на что и похоже, то лишь синтаксически. Единственное в чём ты прав, ООП или его часть можно реализовать как и где угодно по мере надобности. Но факт в том что не из ООП берутся идеи, это ООП просто сборник того что уже было. Но кое-кто сделал финт ушами, взять кучку готовых практик, собрать их вместе и сказать что они специально придуманы, все неразрывно связаны и так задумано назвать это по своему, а потом показывать пальцем на всех где есть что угодно похожее и говорить, «а вот смотрите, а вот тут они позаимствовали наши ООП идеи и подходы»

Господи, да скоро увидя вызов функции будет говорить что это идея из ООП по вызову методов. А неявное приведение типа будут называть идеей вызова конструктора приведения типа и так далее. ООП шники успокойтесь. Пажавуста :)

Пожалуй единственный нюанс

Не только.

Я к Go даже прикасаться не хочу, пока они не сделают декораторы как в Python.

Я посмотрел на декораторы в Go и ужаснулся.

А они довольно часто в вебе используются.

не подходит для создания игр и gui-приложений

Последние же как-то делают.

говнокод обыкновенный :). но главное - читабельный и понятный.

А они довольно часто в вебе используются.

это в питоне. в го они не нужны ибо подобная вещь делается через лямбду. да и невозможны питоновские декораторы в го из-за строгой типизации.

а вся бизнес логика в базе

Если можно что-то переложить на СУБД, надо перекладывать это на СУБД.

Давай сразу прогеров на асме искать - эти смогут.

400k – это без комментариев и пустых строк.

400 K SLOC, на которые нельзя посмотреть, ничем не отличаются от 100500 K SLOC или 0 SLOC. Это не пойми что в не пойми каком виде, которое не может ответить на вопрос «Golang в крупных проектах возможен (back)?».

То есть Foo является базовым типом для Bar и переменная типа Bar может использоваться в любом вызове ожидающем Foo?

Нет, вообще-то, поскольку есть такая штука

 type IBaz interface {
doSometing()
}

Тогда если Foo и Bar реализуют метод из интерфейса, то пожалуйста.

Писать лажу можно на любом языке. Качественный код и продукт можно на любом популярном языке, причём в последнем случае решает обычно не столько язык, сколько культура кода и умение его организовывать.

Нет, вообще-то

ну значит это не наследование, а композиция