That's a stawman fallacy. There is no perfect language. However, there are languages that almost are strictly superior to others. Java and C# in this case are almost strictly superior to golang in almost every front.
I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others.
I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1].
Perhaps I'll upset some, but IMO Go would be another obscure language that no one cared about if it didn't come from Google.
> I wouldn't necessarily call Go's concurrency model superior
Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases.
> I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os
Is that OS written in Java or C#, because that's what the discussion was about.
Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered.
Also, size seems like an odd complaint to me in today's day of cheap disk space. On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.
> but IMO Go would be another obscure language that no one cared about if it didn't come from Google.
The people who worked on golang also worked on another similar language called limbo before they were at google. You can guess where that one ended up.
Compiling to a native binary is not a strict advantage, there are many advantages for running in a managed environment, and it can be argued that for critical systems it is the superior route in fact (given that you have the resources to run said VMs, which unless you're doing embedded or resource constrained systems, is a non-issue).
That being said, both Java and C# can compile to native binaries. Java is getting Fibers, basically JVM managed lightweight threads, and has a strictly superior concurrency library in the form of `java.util.concurrent`. Not to mention libraries like Vertx and Akka for concurrency and actor systems.
- simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring )
- memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server.
- the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch )
- Don't need 200MB of library to open a file or create a REST server
- maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary
- 50 line stack trace that tells nothing
- observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. )
I worked with Java for many years and I can tell you that Go is a breeze of fresh air, it's not perfect but it's good for what it was designed.
I mostly write Haskell professionally, but I still reach for Go depending on the project. Sometimes it just has the libraries I need and I can tell up front that I'm willing to deal with the tedium the language forces on me. Cost/benefit analysis.