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