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

Why asynchronous Rust doesn't work

eta.st

Post reply on HN
Print view View original

91–100 of 305 posts

Re: Why asynchronous Rust doesn't work

#91

Post by diegocg »

999900000999 wrote: post #62

Maybe I'm stupid. But why is Rust so much harder than any other newish programs language. Dart is like all of my dreams come true at once, Rust still gives me nightmares. I seriously tried to learn it multiple times and failed repeatedly. I've created several Dart/ Flutter projects for myself and friends. Multiple C#/Unity projects. Python and JavaScript have paid my rent for the better part of a decade. But Rust, I…

> But why is Rust so much harder than any other newish programs language.

For one, Rust has manual memory management. You are aided by the type system and the compiler, but it's the programmer who has to deal with the mental load of thinking about the lifetime aspects of every variable. Compare to a GCed language, where you just free your mind and can focus on your program.

Re: Why asynchronous Rust doesn't work

#93

Post by auggierose »

Aissen wrote: post #15

It was heavily discussed previously. In particular, it triggered this response from Rust contributor withoutboats: https://news.ycombinator.com/item?id=26410487 And this blog post from someone who did spend a lot of time working with async rust: https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d...

Oh, thanks for that link. Withoutboats is being quite emotional, but it is understandable to be emotional about their brain child.

I am tempted from time to time to try Rust, but in the end, I don't think it provides enough benefits for me to consider it. I like high-level, and when I am going low-level, I don't want to be hand-cuffed. It seems with Rust, I am paying all the time just for the ability to go into hand-cuffed low-level mode.

Re: Why asynchronous Rust doesn't work

#94

Post by rad_gruchalski »

jsiepkes wrote: post #14
ungamedplayer wrote: post #11

Guess I'll just go back to erlang.....

There is also a actor pattern implementation for Rust: https://actix.rs/ But yeah, the way Erlang embededded the actor pattern in the VM (Beam) and the language itself is great. Tough personally I would have liked it if it was more statically typed. I still need to take a look at Gleam...

I love erlang but my problem with it is the app distribution model and runtime dependence. The language is really nice and simple.

Re: Why asynchronous Rust doesn't work

#95

Post by api »

xondono wrote: post #26

Maybe it’s only my take, but from what I understand, the author wants to easily create closures with mutable references and call them from anywhere, asynchronously? And the complaint is that Rust semantics makes this hard. Well yes, Rust makes it uncomfortable to shoot your own foot, that’s kind of the point.

The author wants Go, Java, C#, or another GC’d language.

Re: Why asynchronous Rust doesn't work

#96

Post by gameswithgo »

skohan wrote: post #77
kccqzy wrote: post #7

The article glosses over async Rust and is mostly a rant about how closures are difficult in Rust. Most of the difficulty comes from Rust not having a GC yet wishing to keep track of object lifetimes precisely: a GC'ed language needs no distinction between an ordinary function pointer and a closure that captures the environment. But Rust being a low-level systems language chose not to have a GC. Another popular langu…

I think it's not entirely fair to paint problems with rust's async features as an aversion to low-level-ness. If anything, I think the issue with Rust's async is that it tries to be too high level . In my experience with async rust, most of the difficulty comes from "spooky errors at a distance". I.e, you're writing some code which feels completely normal, and then suddenly you are hit with a large, obtuse error mess…

This may be a problem with async generally unless the language is designed specifically around async like Go is, which some profound tradeoffs to make it happen. (not criticizing that I think Go did a great job)

Re: Why asynchronous Rust doesn't work

#97

Post by api »

Speaking of the four versions of tokio in your build problem: this is definitely an issue with Rust dependencies. Async just magnifies it because there are a lot of async utility crates.

Personally I hate dependencies in general and try to minimize them. Instead of reaching for a utility crate I think “how could I architect this so I don’t need this hack?” There is almost always a way. In the end falling back on Arc is still cleaner and probably comes with less overhead than dependency spaghetti.

Re: Why asynchronous Rust doesn't work

#98

Post by skohan »

gameswithgo wrote: post #96
skohan wrote: post #77

Earlier quoted context omitted.

I think it's not entirely fair to paint problems with rust's async features as an aversion to low-level-ness. If anything, I think the issue with Rust's async is that it tries to be too high level . In my experience with async rust, most of the difficulty comes from "spooky errors at a distance". I.e, you're writing some code which feels completely normal, and then suddenly you are hit with a large, obtuse error mess…

This may be a problem with async generally unless the language is designed specifically around async like Go is, which some profound tradeoffs to make it happen. (not criticizing that I think Go did a great job)

I don't disagree. After working with Rust's model, which forces you to confront a lot of the tradeoffs and complexity, I'm more inclined to think async is a feature which should really be considered from the ground up when a language is being designed, to avoid painting oneself into a corner in the design space.

Re: Why asynchronous Rust doesn't work

#99

Post by dgan »

999900000999 wrote: post #62

Maybe I'm stupid. But why is Rust so much harder than any other newish programs language. Dart is like all of my dreams come true at once, Rust still gives me nightmares. I seriously tried to learn it multiple times and failed repeatedly. I've created several Dart/ Flutter projects for myself and friends. Multiple C#/Unity projects. Python and JavaScript have paid my rent for the better part of a decade. But Rust, I…

Anecdotally, I found Rust easier to grasp than OCaml..

Re: Why asynchronous Rust doesn't work

#100

Post by IshKebab »

Aissen wrote: post #15

It was heavily discussed previously. In particular, it triggered this response from Rust contributor withoutboats: https://news.ycombinator.com/item?id=26410487 And this blog post from someone who did spend a lot of time working with async rust: https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d...

To be fair withoutboats didn't really address any of the points that people make about the flaws of async Rust (e.g. the cancellation problem).

It may be the case that there's no good way to solve them, but that doesn't mean that they aren't problems and it doesn't really help to say that people who highlight them are totally wrong and don't know what they're talking about.

That said I think your second link does a much better job of explaining the issues than this post does.

Post reply on HN