This is terrible advice. Golang may have a flavor-of-the-week status in some people's minds, but it's a language that really deserves more credit. It is really easy to program and learn, and it does a lot of stuff other languages rely on third party programs for. With each release, nagging issues (namely around garbage collection) are getting resolved, but it's more than production ready. To ignore Golang right now would be akin to ignoring Java back in the early 2000s in my opinion.
Golang has my attention, but I don't think it's anywhere near Java, at least popularity-wise, in the early 2000s. By then most schools had already switched their language of choice to Java - I'm not aware of any that has switched theirs to Golang.
I do enjoy coding in Golang, but we use mostly Java where I work, and for us, the benefits don't make up for the things we lose. This blog post is a great example: the solution they had to find is the first thing you'd probably do in Java, because Java has a standard package with all sorts of concurrency patterns.
Yeah, I remember wanting to do a fan-out pattern in Go and reading the Go Pipelines and Cancellation article[0]. I saw the function merge() in the article and thought, "Great, here's what I need!" I then proceeded to read further and saw that I have to define this function myself based on the types I'm using, which made me quite sad.
Go really needs a library for these patterns built in... I assume the lack of generics prevents users from creating that themselves (I'm not trying to start a language war here, seriously).
"To ignore Golang right now would be akin to ignoring Java back in the early 2000s in my opinion."
Except Go provides limited value for somebody who already knows .net or a jvm language. And that's a huge chunk of the market.
And the key advantage that Go offers to business is that they can easily hire from a pool of experienced programmers and have them learn Go with little downtime.
Sitting at a corporation and learning Java may have been a popular thing to do to join the "boys" club in the early 2000s but I promise you that won't last forever. It's not bad advise to pick a target and actually point at it instead of wasting time solving a problem that has already been fixed.
depends a lot on what your constraints are and what goal you're trying to achieve. Go could be the right choice, but I believe the prior poster was alluding to the fact that it does not fit the sinatra/flask/etc. use case very well for most use cases.