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.
> Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency.
Kotlin does that today and I like Kotlin, however the fact is that the class-everywhere Java approach just doesn't sync with me. Go's and Rust approach to OO with value-based types (structs) suits me much better.
> golang doesn't even have concurrent data structures
Not strictly true. It does have sync.Map There's also 3rd party packages offering this.
Java is getting record types as well. That being said, one is free to use whatever JVM language they like and still get the huge benefits of the JVM, regardless of the language.
> Not strictly true. It does have sync.Map There's also 3rd party packages offering this.
Which still uses locks behind the scenes. Java's concurrent structures are lockless in general (lockless maps, lockless queues, channels, etc.). Not to mention casting to and from interface{} which is error prone and very tedious and verbose.
It's not an either-or situation. Java's generics have their advantages (I'm assuming you're referring to type erasure). Just look at the number of languages implemented on top of the JVM to see what I'm talking about. Type erasure made inter-op much easier between languages implemented on the JVM. That being said, there are upcoming improvements to generics in Java and the JVM (e.g. JEP 218).
And generics constitute just one part of a type system. You have languages like Scala if you're looking for a language with a more advanced type system than Rust's, and it also runs on the JVM.
> On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.
Java application servers have been offering this for a long time now. Just drop in a .war file and your code is running. No need to restart, and the .war file has a small size.
> 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.
They're not in the same market. Dart faced competition from TypeScript (same designer as C#, and also backed by Microsoft), and the latter seems to have won so far.
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.
> - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring )
Another strawman. There are many other frameworks other than Spring that are simple and performant and easy to deal with.
> - 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.
No one is requiring you to use -Xmx 512MB. The JVM will take up as much memory as you give it. And newer GCs will release unnused memory back to the OS much more aggressively.
> - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch )
golang barely has any settings, which completely limits how it can be used. If you want to tune your code for throughput instead of latency, well you can't. The JVM gives you this option, and even moreso with ZGC and Shanendoah (TBs of heaps with ~1ms max latency). golang's gc can't even approach that.
> - Don't need 200MB of library to open a file or create a REST server
That's quite ridiculous. You don't even need any dependencies to open a file. And not all JVM web frameworks are Spring. There are many light weight alternatives.
> - 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
It depends on how you configure them. golang's dependency management is non-existent, so no real comparison there.
> - 50 line stack trace that tells nothing
On the contrary, this is one of the biggest advantages of using the JVM or .NET. You get a stack trace telling you exactly where things happened. Compare that to golang where you get a single string and you have no idea which code path was taken to reach that error.
> - 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 .. )
The JVM is the most superior platform for metrics, measurement, and monitoring. This is an established fact, and anyone claiming otherwise shows they don't have experience in this area.
> - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring )
that is decision of the project developer, it seems really nice at first when project is small, then it becomes a nightmare to manage, but spring is not really part of a language, but a framework. Go is still fairly young so it doesn't have "enterprisy" tolls :)
> - 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.
fair point, memory consumption is a huge problem but I believe it's because people over years are adding various dependencies and build on top of them. I remember when for one project I wanted to graph a dependency try using IntelliJ, and it was just crashing the IDE each time. I didn't work with C# and don't know how much of this applies to it, but I think major reason for not being used is that it primarily targets Windows platform. Also you see a lot of Go code around Kubernetes, because Kubernetes also originates from Google.
As for "-xmx -xms 512MB" this is because that the code runs on a VM, if you would compile it to a native language this shouldn't be needed AFAIK.
> - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch )
that's because of the VM
> - Don't need 200MB of library to open a file or create a REST server
This is false, you also don't need a 200MB library, that functionality is included in the language, it's just that maybe that library is nicer to use. Go is younger so it had opportunity to learn from other language's mistakes and designed its library based on lessons learned, it also did not have need to evolve together with the protocol.
> - 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
that's because it is young, it doesn't really have any real dependency tracking yet (well... starting with 1.11 modules were introduced) but that's still rudimentary
> - 50 line stack trace that tells nothing
it's different error handling, in Go on the other hand you might not get any error just SIGSEGV, creating a reliable stack trace requires work from the developer
> - 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 .. )
It's a misconception that you need a lot of memory to run a Java app. Just for example:h ttps://news.ycombinator.com/item?id=19728329
> > - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch )
> that's because of the VM
It's not even that. Python has a VM. However, the JVM (at least up to version 8) was tuned for throughput at the expense of latency by default. Starting with Java 9 I believe, the G1GC has become default, and there are new GCs being worked on right now for even lower latencies for huge heaps (in the TB range). golang would not even fair close in such applications because of its limited gc.
