> Rings especially true for my shop as well. I had to introduce Rust or Go, and went with Go. Seeing the mild pushback I get from Go's type system makes me especially glad I didn't choose Rust.

An other possibilities is that Go's static types feel like a lot of ceremony for too little benefit. That was one of my biggest issues with Java, and though Go's lighter it also provides less benefits… By contrast, Rust is in the camp of requiring a higher amount of ceremony but providing a lot of benefits from it (sometimes quipped as "if it compiles it works").

Why do you think Go's type has "less benefit" than Java's type system?

That's my personal, anecdotal feeling as well. Go feels a bit more like I'm yelling at the compiler "you know what I mean, why can't you just do it?!" whereas with Rust it's more "ah, I see, you have a point".

Java has generics for one.

Failed generics with type-erasure sure, but definitely better than Go which has nada.

Type erasure on it's own isn't necessarily a bad thing, Haskell implements type erasure also.

I guess this was your point, but the problem is how Java does does type erasure. With Haskell type erasure is an implementation detail, but with Java it leaks into the compile-time type checker. For instance, you can't have both these overloads:

    public void foo(List<String> list)
    public void foo(List<Integer> list)

This just wouldn't compile.

The problem there is that the equivalent Haskell would dispatch statically, whereas this is dynamic dispatch in java

Not today, but in the future it might, depending on how the work on value types will turn out.

The difference is that Haskell has very little RTTI, so you can't really see the missing types at runtime. For Java it's much more noticeable, because runtime type manipulations are way more common.

Well, Go's type system is a butt of many jokes.