Hacker News Reader

Comment by derriz | Hacker News Reader

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.

View on HN

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++.

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.

Regarding .NET, https://github.com/dotnet/runtime/issues/12221

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.

Well, with the Foreign Memory API one can quite easily do everything basically, including u64 indexing.

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.

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.

> 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?

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 :).

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?

Reply on news.ycombinator.com