Go shot past similar languages because Google's backing got lots of instant attention from people who would never even hear of something like Nim or Clay.

> In many ways it's Java done right

Not quite:

* no generics

* error prone error handling

* non tunable GC

* null pointers

* golang interfaces are messy and can't be used to tag structures

* golang time package is garbage

and lots more

Java today is superior to golang in almost every front.

Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.

Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1].

Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off.

I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics.

Deployment has been solved for a while now with building shadow jars[1].

[1] Not to mention offerings like: https://quarkus.io/

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.

And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.

Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.

Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap:

    func main() {
        n := 1
        fmt.Println(n)
    }

Object pooling won't help here.

The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.

You can pool n if it's on your hot path, can't you?

Escape analysis was just rewritten, and the objective is to handle this case more gracefully.

I don’t understand the comparison to Haskell or Ocaml; those languages are not C like and have a much different philosophy on the responsibilities of the language and type system.

Haskell is not C like? You can write Haskell with curly brackets and semicolons, just like Go! I rest my case.

No, but seriously, you didn't get what I was saying there. The whole reason Go might be of interest is that it is loosely C-like in a way that Haskell and Ocaml are not.

That true, and I still don’t get what you are saying here. In my mind, they are different languages which appeal to different developers and fit with different requirements. I don’t see it as an alternative to Haskell any more than any Turing-complete language is technically an alternative.

Then why did D never take off?

For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.

I don't necessarily agree with the parent's point but D managed to fumble early on and never managed to catch up ever since. Around the time it got released (in the early 2000's) I was a C++ coder and I remember being very interested, only to immediately dismiss it as soon as I learned that it wasn't fully open source. I'm sure other devs didn't mind as much as I did but it definitely stunted growth early on. By the time they fixed this "issue" there was a lot of competition in that space and I never bothered looking back.