> Poor/inconsistent null handling That's one of my gripes with the language too. Due to the lack of generics, Go programmers just use pointers to indicate null

> Poor/inconsistent null handling That's one of my gripes with the language too. Due to the lack of generics, Go programmers just use pointers to indicate nullability - not exactly the right approach. Thankfully, it's still an improvement over Java, as non-nullable pass-by-value semantics are the default, so if you want a pointer you have to explicitly define one. I have my fingers crossed that once generics land, the ecosystem switches over to some sort of an Option type. > have a poor module system I'm curious, what's poor about it? > runtime with almost no knobs to apply workload specific optimisations, etc The approach Go takes is that the GC should "just work" for all workloads. Obviously, this will never be 100% optimal for any given workload, but you know... tradeoffs. That said, the knobs you're looking for do exist, but they are in the language itself. Unlike Java, Go makes writing GC-friendly code easy. > Even in Java [...] you have all the primitives at your fingertips, real threads, powerful reflection, metaprogramming and runtime introspection. Aren't "real threads" strictly worse than green threads? > powerful reflection, metaprogramming Those are misfeatures, especially metaprogramming.