[apta]

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.

[Thaxll]

- 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.

[apta]

> - 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.

[takeda]

> - 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 .. )

I'm not sure what tooling are you talking about?

[apta]

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.