It has the ability to make real-world concurrency scenarios trivial e.g.

* 3 fibers - each fetches from remote storage, local storage and in-memory cache.

* Race them, kill the two slowest and give me the result.

* Free the resources safely including if any of the connections fails for an unforeseen reason.

That's a few lines in ZIO. Pain to get working properly in Java, Rust, Go, C++ at least.

It may be the best on any platform outside of the BEAM, but there are a lot of correlating factors needed to create the ideal concurrency platform that you simply can't do without building them from the ground up.

It's why almost anything outside the BEAM can't make that claim.

True, BEAM is a platform on its own. Scala can use Akka which is also awesome, but doesn't have all the nice things builtin like BEAM.

I guess a merge of Scala as the language (because honestly, Erlang & co suck) and BEAM as the platform would be awesome!

A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/

(Disclaimer: I haven't used Gleam, I just know it exists.)

I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!

This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).

Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.

The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them.

Error handling and deferring for resource closure work just fine.

Sure you could say "but the compiler doesn't guarantee it". But that's not much of a point if it's not a real problem in practice.

> The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it

But that's exactly what OP was talking about. Maybe for you that doesn't mean Go fails here, but for (us) Scala developers it definitely feel like Go fails us. We want a language that fails at compiletime in as many cases as possible.

> But that's not much of a point if it's not a real problem in practice.

Maybe not for you. For me it is!

I agree it's fine to have different taste, as I mentioned in another reply to you.

But it's the difference between whether this statement is objective, or subjective.

> is the best concurrency library on any platform

Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.

Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.

Error handling and Go doesn’t mix well.

That's a matter of opinion. Many, me included, very much like the current, very explicit, approach.

I understand why people who like monadic constructs don't like it though.

Not quite: https://www.uber.com/blog/data-race-patterns-in-go/

I don’t know — I don’t claim that algebraic datatypes are the only proper way to handle errors, I’m okay with exceptions as well (even checked ones). But what go has is only very slightly better than C’s attempt, so I’m not sure it is that subjective.

I think the presence of multiple return values and the ability to easily use complex types for errors make a huge difference (adding wrapping messages, context, etc.).

I agree algebraic data types could improve this. I don't think monadic result types or exceptions would be an improvement.

I think maybe you've misread the intent.

I do not want to wait for the three fibers to finish. I want the whole process to stop the minute any of them have returned i.e. get me my data as quick as possible no matter its source.

I haven't.

You wait for the first result using i.e. a shared result channel, then you cancel the context.

It's still error prone in golang. Java's structured concurrency approach is much better.

This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)

Thats the thing with Scala, they are solving important problems. It is not spending time on useless problem like performant build system. I mean code is gonna compile eventually, if not today maybe tomorrow. But complex problem like described above will not be solved unless someone make a decent framework for it.

In the last 10 years every team/company I have been working in had to deal with at least one of these problems. Good for you if you only ever have to work with single threaded applications, but for most of us the reality of modern software development is different.

It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.

I find that one of the best things about using a managed runtime such as the JVM is the ability to get stack traces when things go wrong. When debugging, it is a considerable time saver to be able to determine the causality chain that lead to a specific failure.

Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces. At least all the ones I know of, including ZIO, Akka, Monix, plain Futures, etc. I know that there is tooling to counteract that (such as the abstractions used in distributed tracing), but that's again on the language level.

In my experience, for all but the most advanced applications, the debuggability advantages of using linear code outweigh the performance advantages gained by abstracting over execution contexts. Thus, I would posit that concurrency is best dealt with on the platform, not the language level, especially when starting a project.

Of course there are some situations where a library can make some concurrency task appear trivial, but as long as there is no good tooling, the time saved using beautiful abstractions tends to be paid back 5-fold when those abstraction break (which they often do as an application grows).

> Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces.

This is completely false. Years ago we (7mind) added async stack traces to ZIO. Now both Cats and ZIO support them.

That sounds like RxJS race(), and given that it's JS there's often no cleanup needed (and if there is RxJS has easy ways of doing that as well).

https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...

No backpressure in RxJS.

It's trivial in Haskell, a bit hard in Rust, really hard in Java, and trivial to get a non-working implementation and declare it flawless on C++. I never tried it in Go.

This will make it trivial in Java: https://openjdk.org/jeps/428

Cats effect can do the same