но ведь это очень субъективно..
и смотря что разрабатывать

Экспертиза команды решает.

Да, Го простой. Но все его знают? Нет. И даже если выучить язык, нужно разбираться с остальным барахлом:

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

Знать сам язык != знать экосистему.

По куче из вышеперечисленных пунктов у Го была чехарда с тем, что считать решением по умолчанию. Скандал вокруг Iris гремел полгода, например.

Ну и сам аргумент “Го настолько простой” не особо заслужен. На Го неудобно писать полиморфный код (надо кастить везде), неудобно / невозможно писать в функциональном стиле. И если это то, к чему ты привык, то Го - ни капельки не простой.

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

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

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

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

Но в общем согласен, принимается, спасибо!)

в ноде меня пугает абсолютно недоразвитые модули для работы с БД.
Если брать голый pg иже с ним подобный клиент-драйвер, то еще нормально.. писать голые запросы в БД.

Но если захочется прикрутить какой-нибудь knex (да еще и с тайпскриптом) - то еще приключение, как минимум с миграциями.

А если на большие ORM смотреть, типа той же TypeORM которая подает надежды, но у нее дата мапперы настолько тяжелые что все преимущества однопоточной асинхронности ноды сводятся на нет этими постоянными синхронными маппингами где при какой-нибудь средней нагрузке уже начнутся микро-фризы ивент лупа

Так сложилось исторически  что serverless часто пишут на js

Node - это ж не про производительность. Его в 2009м продавали как “быстрый”, потому что сравнивали с тогдашними популярными динамическими языками для бекенда: PHP, Python, Ruby.

В тех языках тогда JIT не было, сборка мусора была простой Mark & Sweep Stop the World (или аналоги).

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

Соответственно, нода хороша в проксировании трафика.

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

Я не вижу чем абстрактный нест на сервере хуже абстрактного симфони

Ага, или Ruby on Rails / Django

Рельсы это вообще отдельная история (с ними по гитлабу сталкиваюсь)

Совершенно другой мир с магией, пумами и единорогами

Проксирование - дело haproxy или nginx, уж точно не ноды. Главное - это именно доменная лоника на js, при этом скорость вообще не важна, хоть на ноде можно писать очень быструю и производительную логику.

Мне нравится.

Я пока страдаю :)

Руби это то место откуда js заразился практиками говнокода

Даже не практиками и методолгией - хряп-хряп-и-в-продакшен

Ой не надо вам.

laravel на php кстати тоже с рубей это взял)

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