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

91–100 of 236 posts

Re: A four year plan for async Rust

#91

Post by insanitybit »

CyberDildonics wrote: post #86
insanitybit wrote: post #57

Earlier quoted context omitted.

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…

I don't think that's what they are saying, I think that's what you're saying. I would be frustrated by that too, but I don't see any of that here.

Well they're responding to someone saying "Async is a wart".

Re: A four year plan for async Rust

#93

Post by [deleted] »

littlestymaar wrote: post #4
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.

> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation. No. This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single ot…

[deleted]

Re: A four year plan for async Rust

#94

Post by dymk »

cedws wrote: post #75
killercup wrote: post #30

Earlier quoted context omitted.

Because this code block looks quite complex, I want to add that it can also be just smol::block_on(async { println!("I'm async!"); }); (I thought tokio had a helper like this too but could only find `tokio::runtime::Runtime::new().unwrap().block_on(async { println!("I'm async!"); });`.)

Needing a helper library for something as simple as async so you don't go mental is really not good enough. I see the same thing with error handling - every Rust project I see imports a helper because it's too clunky otherwise.

Then use the code I posted if you don't want a helper library. Or just wrap it in your own function if it's too complex for your tastes.

Re: A four year plan for async Rust

#95

Post by jokethrowaway »

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…

That doesn't sound right. In which way was your application slow? Conceptually, async is not necessarily giving you parallelism but concurrency. Tokio (multithreaded) or async-std spawn N threads though and schedule your work for you.

It would be interesting to see the code or know which libraries you used (or even just what type of application you were building).

I built a heavy app using async-std and then rewrote it to threads just to better control what was each thread doing. Without my additional scheduling rules (which brought a lot of other benefits and helped performance in other ways), the performance between async and not async was close, with threads being marginally faster.

Re: A four year plan for async Rust

#96

Post by sapiogram »

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…

Could you be more specific about your bottlenecks? Were you not able use the multithreaded scheduler for some reason, or did it not work properly?

Re: A four year plan for async Rust

#97

Post by kroltan »

samus wrote: post #58
Verdex wrote: post #38

Earlier quoted context omitted.

> 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. Espe…

That list of bullet points (except the compiler one) is also applicable to the whole async ecosystem in Rust :)

Re: A four year plan for async Rust

#98

Post by kelnos »

echelon wrote: post #17
seanw444 wrote: post #10

Earlier quoted context omitted.

The point can be made equally well without the elitist condescension.

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.

It sounds like you are saying "I like Rust and want to be able to write it professionally, so shut up and stop criticizing it, regardless of how valid your criticism is".

That's no way to do good work.

Post reply on HN