Здравствуйте, Sinclair, Вы писали:

S>Всё это есть и на Go, и на TS/JS, и на C#.

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

Здравствуйте, Sheridan, Вы писали:

S>Это не микросервис будет, а говносервис. Ноду придумали для фронтендеров, которым лень изучать другой язык и которые "я художник я так вижу". Такое себе, короче.

В кои-то веки я с тобой согласен. JS — это диверсия против прогрессивного человечества. Зато ассемблер — наше всё.

Здравствуйте, ·, Вы писали:

·>В java есть jib. Пару строчек в mvn/gradle и всё собирается как надо — Очень быстро и эффективно по слоям.

Ну да. В 22 году умение Go работать в одном экзешнике особо не роляет. Все преимущества сводятся к простоте языка, типа на нем не написать замудренный код.

Для бэка выбор Go для меня неочевиден. Каких-то удобных ORM, к примеру, на Go нет. Очень похоже на какой-то хайп.

·>Преимущество js это можно ту же рабочую силу использовать для фронта и бека... но качество так себе.

Это частный случай фулстека, который умеет бэк на JS. Если принято решение разрабатывать фулстеками, то искать фулстеков умеющих ноду не проще чем на python/ruby/php. На java/.net чуть сложнее, так как динамика и статика дружат хуже.

Здравствуйте, scf, Вы писали:

scf>Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость.
А разве это не ещё одни микросервисы?

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Sinclair, Вы писали:

S>>Весь смысл микросервисов — в том, что нет одного языка, навязанного монолитом.
S>>Выбирайте тот язык, на котором вам комфортно писать.

scf>Это из продающего микросервисного рекламного буклета, реальность немного печальней. Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость. А это приличный объем кода, который никто портировать на n языков не будет.

Платформы языконезависимые, тот же docker и dapr не зависят от того, на чем написан микросервисы.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, scf, Вы писали:

scf>>Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость.
K>А разве это не ещё одни микросервисы?

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

Здравствуйте, Ziaw, Вы писали:

Z>Для бэка выбор Go для меня неочевиден. Каких-то удобных ORM, к примеру, на Go нет. Очень похоже на какой-то хайп.

Я смотрел в сторону Ent и Gorm, правда не пробовал их, они проигрывают ORM из java/c# ?

Здравствуйте, tnikolai, Вы писали:

T>Здравствуйте, Ziaw, Вы писали:

Z>>Для бэка выбор Go для меня неочевиден. Каких-то удобных ORM, к примеру, на Go нет. Очень похоже на какой-то хайп.

T>Я смотрел в сторону Ent и Gorm, правда не пробовал их, они проигрывают ORM из java/c# ?
Насчет java не знаю, но ORM из .NET проигрывают однозначно

Здравствуйте, Sheridan, Вы писали:

R>>

JS (Node.js) — как Python, только сильно современнее, динамичнее развивается и есть статическая типизация в виде TypeScript.
S>Это не микросервис будет, а говносервис. Ноду придумали для фронтендеров, которым лень изучать другой язык и которые "я художник я так вижу". Такое себе, короче.

Снова у тебя девелоперы виноваты. Нода обычно используется там, где достаточно простые задачи на бакенде. Таких приложений нынче вагон и маленькая тележка.
Как правило, джависты и дотнетчики (нужное вписать) не умеют во фронтенд, ну никак. Они только думают, что умеют. А вот когда на бакенде нужно писать много несложной логику, оказывается, что дешевле научить фронтеда мелкому бакенду, чем джависта или дотнетчика какому то внятному фронтенду.

То есть, чисто экономические основания. В таком случае команда фулстеков комплектуется как обойма, ну или как пожарная команда — все умеют всё. Это дает существенную гибкость и при этом обходится намного дешевле смешаной команды команды с джава-дотнет(нужное вписать) бакендом.

Здравствуйте, tnikolai, Вы писали:

T>Я смотрел в сторону Ent и Gorm, правда не пробовал их, они проигрывают ORM из java/c# ?

C# не имеет аналогов своего linq. Просто на голову выше всего остального, ничего подобного другие языки предложить не могут.

Gorm и Ent инспирированы рельсовым ActiveRecord и Criteria от java Hibernate соответственно. Первое, имхо, сложно сделать удобно в статически типизированном языке, второе скорее всего будет иметь большой синтаксический оверхед.

Здравствуйте, Sinclair, Вы писали:

S>Весь смысл микросервисов — в том, что нет одного языка, навязанного монолитом.
S>Выбирайте тот язык, на котором вам комфортно писать.
S>Может быть, даже несколько — для каждого микросервиса решаем вопрос отдельно.
S>Если решение было принято неудачно — ничего страшного; в микросервисе не так много кода, чтобы было жалко его выбросить и переписать на более другом языке.

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

Здравствуйте, Ziaw, Вы писали:

Z>·>В java есть jib. Пару строчек в mvn/gradle и всё собирается как надо — Очень быстро и эффективно по слоям.
Z>Ну да. В 22 году умение Go работать в одном экзешнике особо не роляет. Все преимущества сводятся к простоте языка, типа на нем не написать замудренный код.
Z>Для бэка выбор Go для меня неочевиден. Каких-то удобных ORM, к примеру, на Go нет. Очень похоже на какой-то хайп.

Дело не сколько в простоте языка, сколько в общей идеологии, которая находит свое отражение не только собственно в языке, но и в комьюнити, общепринятых практиках, библиотеках, тулинге и пр. Go — это про принцип KISS, про то, что всё должно быть максимально просто, явно и очевидно и вся экосистема GO строится на этом принципе. Соответственно, тут надо определяться, что тебе ближе. Если тебе нравятся развесистые фреймворки типа Spring, ASP.NET И тому подобное, то GO лучше не выбирать. Если же душа лежит к SRP, к UNIX-way, то GO будет в самый раз. ИМХО в этом контексте GO лучше всего идеологически подходит к микросервисам, потому что микросервисы тоже про SRP и UNIX-way, только применительно к сервисам.

Здравствуйте, tnikolai, Вы писали:

T>Я смотрел в сторону Ent и Gorm, правда не пробовал их, они проигрывают ORM из java/c# ?

Лучше и не пробуй, если хочется ORM, то бери C#, там лучший ORM. GO — это про то, что код должен быть максимально простой и прозрачный и про отсутствие лишних абстракций в виде ORM, которые в экосистеме GO проитвоестественны. В случае GO лучше смотри на sqlx

Здравствуйте, mrTwister, Вы писали:

T>Go — это про принцип KISS, про то, что всё должно быть максимально просто, явно и очевидно и вся экосистема GO строится на этом принципе. Соответственно, тут надо определяться, что тебе ближе. Если тебе нравятся развесистые фреймворки типа Spring, ASP.NET И тому подобное, то GO лучше не выбирать. Если же душа лежит к SRP, к UNIX-way, то GO будет в самый раз. ИМХО в этом контексте GO лучше всего идеологически подходит к микросервисам, потому что микросервисы тоже про SRP и UNIX-way, только применительно к сервисам.

SRP, Unix-way и все такое мне в самый раз. А вот простота Go это для меня не про KISS, а про деградацию.

SQL в конкатенированных строках, инфраструктурный бойлерплейт в коде — не мое. Хорошая ниша — переписать что-то, что уже сделано и отлажено для последующей поддержки.

Здравствуйте, Ziaw, Вы писали:

Z>SRP, Unix-way и все такое мне в самый раз. А вот простота Go это для меня не про KISS, а про деградацию.
Z>SQL в конкатенированных строках, инфраструктурный бойлерплейт в коде — не мое. Хорошая ниша — переписать что-то, что уже сделано и отлажено для последующей поддержки.

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

Здравствуйте, mrTwister, Вы писали:

T>Здравствуйте, Ziaw, Вы писали:

Z>>SRP, Unix-way и все такое мне в самый раз. А вот простота Go это для меня не про KISS, а про деградацию.
Z>>SQL в конкатенированных строках, инфраструктурный бойлерплейт в коде — не мое. Хорошая ниша — переписать что-то, что уже сделано и отлажено для последующей поддержки.

T>Это ложная дихотомия: либо монструозный фреймворк, либо инфраструктурный бойлерплейт. В Go научились делать просто, без магии и бойлерплейта. Делать просто всегда сложнее всего и от того, что в других комьюнити предпочитают магию простоте не следует, что нельзя сделать иначе.
Хотелось бы посмотреть пример идиоматического кода на Go, который делает что-нибудь простое — ну, например, отдаёт в REST-ендпоинте данные из SQL базы с проверкой row-level ограничений доступа.
Чтобы было просто, без магии и бойлерплейта.

Здравствуйте, mrTwister, Вы писали:

T>Это ложная дихотомия: либо монструозный фреймворк, либо инфраструктурный бойлерплейт.

Действительно ложная, где ты ее взял?

Тем более фреймворк может добавить простоты, т.к. пишется не фреймворк, а код. Код с фреймворком может быть очень прост. Как пример — ASP.NET MVC, супер простой фреймворк, позволяющий писать код проще чем аналогичный на Go.

T>В Go научились делать просто, без магии и бойлерплейта. Делать просто всегда сложнее всего и от того, что в других комьюнити предпочитают магию простоте не следует, что нельзя сделать иначе.

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

Здравствуйте, Kernan, Вы писали:


scf>>Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость.
K>А разве это не ещё одни микросервисы?

Кстати, хороший вопрос. Может они сдлеаны как микросервисы, но я бы отнес их к инфраструктуре. Т.е. то, что не надо делать с нуля.

Здравствуйте, Ikemefula, Вы писали:

I>Снова у тебя девелоперы виноваты. Нода обычно используется там, где достаточно простые задачи на бакенде.
Ну уж простую задачу можно на чом угодно нарисовать. Да хоть на баш, хоть на плюсах, хоть на перле. Всяко лучше чем нода. И возни меньше. А так как исчезает один компонент из системы — то и надёжнее.

Здравствуйте, Sheridan, Вы писали:

S>Ну уж простую задачу можно на чом угодно нарисовать. Да хоть на баш, хоть на плюсах, хоть на перле. Всяко лучше чем нода. И возни меньше. А так как исчезает один компонент из системы — то и надёжнее.

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