в вопросе было про статическую типизацию

тут

typescript

go/rust/kotlin/c

что-то там не так с типизацией и any

я забыл и не смогу аргументированно объяснить сейчас

вот хочется холивар Java/Scala/Kotlin vs Go в кейсе "для разработки бекенда стартапов с микросервисной архитектурой"

как-то туго с аргументами в пользу той или другой стороны, не хотят эти товарищи холиварить друг с другом)

про ts (из чата Dart'а)

типизация есть но она сломана - бивариантные параметры методов, отсутствие type variance и ковариантность дженериков (из-за чего в массив собачек можно запушить котика), невозможность выразить композицию функций через дженерики, не ловит ошибки где надо (двойной вызов log(obj.id) из того доклада Климова ) а где не надо находит (https://github.com/Microsoft/TypeScript/issues/19209)

далее будет имхо:

1) Твоя проблема в том, что ты натягиваешь реальность на какую-то модель в своей голове.  А реальность куда более многогранна и никто не разрабатывает "бекенд в стартапах с микросервисной архитектурой" ради архитектуры.

2) И ответ на вопрос "на чём?" сильно зависит от исходных данных и целях. Потому что если у тебя вокруг люди с java-бэкграундом - скорее всего что-то будет на jvm.
А плюсовикам будет проще и приятнее писать на чем-то похожем.

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

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

и сразу представляется некая команда с продуктом, который они пилили года-два и нужно дописать/изменить новые фичи, где будет быстрее - на Go? на Java? а где будет быстрее, если отмотать время на 10 лет вперёд? выйдут к тому моменту новые либы под Go, станет ли он таким же популярным монстром как Java или потихоньку превратится в "нишевый язык для доработки Kubernetes"

за этим стоит Google, какие события тут могут произойти? новые конфликты с Oracle в результате чего Google начнёт активно вкладывать деньги в развитие всего, что не Java?

> никто не разрабатывает "бекенд в стартапах с микросервисной архитектурой" ради архитектуры

типичный стартап - это проверка MVP и принцип "делаем 💩, но зато быстро", лучший ЯП для такого подхода - Python (альтернативы - PHP, JS/TS), даже если вдруг вся команда знает C++, было бы странно его использовать...

если к MVP появляются некие требования, связанные с надёжностью работы сервиса, то возникают мысли про статическую типизацию, но требования "делать быстро" не исчезают... и кто тогда становится лидером вместо питона? а через 10 лет? мысли были об этом...

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

тут разные мнения есть на эту тему, некоторые считают, что удобнее микросервисы сразу, если так организованы процессы и коммуникации (закон Конвея, https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9A%D0%BE%D0%BD%D0%B2%D0%B5%D1%8F)

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

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

Сильно зависит от предметной области.

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

при определённой структуре микросервисы будут вполне естественны с самого начала (если разработчиков больше 1,5 человек, конечно)