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

Расширение типа.

При чём вообще фреймворки к бизнес-логике. Фреймворки для придания структуры твоему приложению/сервису, для переиспользования типовых решений типовых рутинных задач. Бизнес-логика вообще не должна зависеть ни от какого фреймворка.

Извини, но IP. Не покажу.

И так полно больших проектов → https://blog.kowalczyk.info/article/9afe3485f2204f1bb43217d70f7b87d4/big-projects-written-in-go.html

И так полно больших проектов

И все они - технические решения. Компиляторы, интерпретаторы, веб-сервера, бд, схд и т.д. / т.п.

Речь (в оп-посте и этом треде) идёт о бизнес-решениях, т.е. решениях задач вне технической инфраструктуры. И последние лет 10 - 15 там вообще-то было модно тугосерить наносервисами, что будет прямой противоположностью крупному ынтырпрайзному монолиту.

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

Кто ж тебе коммерческую тайну то показывать будет? Нанимайся на работу и всё это увидишь.

У нас два десятка с гаком микро-монолитов. Немного обвязки в виде grpc и туева хуча бизнес-логики, от документо-оборота и до всяких api к sap. Никаих фреймворков. Всё стоковое или самописное.

Как микросервисы между собой коммуницируют, kafka? другой брокер?

Просто потому, что придется с нуля реализовывать весь этот ваш спринг.

Тут 2 подхода.

1. вляпятся в какой-нибудь комбайн и бороться с ним
2. реализовать суб-сет того, что конкретно надо тебе и спать спокойно

Тут кстати ещё один большой плюс Go: когда мы начинали был ещё go1.6. С тех про все изменения версии прошли без сучка и задоринки.

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

Кафку рассматривали, но отказались. К нему ещё трёх админов нанимать надо. Сервисы между собой через gRPC (исторически) и через доморощенный event-stream на основе Postgres общаются.

Мы вообще за 10 лет много чего выкинули на мороз. Один Postgres остался. У нас как раз 2-й подход. Лучше я нарисую свою маленькую либу под свои нужды, чем буду бодаться с third-party комбайном.

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

Пусть на асме ИИ пишет. Идея такая: набираем узбеков за доширак, даем им в лапы пхп (сабж сгодится), они корябают бездарный говнокод без всякого ревью и тестирования. Дальше ИИ исследует это наскальное творчество и выдает корректный ассемблерный код без единой лишней инструкции. Всё, дорогие пограмисты с дипломами больше не нужны. Тем более, что так оно сейчас примерно и происходит, только код на выходе мягко говоря не идеальный. Потому что компиляторы тупые пока что.

И последние лет 10 - 15 там вообще-то было модно тугосерить наносервисами, что будет прямой противоположностью крупному ынтырпрайзному монолиту.

Если речь всё ещё идёт о SLOC, то в микросервисах это число должно быть больше.

При чём вообще фреймворки к бизнес-логике.

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

Кратко суть вопроса: вот есть язык для мелких утилит и микросервисов, можно я буду на нем тырпрайз лабать? Ну можно, а чо такого. Флаг в руки! Даже история успеха есть от регистранта. Только придется сначала свой спринг написать, но кого это останавливает. Наоборот, так интереснее же.

а что там в вашем го с горутинами?

Они везде и всюду. Часто даже под капотом и незаметно. В частности каждый http запрос обрабатывается в своей go рутине, как для примера. Заработать deadlock ещё очень сильно постараться надо.

В enterprise например

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

Это странное мнение. Как раз для enterprise он и подходит хорошо. И создан не просто так именно гуглом.

Это не делает язык объективно «хорошим», впрочем. (Плохим тоже)

Это не наследование, а embedding. У них есть какие-то общие свойства, но разницы тоже много: главное — отсутствие полноценных виртуальных функций. Попав в базовый объект ты никак не вызовешь функцию наследника.

Как раз для enterprise он и подходит хорошо

Только надо уточнять для каких задач. Девопс? Да. Микросервисы для хайлоада? Да. Корпоративный бэкенд? Ну лол же.

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

Нет, гошники такое не пишут 10 раз в день, но код вполне понятный.

Более того, даже стандартная библиотека написана очень просто. Если какой-то нюанс не очевиден из документации, ты просто прыгаешь в реализацию и читаешь код. Это разительно отличается от C/C++ или Раста, например.

Какие претензии к расту?

ты просто прыгаешь в реализацию и читаешь код.

а потом, когда все сломалось и ты долго искал почему,… ты опять прыгаешь в реализацию,.. в там другой код. и некому предъявить претензии.

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

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

а проще(и правильней) всего вводить интерфейсы и механизм имплементации (со статическими проверками разумеется) его.

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

Попробуй найти вакансию в РФ на гошку, где людей берут с улицы. Скорее, наоборот чаще люди приходят с опытом работы на других языках.

Найди здесь хоть одно упоминание набора с улицы и адаптации языка специально под эту цель.

это называется гипербола.

утиная типизация. то есть еще один костыль

Представляю переписку разработчиков Гошки.

— Расс, ты знаешь как сделать статические интерфейсы?
— Нет. И не знаю зачем они нужны.
— Ну ладно, тогда делай как попало.

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

Утиная типизация позволяет плодить меньше сущностей (контракты, зависимости), писать более выразительный/короткий код. Это весело, в конце-концов. А описанная проблема о несоответствии контрактов встречается почти никогда, зато философы языков программирования хотят обязать абсолютно все языки переделать джаву.

Ну вот интересный пример: /bin/cat явно не указывает зависимость от NFS. И это фича, а не проблема.

Типа такого: https://github.com/go-spring-projects/go-spring

Хотя вроде такой фигни на go сотни …

Напомните мне пожалуйста как называется та штука на которую Fedora перешла за место githab и причем долго выбирали между всякой ерундой типа gitlab (где в основном не go а ruby) и т.д. ?

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

Прочитал как «сделан на горшке»... А сколько тому банку лет?

Вот кусок из ядра какой-то версии

VFS изобрели очень давно, ещё во времена BSD. Обычной, не free.

Весной 21 года Озон купил его у Совкомбанка. С какого года используется гошка — не знаю, но огромного легаси там нет.

Какие претензии к расту?

У меня свои претензии, т.к. я тоже с ним ковырялся, особенно в сравнении с Go.

1. Каждый кулик свой crait пилит. Одних только http клиентов пальцев считать не хватит. А если ещё и tsl нужен… В Go один.
2. Названия у всего, как у покемонов. Никогда не знашь, какой crait искать, и что он делает. В Go с этим проблем нет.
3. Документация отсутствует как класс. Точнее она есть, но в 90% пустая. В Go с этим проблем нет.
4. Отсутствие stdlib как класса. В Go с этим проблем нет.
5. Проапдейтится с версии на версию – всё валится. В Go проблем нет.
6. То, что можно было сделать автоматически, рулится в ручную. Наследие malloc/free никуда не делось. Оно просто теперь borrow-checker называется.
7. Жутко раздутый синтаксис. Там где в Go можно просто прокинуть interface в структуре, в rust это всё разрастается в много-экранные декларации генериков на методах. Которые повторяешь и повторяешь …
8. Наркоманские макросы.
9. Rust паникует в runtime just fine. Хвалёный memory safety только для запудривания.

index out of bounds: the len is 76800 but the index is 18446744073709551296

И это в коде без всяких unsafe.

TL;DR: в Go сел и пишешь, что тебе надо. В Rust – сначала *бёшься, потом ещё *бёшься и так всё время.

Forgejo

Точно.

https://v10.next.forgejo.org/

Чем мне нравится go, так у них полно проектов которые я использую и все работают круто, хз почему так.

docker, prometheus, grafana …

Что-то это напоминает:

«Банк фунционирует преимущественно как дистанционный онлайн-банк, хотя имеет один московский офис. Пункты выдачи Озон используются как дополнительные места обслуживания (места выдачи банковских карт, которые можно заказать на озоне за 1 рубль).» (С) где же тут подвох... ума не приложу. Напоминает одного торговца пельменями и пивом, который платиновые кредитки своего «тоже банка» в почтовые ящики подкидывал с книжками про свой успешный успех.

Ах да:

«Лицензия №3542 от 12 апреля 2023 года

Год основания 2022»

Совсем не удивительно что он «сделан на горш...» на гошке. Совсем не подозрительно. После ребрендинга все пахнет свежим... свежим и точка.

огромного легаси там нет

Огромного кредита доверия что характерно тоже.

Приходится с чего-то начинать.

Кто ж тебе коммерческую тайну то показывать будет?

Тогда мы от прямых свидетельств наличия слона переходим к попыткам определить его наличие по косвенным признакам и ощупываем всё свисающее на букву «х» - хоббот, хвост и остальное.

И тут картинка выглядит не так радужно. По жабе / дотнету все признаки ынтырпрайзности от руководств по включению компьютера до сертификации на специалиста по включению компьютера попёрли прямо сразу с релиза. А затем полезли глубокие философствования на тему object–relational impedance mismatch и фреймворки, пытающиеся решить эту проблему, наряду с шаблонизацией и прочем.

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

А вот по гошечке всех этих внешних косвенных признаков ынтырпрайзности не видно. У нас есть по хашикорпу с кубернетисом, полторы ORM, штуки три веб-серверов и 100500 пакетов уровня npm. Это всё пока что свидетельствует, что ынтырпрайзность у гошечки где-то в районе жабаскрипта.

Я был бы рад увидеть опровержения этой точки зрения.

Потому что в Go есть stdlib. Всякие ORM и фреймворки признак того, что stdlib языка полностью провалился. В них нет надобности в Go, батарейки уже есть.

Я не знаю, что такое декораторы. Зачем они нужны? Пишу веб без всяких декораторов.

Если читабельно и понятно, то это не говнокод, а жемчугокод.

А зачем эта «косвенная» ентерпрайзность нужна? Все эти фреймворки — скорее минус языка, чем плюс.

А толку от этого Энтерпрайза? В сертификатах что ли? Всяких спецификациях? И дальше что?

Вон замена gitlab работает на малинке а github/gitlab так могут?

А знаешь как масштабируется prometeus? Тысячи данных с тысяч компьютеров а все летает причем с полным отказом любой цепи. Вот это реальный энтерпрайз а не какие то там сертификаты.

Когда то в java сообразили что ее энтепрайзность (J2EE) это тупик и выкатили спринг.

Лучше бы не выкатывали.

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

Я тоже захотел посчитать, вышло 1300K (исключая генерируемый код, пустые строки и комментарии). Это только те проекты, которые я склонировал себе на ноут, а работаю я всего-лишь полгода.

Реальная проблема - как справится со всей этой кучей сервисов. Видимо, никак.

Реальная проблема - как справится со всей этой кучей сервисов. Видимо, никак.

Что значит «справиться»? Вы же как-то справляетесь, разве нет?

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

Так они в своем Энтерпрайзе (javaBeans) так запутались что даже сами уже не понимали как это работает а им (java программерам) хотелось какой то упрощенки типа RoR (рельсов) вот и обрадовались спрингу.

В них нет надобности в Go, батарейки уже есть.

Какой батарейкой из гошного stdlib мне замаппить поле структуры в колонку таблицы реляционной базы данных?

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

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

Если говорить про Java, то там сейчас из условно-популярных это Helidon SE. Условно - потому, что спринг и Java раздельно уже, видимо, никогда не будут писаться и всё остальное это жуткая минорщина, которую в проект затянуть прям проблема. И вообще у жавистов уже мозги набекрень, обгенерируются своего кода и эт самое.

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