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

121–130 of 305 posts

Re: Why asynchronous Rust doesn't work

#121

Post by gameswithgo »

skohan wrote: post #98
gameswithgo wrote: post #96

Earlier quoted context omitted.

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.

Rust could never have had easy async like Go, though, and maintain the control of performance that is the whole point of Rust.

Re: Why asynchronous Rust doesn't work

#122

Post by pornel »

microtonal wrote: post #56
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.

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? I think you are misunderstanding the author's point. I think that they'd probably agree that the (lack of) ergonomics of closures are a necessary result of the safeguards that Rust provides. They point is more that, given that closures have somewhat frust…

Rust has stopped depending on closures for async when it moved from experimental futures library to built-in async/await. Rust now easily supports mutable and temporary references in async blocks and across await points.

Rust still doesn't support use-after-free, so you can't reference a temporary object and use it in another thread that will outlive it :)

In TFA the second do_work_and_then() example doesn't compile, because it has a UAF vulnerability that borrow checker has detected and prevented.

Re: Why asynchronous Rust doesn't work

#123

Post by auggierose »

jdub wrote: post #102
auggierose wrote: post #93

Earlier quoted context omitted.

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

Nah, you're really not. Most of the time, particularly if you're not writing libraries, Rust feels like a dialect of Python that wants to help you get things right.

Well, 90% of what I am doing is writing libraries. I know how to get things right. Does Rust?

Re: Why asynchronous Rust doesn't work

#124

Post by jmull »

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 see this article as not understanding the goals and tradeoffs of Rust. The author would be happier writing in a higher-level language than Rust.

That's a pointless conclusion. The author's criticisms of Rust's tradeoffs are invalid because those are the tradeoffs Rust made. A perfect circle!

Re: Why asynchronous Rust doesn't work

#125

Post by kall »

wccrawford wrote: post #43
eska wrote: post #32

Earlier quoted context omitted.

Frontend or backend js? Because in the frontend everything is just scheduled to a single thread, so you only deal with concurrency, not parallelism.

"Modern" frontend JS is increasingly async. Yes, it's not true async, but it still has all the problems, but the benefit of not locking up the UI is worth the pain. Even old frontend JS was async in that events could be triggered by the user at any time, and in any order, and xhr and image loads requests were async as well.

Really the only sync actions in frontend I can think of are alert() calls and page navigations.

Re: Why asynchronous Rust doesn't work

#126

Post by skohan »

gameswithgo wrote: post #121
skohan wrote: post #98

Earlier quoted context omitted.

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.

Rust could never have had easy async like Go, though, and maintain the control of performance that is the whole point of Rust.

Yeah maybe not like go, but it's not impossible to imagine that you could create a language from the ground up with a rust-like ownership model and some async model - maybe not async await precisely.

Re: Why asynchronous Rust doesn't work

#127

Post by scotty79 »

quotemstr wrote: post #87
marcus_cemes wrote: post #50

Earlier quoted context omitted.

Correct me if I'm wrong, but: - GC pauses, Rc does not, it's simply a deallocation by the last reference holder - Rc still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed - More efficient memory use, no need to keep track of allocated objects - The rest of the Rust language is a pleasure to use (imo) - Python is slow for certain applications, and not concurrent - Kotlin is kin…

Naive synchronous reference counting can lead to large pauses as well. What happens when you drop the last reference to the root of a 10,000-node search tree? You do 10,000 reference deferments and free()s. Reference counting might feel more incremental than GC, but really is not. There are tricks you can use, but you're better off with a fast, modern, pauseless real GC that comes with tons of other benefits. Look: m…

I wonder if you could just pass this 10000 tree node root to another thread that will just drop it.

This should result in no pause for main thread.

Apparently you need Arc for that not Rc which shouldn't have much overhead over Rc in reasonable scenarios.

Re: Why asynchronous Rust doesn't work

#128

Post by qalmakka »

lordnacho wrote: post #71
hmrr wrote: post #12

Earlier quoted context omitted.

It’s a pain with GC as well, coming from a C# background. It’s incredibly easy to write something that intermittently doesn’t work in weird and impossible to debug ways.

> intermittently doesn’t work in weird and impossible to debug ways This is my major reason for using Rust. It's far better to beat your head against a wall when you're writing than when you're debugging. In both c++ and c# it's possible to write subtly wrong code that is basically undebuggable. Often these are intermittent things that show up once every million or more runs. There's no amount of time that will satis…

If you are very zealous and use lots of C++17/20 magic, you can prevent lots of runtime bugs with C++ too by doing basically the same stuff you do in Rust (RAII, move semantics, use concepts, etc). Sadly that's not doable in C#.

Re: Why asynchronous Rust doesn't work

#129

Post by scotty79 »

dgb23 wrote: post #70
scotty79 wrote: post #22

Earlier quoted context omitted.

From my very limited expeirience with Rust I noticed that it becomes way more easy and laid back language when you just skip using references and lifetimes nearly completely and just wrap everything in Rc . Then you are getting expeirience of fairly high level language with a lot of very cool constructs and features like exhaustive pattern matching and value types with a lot of auto-derived functionality. Does Rc hel…

Then you are essentially introducing a verbose, unoptimized garbage collector?

Yes. It's a kind of a garbage collector for people who don't need garbage collector.

If you need to do a lot of small allocation or have many circular references that you want to drop wholesale then you need a proper GC.

Even in some other cases you might benefit from proper GC. However Rust doesn't have a standard proper GC yet. It might have it as library some day. Some simple ones like https://docs.rs/gc/0.4.1/gc/ already exist.

But Rust is such a great language for many reasons. It would be a shame to not use it just because it doesn't have a great GC yet or because you don't have patience for borrow checker.

Re: Why asynchronous Rust doesn't work

#130

Post by auggierose »

jokethrowaway wrote: post #104
auggierose wrote: post #93

Earlier quoted context omitted.

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

I'd say seat belts more than handcuffs. When going low level it's easy to slip in memory leaks and security vulnerability. If you care about developer speed and security but don't care about correctness or performance you can rely on someone's else implementation and write higher level code (eg. use node and offload low level security considerations to node). If you care about developer speed and performance but don'…

I am currently using Swift, and I like it a lot. But you are kind of siloed into the Apple ecosystem. So I am looking for an alternative.

I am thinking TypeScript might give the biggest bang for the buck: * You have the widest possible reach via web apps & Electron * You have an eval/Function object for compiling code on the fly * You can embed low-level code via WebAssembly (and here Rust might be relevant for producing that WebAssembly) * If you need access to your TypeScript libraries on mobile, you can still do that via embedding a hidden WebView.

Post reply on HN