[takeda]

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others.

I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1].

Perhaps I'll upset some, but IMO Go would be another obscure language that no one cared about if it didn't come from Google.

[1] https://kolibrios.org/en/

[AsyncAwait]

> I wouldn't necessarily call Go's concurrency model superior

Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases.

> I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os

Is that OS written in Java or C#, because that's what the discussion was about.

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.

Also, size seems like an odd complaint to me in today's day of cheap disk space. On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.

[apta]

> the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases.

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.

[AsyncAwait]

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

[apta]

> Kotlin does that today and I like Kotlin,

Kotlin's coroutines are still not like fibers (it's still affected by: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...)

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.

[AsyncAwait]

> Not to mention casting to and from interface{} which is error prone and very tedious and verbose.

Agreed, but Java's generics are not the best either. When I am looking for an advanced type system in this space I look at Rust, not Java.

[apta]

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.

[apta]

> On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.

Java application servers have been offering this for a long time now. Just drop in a .war file and your code is running. No need to restart, and the .war file has a small size.

[apta]

> but IMO Go would be another obscure language that no one cared about if it didn't come from Google.

The people who worked on golang also worked on another similar language called limbo before they were at google. You can guess where that one ended up.

[geodel]

The people who worked on Java also worked on Dart after joining Google. You can guess where it ended up.

[SureshG]

Dart had an initial hiccup, but I think things started changing with flutter - https://github.com/flutter/flutter

[apta]

They're not in the same market. Dart faced competition from TypeScript (same designer as C#, and also backed by Microsoft), and the latter seems to have won so far.