Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A four year plan for async Rust

without.boats

Post reply on HN
Print view View original

51–60 of 236 posts

Re: A four year plan for async Rust

#51

Post by insanitybit »

no_wizard wrote: post #47
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist. I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone…

How can you argue that? Loom is extremely early, it's not proving anything.

And Java/Goroutines don't have a keyword because they do things implicitly, they have heavy preemptive runtimes.

Re: A four year plan for async Rust

#52

Post by alilleybrinker »

steveklabnik wrote: post #49
lucasyvas wrote: post #40

I think std needs a default runtime, and we might as well make it tokio, but maybe make the single-threaded executor the default instead and tweak the API where appropriate to align with this change. Swapping the executors out should absolutely be a feature, and the traits should be portable, but a way to start fixing the situation beyond the great suggestions in this proposal is to acknowledge that std and no-std us…

> I think std needs a default runtime, and we might as well make it tokio Regardless of the quality of this idea, it isn't going to happen: neither the Rust Project nor Tokio (in my understanding, to be clear I am not involved in either) want this to happen. > Swapping the executors out should absolutely be a feature, and the traits should be portable I am not fully aware of all of the details here but there are sign…

To pick out one example of what makes it challenging: not all executors place the same type system constraints on tasks they execute. Tokio, for example, is a work-stealing executor which requires tasks to implement the `Send` trait so they can be sent between threads, while other executors may never move tasks between threads and therefore don't require the `Send` bound.

Re: A four year plan for async Rust

#53

Post by [deleted] »

inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

[deleted]

Re: A four year plan for async Rust

#54

Post by zozbot234 »

no_wizard wrote: post #47
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist. I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone…

Goroutines and the Java Loom are just fibers. They're like a super clunky mix of async-like and thread-like features, though sometimes there are reasons to use them. (For example, stackful fibers might enable cleaner interactions with OS facilities or outside library code.) Rust makes it real easy to just use threads if that's what you prefer.

Re: A four year plan for async Rust

#55

Post by alilleybrinker »

vlovich123 wrote: post #28

Adding Move and deprecating pin/unpin would be a huge ergonomic improvement I think. I also think the Rust project should consider “out-of-band” editions if they can deliver big features like that sooner rather than waiting until 2027.

Note that in general, the Rust project has chosen a time-based, not feature-based, release model. New Rust versions come out every 6 weeks, and new Rust editions have a consistent cadence of every 3 years. There are advantages and disadvantages to debate between time-based and feature-based release models, but Rust pretty clearly has chosen their preference.

Re: A four year plan for async Rust

#56

Post by sargun »

I was a huge opponent of Rust, but finally decided to give it a try in anger once again.

I began writing a large application, and noticed that many of my libraries only offered async versions, and the promise was quite appealing -- not having to worry about threads or concurrency as long as I followed certain rules. What I ended up with was an incredibly slow application because of the limitations of Rust async, and the runtime. All of my I/O got pushed through one thread (with tokio), and that, plus scheduling overhead became my bottleneck. Debugging this was a nightmare in writing my own tracing tools.

20/20 hindsight, I would not write my code to be async, and would just prefer threads. I'm really not sure how / why async took off the way it did.

Re: A four year plan for async Rust

#57

Post by insanitybit »

CyberDildonics wrote: post #33
echelon wrote: post #17

Earlier quoted context omitted.

It's not elitist. I'm sick of people perpetuating this about the Rust ecosystem. It's not a month that goes by that there isn't some article badmouthing the language and its features. Stop it. We want our language to gain support in enterprise so we can get paid to write it as our day job. These articles and negative comments are not helping.

Your comments boil down to "I think rust is easy, stop giving your opinions that don't agree". You didn't make any arguments here at all. You can check my other comment for detailed reasons why async in a language is not a good approach to concurrency. The overview is that is just isn't a holistic solution and the only time it will solve someone's problem is if they have extremely simple concurrency needs in the firs…

The way I see their comment, and they'll have to forgive me if I'm wrong, is that the "async is bad" posts are generally not great.

a) They often focus on problems that, at least for me (and many others) are not significant. For example, acting like writing "+ Send + Sync + 'static" is causing your hands to seize in pain. Or they ignore that you can "block_on" a future.

b) They're then often interpreted by people who have very little context on async or rust at all. Look at the initial comment of "Async is a wart", it's idiotic. Look at how stupid the comments section is, how people are not talking about literally anything that boats wrote.

c) They make propositions that aren't very helpful. They mostly say "it was a mistake!" or "we don't need multithreading" or "we want TPC".

Contrast with Boats' post, which is far more contextual, far more historical, and proposes actual solutions and future work to be done.

It's quite frustrating to see the same sorts of complaints over and over again, especially when they're often not super great complaints to begin with.

Re: A four year plan for async Rust

#58

Post by samus »

Verdex wrote: post #38
lucasyvas wrote: post #20

Earlier quoted context omitted.

This is consistent with the author's assessment - the incomplete implementation of async makes it very challenging to advocate for, despite the fact that it was the only logical choice given Rust's design goals. I will say that the notion that you must make your whole project async is largely true (except that you can block on futures with all runtimes), but this is more symptomatic of the fact that Rust has hitched…

> It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design. My theory as to why C++ has become as a problematic language as it has is because it is able to do it all. And "all" doesn't fit nicely into a single package or paradigm. I don't like async (in any language), so your post immediately piqued my interest. I'm n…

The problem with C++ is that every feature

- attempts to solve too many problems,

- has significant papercuts that have to be considered,

- has significant runtime cost,

- interacts poorly with other features, or at least leaves significant edge cases open,

- has non-uniform compiler support (although in OSS land only GCC and LLVM matter), and

- creates arcane error messages that are anything but fun to analyze. Especially when templates are involved.

Above everything the fundamental problem that the unsafe parts of C are everywhere, and to master C++ you have to become really proficient at diagnosing problems with them because you will run into them. Only then can you start thinking about fun things like software architecture. Always use a linter/static analyzer.

Re: A four year plan for async Rust

#59

Post by jayd16 »

no_wizard wrote: post #47
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist. I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone…

Async handles thread contexts better. Maybe I'm out of the loop but implicit blocking patterns haven't taken over gui programming just yet.

Re: A four year plan for async Rust

#60

Post by insanitybit »

sargun wrote: post #56

I was a huge opponent of Rust, but finally decided to give it a try in anger once again. I began writing a large application, and noticed that many of my libraries only offered async versions, and the promise was quite appealing -- not having to worry about threads or concurrency as long as I followed certain rules. What I ended up with was an incredibly slow application because of the limitations of Rust async, and…

IO shouldn't be going to one thread, as far as I know. Blocking IO would go to a threadpool.

But you can just `block_on` your futures if you want and not think about it at all.

Post reply on HN