Hacker News new | ask | show | jobs
by AsyncAwait 2605 days ago
> 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.
2 comments
apta 2605 days ago
> 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.

link
AsyncAwait 2604 days ago
> 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.

link
apta 2604 days ago
> 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.

link
AsyncAwait 2604 days ago
> 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.

link
apta 2603 days ago
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.

link
apta 2605 days ago
> 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.

link