Да терзают сомнения, а не произойдет как с kotlun. Go все же язык закрытый и не поддерживает всякие ГОСТы - что просто необходимо Гостеху. Железнячники тоже не все на него перекинулись. Не все типы процессоров и ОС Go будет поддерживать- у GNU compiler collection таких возможностей больше и нет риска привязаться к одному процессору. Ну и куча софта что уже написано под Java. Не Hibernates единым же Java жива.

Я думаю, что Java - это как Джеймс Бонд, агент 007, все про него знают, решает любую задачу и актуален он будет еще очень долгое время. А Go - это Джон Уик, молодой, новый, современный, но будут ли его переснимать через 20 лет - не понятно

Я просто к тому - что железнячники за него взялись. Им граблей с луп мало что? Да вернее всего так. При этом го не сильно сложный.

Да вопрос в том Или глубоко внутрь - там Кваркус тот же , или Го.

То есть куда сейчас бигтех идет. Про стек завтрашнего дня.

Я бы выбрал Go. Quarkus, Micronaut - имхо, имея опыт с одним из фреймворков не сильно глубоко) По крайне мере это мнение с слов моего друга, лично сам я не щупал)

Читал, да и по вакансиям наблюдал, что когда времени и денег предостаточно сервисы с Java переписываются на Go для увеличения производительности. Кто-то делает это полностью, где возможно, а кто-то комбинирует (прокси-сервис на Go для сетевых запросов, Java или Kotlin для сервисов с кучей бизнесовой логики, рядом ещё и LLM могут прицепить с сервером-оберткой на Python). Поэтому Ваше ощущение того, что стоит в Go погрузиться, весьма оправдано.

Да стартует быстро. Теже аналоги спринг хибернейт (глаза мои его не видели) есть. В докере пускается на ура

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

Ну как-то был проект - из-за лямбд там Котлин задействовали. Что бы на 8 jdk у заказчиков не менять.

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

У пайтон там просто по структуре нет статических областей - то есть приложение - поток без синхронизаций. Но у него не было предкомпиляции. Я примерно в то время для видеонаблюдения на С++ делал. Задача синхронизировать картинку с камеры с однополосном радаром. Превышение скорости - видео как серия картинок - то есть внутрь h264 что камера отдавала. Отдавали ИИ который лучший вид номера находил и т д. Эх лет 10 начал было!!!

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

Видео на тех же плюсах и си. Там просто не куда не деться. Системы реального времени так же.

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

Молодеж всяким Луи или раст пытается. Го тот же. Но там обычно консерваторы - поэтому на Си или Плюсах. Плюс компилеры. GNU даже порой не всегда. Встречал проекты где приходилось интеловский компилер с полной оптимизацией под один тип процессора, иначе мощи не хватало. Но там на оптимизации команда из 10 чел в течении нескольких лет трудилась.