> Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency.
Kotlin does that today and I like Kotlin, however the fact is that the class-everywhere Java approach just doesn't sync with me. Go's and Rust approach to OO with value-based types (structs) suits me much better.
> golang doesn't even have concurrent data structures
Not strictly true. It does have sync.Map There's also 3rd party packages offering this.
Java is getting record types as well. That being said, one is free to use whatever JVM language they like and still get the huge benefits of the JVM, regardless of the language.
> Not strictly true. It does have sync.Map There's also 3rd party packages offering this.
Which still uses locks behind the scenes. Java's concurrent structures are lockless in general (lockless maps, lockless queues, channels, etc.). Not to mention casting to and from interface{} which is error prone and very tedious and verbose.
It's not an either-or situation. Java's generics have their advantages (I'm assuming you're referring to type erasure). Just look at the number of languages implemented on top of the JVM to see what I'm talking about. Type erasure made inter-op much easier between languages implemented on the JVM. That being said, there are upcoming improvements to generics in Java and the JVM (e.g. JEP 218).
And generics constitute just one part of a type system. You have languages like Scala if you're looking for a language with a more advanced type system than Rust's, and it also runs on the JVM.
Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency.
> Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered.
golang doesn't even have concurrent data structures. So it's either CSP or mutexes, both not ideal for high performance code.