To me the implication is that the culture at this company won't allow this team to master Go either, and in a few years there will be a post describing how they moved from Go to another language.
Many people like to write about how Golang is so simple, but the drawback of that simplicity is that many features of other languages are either covered by additional dependencies or by inflating code size. It's just as possible for Go projects to devolve into big balls of mud as for any other language.
The mindset that you can master any programming language in a month is exactly what I meant in my previous post. There's a veritable cottage industry of "golang pitfalls" blog posts out there that show there are absolutely a lot of footguns in Go.
For example, what do you think the following should print?
values := []int{4, 8, 15, 16, 23, 42}
for value := range values {
fmt.Println(value)
}
I don't think there are very many people who would guess the integers 0 to 5.
I also like the following one:
ch := make(chan int)
ch <- 1
fmt.Println(<-ch)
What would this print? The only correct answer is sadly "fatal error: all goroutines are asleep - deadlock!".
Golang is a fine language and simpler than most, but sadly "simpler" is not the same as "simple".
But people here are comparing a language standard library with a framework like Spring, which doesn't make sense.
The Java standard library has a web server in it, it has JDBC. You could use those directly. That's comparable to the Go standard library. For real apps people don't do this because they want a lot more, like simplified database access or session management.
It strongly resembles JDBC. Doing a database query with that is verbose and error prone. Compare the work needed to do a lookup query and map the results to a data structure with that to (Micronaut syntax, Spring is similar):
var someGopher = gophersRepository.findById("goo");
Add the username/password/host/port to the config file and that's all you need for db access. Compare to the Go stdlib which wants you to manage drivers, connections, prepared statements, rollbacks, etc. It's a different level of abstraction.
Many people like to write about how Golang is so simple, but the drawback of that simplicity is that many features of other languages are either covered by additional dependencies or by inflating code size. It's just as possible for Go projects to devolve into big balls of mud as for any other language.