4 ms·

I only observe Java from a distance but everything I've read about project loom is amazing. Speaking as someone who has worked intricately on an async runtime

by klabb3 4y ago

I only observe Java from a distance but everything I've read about project loom is amazing. Speaking as someone who has worked intricately on an async runtime in another language, I've more and more started to question the premises around the explicitly async paradigm. Lots of things we were "promised" with async turned out to be just as complicated in the threaded (i.e. blocking) programming models, and now we have two incompatible programming models. I'm now of the opinion that we should improve (instead of replace) our threaded models and do under-the-hood optimizations to sort out the performance issues. If I had a dime for everytime someone made a blocking call from an async function.. And who can blame them? Most blocking functions aren't even documented as such, you just have to know.

sebazzz 4y ago
> If I had a dime for everytime someone made a blocking call from an async function.. And who can blame them? Most blocking functions aren't even documented as such, you just have to know. Isn't that exactly what loom aims to resolve?
lichtenberger 4y ago
Yes, I think Loom is an amazing step forward and it's brilliant to just change the blocking methods and thus existing code might already benefit with minor changes.
derriz 4y ago
Yeah, I've used a bunch of non-blocking paradigms over the years and all become painful quickly once the system becomes non-trivial, except for green threads. I was very disappointed that Rust dropped this feature in favour of async.
- dralley 4y ago
  It makes sense for Rust. Rust with a significant runtime wouldn't provide much value over Go / Kotlin / Java / C#, whereas Rust without a heavy runtime is the first legitimate competitor to the dominance of C / C++.
  - lostmsu 4y ago
    At least Java and C# have a problem of being 32-bit. Most of the standard collections and interfaces use i32 for sizes, offsets, etc. So large parts of the existing codebases can't be directly reused to manipulate data in sizes, that are not so "big" anymore. I'd like to see how those platforms will be able to get past that legacy.
    - pjmlp 4y ago
      Regarding .NET, https://github.com/dotnet/runtime/issues/12221 https://github.com/dotnet/runtime/issues/12221
      - lostmsu 4y ago
        Exactly. This one has been open for 3 years now (and it is probably not the first one), and the completion is nowhere in sight. It also only targets runtime, but does not yet solve the library compatibility issue.
    - kaba0 4y ago
      Well, with the Foreign Memory API one can quite easily do everything basically, including u64 indexing.
  - deleted 4y ago
    [deleted]
  - klabb3 4y ago
    I think you're both right. Rust with green threads would have been incompatible with their goals for embedded. Otoh, if the runtime was pluggable at compile time, you could retain that choice while catering to the majority user base (i.e. the ones currently using Tokio). In order to do that, you'd have to have an abstraction over the syscalls. I'm not entirely sure this is feasible with all the ins and outs of Rust, but seeing the success of Loom, I'm at least optimistic.
  - ibraheemdev 4y ago
    Rust makes it very easy to use plain old OS threads, which work very well for many, dare I say _most_ use cases. OS threads are a lot lighter and cheaper than many realize, and async has it's own hidden costs. In the cases that OS threads don't cut it, a general purpose async runtime isn't likely to either. Green threading libraries are also possible without language integration [0], and though they require custom I/O types they have a synchronous API, which makes generic abstractions easier. Now of course if you want the async coding model with all it's benefits (selection, cancellation), then there is really no escaping it, but it's certainly not the only option.
lmm 4y ago
The fact that explicit async turned out to be more complicated than expected is precisely why I'm skeptical of loom. When the magic works perfectly it'll be great. When it doesn't... > If I had a dime for everytime someone made a blocking call from an async function.. And who can blame them? Most blocking functions aren't even documented as such, you just have to know. Agreed. I'd like to see blocking represented in the type system the same way we do for async, so that you can't mix and match the two unless you deliberately choose to.
- jayd16 4y ago
  > so that you can't mix and match the two unless you deliberately choose to. Function coloring as a feature?
  - lmm 4y ago
    Function colouring has always been a good idea, as long as you have a language where you can be polymorphic over it where appropriate (i.e. one with higher-kinded types).
- Quekid5 4y ago
  The type of thing Loom is doing has been working great in e.g. the Haskell runtime for decades at this point.
  - kaba0 4y ago
    What do you mean? I really don’t think there is anything comparable in Haskell.
    - funcDropShadow 4y ago
      There is and it has been for quite some time, see chapter 4 of [1]. [1]: Runtime Support for Multicore Haskell, Simon Marlow, Simon Peyton Jones, Satnam Singh (https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/multicore-ghc.pdf https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...)
dboreham 4y ago
Strong agree. It turns out Tony Hoare was right.
deleted 4y ago
[deleted]
pjmlp 4y ago
From .NET and C++ point of view, async/await, turns out to be a pain because unless the complete call stack is written to be async, we need to create async bubbles to be able to call into those functions. Microsoft tried to make everyone program the right way in WinRT and it was one of the reasons why many developers hate it (among the other reasons vs Win32), because you get async everything.

by klabb3 4y ago

sebazzz 4y ago

> If I had a dime for everytime someone made a blocking call from an async function.. And who can blame them? Most blocking functions aren't even documented as such, you just have to know. Isn't that exactly what loom aims to resolve?

lichtenberger 4y ago

Yes, I think Loom is an amazing step forward and it's brilliant to just change the blocking methods and thus existing code might already benefit with minor changes.

derriz 4y ago

Yeah, I've used a bunch of non-blocking paradigms over the years and all become painful quickly once the system becomes non-trivial, except for green threads. I was very disappointed that Rust dropped this feature in favour of async.

dralley 4y ago
It makes sense for Rust. Rust with a significant runtime wouldn't provide much value over Go / Kotlin / Java / C#, whereas Rust without a heavy runtime is the first legitimate competitor to the dominance of C / C++.
- lostmsu 4y ago
  At least Java and C# have a problem of being 32-bit. Most of the standard collections and interfaces use i32 for sizes, offsets, etc. So large parts of the existing codebases can't be directly reused to manipulate data in sizes, that are not so "big" anymore. I'd like to see how those platforms will be able to get past that legacy.
  - pjmlp 4y ago
    Regarding .NET, https://github.com/dotnet/runtime/issues/12221 https://github.com/dotnet/runtime/issues/12221
    - lostmsu 4y ago
      Exactly. This one has been open for 3 years now (and it is probably not the first one), and the completion is nowhere in sight. It also only targets runtime, but does not yet solve the library compatibility issue.
  - kaba0 4y ago
    Well, with the Foreign Memory API one can quite easily do everything basically, including u64 indexing.
- deleted 4y ago
  [deleted]
- klabb3 4y ago
  I think you're both right. Rust with green threads would have been incompatible with their goals for embedded. Otoh, if the runtime was pluggable at compile time, you could retain that choice while catering to the majority user base (i.e. the ones currently using Tokio). In order to do that, you'd have to have an abstraction over the syscalls. I'm not entirely sure this is feasible with all the ins and outs of Rust, but seeing the success of Loom, I'm at least optimistic.
- ibraheemdev 4y ago
  Rust makes it very easy to use plain old OS threads, which work very well for many, dare I say _most_ use cases. OS threads are a lot lighter and cheaper than many realize, and async has it's own hidden costs. In the cases that OS threads don't cut it, a general purpose async runtime isn't likely to either. Green threading libraries are also possible without language integration [0], and though they require custom I/O types they have a synchronous API, which makes generic abstractions easier. Now of course if you want the async coding model with all it's benefits (selection, cancellation), then there is really no escaping it, but it's certainly not the only option.

lmm 4y ago

The fact that explicit async turned out to be more complicated than expected is precisely why I'm skeptical of loom. When the magic works perfectly it'll be great. When it doesn't... > If I had a dime for everytime someone made a blocking call from an async function.. And who can blame them? Most blocking functions aren't even documented as such, you just have to know. Agreed. I'd like to see blocking represented in the type system the same way we do for async, so that you can't mix and match the two unless you deliberately choose to.

jayd16 4y ago
> so that you can't mix and match the two unless you deliberately choose to. Function coloring as a feature?
- lmm 4y ago
  Function colouring has always been a good idea, as long as you have a language where you can be polymorphic over it where appropriate (i.e. one with higher-kinded types).
Quekid5 4y ago
The type of thing Loom is doing has been working great in e.g. the Haskell runtime for decades at this point.
- kaba0 4y ago
  What do you mean? I really don’t think there is anything comparable in Haskell.
  - funcDropShadow 4y ago
    There is and it has been for quite some time, see chapter 4 of [1]. [1]: Runtime Support for Multicore Haskell, Simon Marlow, Simon Peyton Jones, Satnam Singh (https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/multicore-ghc.pdf https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...)

dboreham 4y ago

Strong agree. It turns out Tony Hoare was right.

deleted 4y ago

[deleted]

pjmlp 4y ago

From .NET and C++ point of view, async/await, turns out to be a pain because unless the complete call stack is written to be async, we need to create async bubbles to be able to call into those functions. Microsoft tried to make everyone program the right way in WinRT and it was one of the reasons why many developers hate it (among the other reasons vs Win32), because you get async everything.