Почитал разные ветки комментариев, стало грустно.Ну, товарищи, вряд ли кто-то говорит про "вытеснить Java" или "вытеснить Python" абстрактно, зачем такое вообще обсуждать. А вот с тем, что в качестве языка написания микросервисов Golang во многих случаях вполне себе теснит другие варианты, спорить уже давно невозможно. Это не "небольшой прирост производительности", на Go вы можете писать нагруженные сервисы, в отличие от Python. В топовых компаниях разработчики выбирают писать бэкенд на Go не от того, что никто Python не знает. И это ни в коем случае не наброс на Python, у языка просто другие области эффективного применения (привет, ML и DS). Не верится, что приходится такое проговаривать.
Побуду тут адвокатом дьявола немного. Дело не в том, что Go "обижают". Расстраивает не критика, которой вполне есть место и которую познавательно читать, а то, что на opennet обсуждение порой ведётся на уровне "devops-тулзов" и "вебнявых поделок".
Больше всего в комментариях писали про память.
https://blog.golang.org/go15gc - вот реклама сборщика мусора Golang, там же ссылка на совсем короткий доклад с GopherCon Рика Хадсона про сборку мусора, который интересно глянуть, даже если вы никогда не собираетесь писать на Go.
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd... - а вот другой взгляд на вещи, с нормальной, адекватной критикой этой го-пропаганды. А не "ой, k8s - поделка, по мне так много памяти ест для таких задач".
Сборщик мусора у Golang изначально задумывался (и переписывался) именно исходя из идеологии обеспечения реалтаймовости. Пусть декларируемый разработчиками Go великий мировой "breakthrough" в построении GC звучит и явно громковато, но справедливо то, что именно они были наиболее успешны в вопросе минимизации длительности отдельных пауз.
И пусть пока куда чаще мы видим использование языка именно для "инфраструктурных" задач и для написания сервисов, перед нами всё же компилируемый язык вполне себе общего назначения. На Golang вы можете создавать не только нагруженные сервисы, но и реализовать СУБД или написать userspace-драйвер.
Очевидно, везде есть рамки адекватной применимости. И, да, в итоге в той же Фуксии Go оставили только в сетевом стеке - странно, что ненавистники языка не припомнили это, а просто "где-то слышали". Но надо понимать, что Go конкурирует в таком контексте с C, C++ и Rust, а не с Java или, тем более, Python.
Относительно недавно здесь же проскакивала новость по теме, сравнение производительности сетевого драйвера в вариантах на 10 языках программирования: https://www.opennet.ru/opennews/art.shtml?num=51475
Подытожу предельно скучным труизмом про то, что с Golang, как и с любым другим инструментом, нужно знать внутреннее устройство, чтобы уметь видеть преимущества языка и использовать их, понимать область применения решения, ну и не забывать о tradeoffs.
