5 ms·

On any platform?

threeseed 4y ago
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.
- bdangubic 4y ago
  This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)
  - geodel 4y ago
    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.
  - misja111 4y ago
    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.
  - valenterry 4y ago
    It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.
- Joeri 4y ago
  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/race https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...
  - vyshane 4y ago
    No backpressure in RxJS.
- cube2222 4y ago
  This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).
  - valenterry 4y ago
    Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.
    - cube2222 4y ago
      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.
      - valenterry 4y ago
        > 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!
        cube2222 4y ago
        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
        valenterry 4y ago
        Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.
- theCodeStig 4y ago
  Cats effect can do the same
- brightball 4y ago
  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.
  - valenterry 4y ago
    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!
    - Taikonerd 4y ago
      A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/ https://gleam.run/ (Disclaimer: I haven't used Gleam, I just know it exists.)
      - valenterry 4y ago
        I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!
- jodersky 4y ago
  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).
  - pshirshov 4y ago
    > 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.
- marcosdumay 4y ago
  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.
  - seer-zig 4y ago
    This will make it trivial in Java: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428

On any platform?

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.

bdangubic 4y ago
This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)
- geodel 4y ago
  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.
- misja111 4y ago
  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.
- valenterry 4y ago
  It definitely is. You can even see it by looking at how the languages market themselves, claiming to make concurrency easy etc.
Joeri 4y ago
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/race https://www.learnrxjs.io/learn-rxjs/operators/combination/ra...
- vyshane 4y ago
  No backpressure in RxJS.
cube2222 4y ago
This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).
- valenterry 4y ago
  Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.
  - cube2222 4y ago
    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.
    - valenterry 4y ago
      > 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!
      - cube2222 4y ago
        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
        valenterry 4y ago
        Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.
theCodeStig 4y ago
Cats effect can do the same
brightball 4y ago
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.
- valenterry 4y ago
  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!
  - Taikonerd 4y ago
    A statically-typed language running on BEAM? Sounds like Gleam: https://gleam.run/ https://gleam.run/ (Disclaimer: I haven't used Gleam, I just know it exists.)
    - valenterry 4y ago
      I think as a Scala developer, my expectations/demands can't be matched by Gleam unfortunately. But if it could, then yes!
jodersky 4y ago
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).
- pshirshov 4y ago
  > 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.
marcosdumay 4y ago
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.
- seer-zig 4y ago
  This will make it trivial in Java: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428