3 ms·

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.

by 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.
  - klabb3 4y ago
    > Now of course if you want the async coding model with all it's benefits (selection, cancellation), then there is really no escaping it Isn't Go proof that this works just fine, arguably even better, with the blocking model?
    - ibraheemdev 4y ago
      It definitely can work, but Rust's model is incredibly powerful, and can make it easy to model complex control flow. Certain patterns, such as cancellation, can get pretty hairy in Go, although this is a place where Rust has some work to do as well :).
      - klabb3 4y ago
        Yeah, but those complex control flows are not free. Drop-to-cancel is a rather powerful foot gun in many cases. Basically you throw out invariants that most people takes for granted, e.g. if a function is started it will complete before exiting the caller's scope. Regarding cancelation, I think Go got it near perfect with contexts, modulo the explicitness of it. What don't you like about it?

by derriz 4y ago

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.
- klabb3 4y ago
  > Now of course if you want the async coding model with all it's benefits (selection, cancellation), then there is really no escaping it Isn't Go proof that this works just fine, arguably even better, with the blocking model?
  - ibraheemdev 4y ago
    It definitely can work, but Rust's model is incredibly powerful, and can make it easy to model complex control flow. Certain patterns, such as cancellation, can get pretty hairy in Go, although this is a place where Rust has some work to do as well :).
    - klabb3 4y ago
      Yeah, but those complex control flows are not free. Drop-to-cancel is a rather powerful foot gun in many cases. Basically you throw out invariants that most people takes for granted, e.g. if a function is started it will complete before exiting the caller's scope. Regarding cancelation, I think Go got it near perfect with contexts, modulo the explicitness of it. What don't you like about it?