Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#101

Post by Lhiw » Sat, Nov 13, 2021, 12:40 PM UTC

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…

> With that in mind, 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.

This is a really unfair call to make.

The author rightfully so goes to great lengths to avoid talking about those trade offs, specifically because they're irrelevant.

Async in rust is hard is the complaint.

It's not suggesting there aren't good technical reasons for it. Just that maybe implementing something that turned out to make a mess in the end wasn't the right move. Instead, maybe other options should have been explored.

The article listed what, 3 different ways to do Async?

You suggesting there isn't possibly a better way to do it because of zero cost trade offs is just gaslighting.

Re: Why asynchronous Rust doesn't work

#102

Post by jdub » Sat, Nov 13, 2021, 12:41 PM UTC

auggierose wrote: post #93

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

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.

Re: Why asynchronous Rust doesn't work

#103

Post by tialaramex » Sat, Nov 13, 2021, 12:42 PM UTC

quotemstr wrote: post #86

CodesInChaos wrote: post #47

Earlier quoted context omitted.

Rust has advantages over C#, even for high level programming: * Rust traits are more flexible than C# interfaces, especially when combined with generics (implementing traits for foreign types, associated types, each method can have its own constraints, conditional trait implementation, #derive) * Rust has much stronger thread safety guarantees (absence of data races, preventing access to a mutex's data without lockin…

I don't agree that people should avoid exceptions for expected errors. The idea that they should has twisted the error handling landscape into a pretzel and is responsible for some ugly bits of Rust design.

Exceptions are a mechanism for error handling that comes with control flow changes.

But Rust already has perfectly nice control flow mechanisms (look at std::ops::ControlFlow for example) and perfectly nice error handling. So you can use either, or both, as necessary, you don't need this particular Frankenstein's Monster.

Using Exceptions for things that aren't actually exceptional is perverse.

Re: Why asynchronous Rust doesn't work

#104

Post by jokethrowaway » Sat, Nov 13, 2021, 12:43 PM UTC

auggierose wrote: post #93

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

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't care about correctness or security use a low level unbounded language (eg. write C and triple check your code)

If you care about security, correctness and performance but don't care about developer speed, use Rust.

To be frank I find the point about developer speed in Rust to be a bit exaggerated, it's pretty high level and the tooling is pretty great.

- Compiler speed is a bit hit or miss - Debugging life cycles definitely take some time, but with time you get the hang of it and you can quickly copy paste previous solutions to the current problem. - You save a significant amount of developer time by fixing things alerted by the compiler instead of finding errors at runtime

All things considered Rust is definitely the language I feel more productive in (before it used to be Haskell).

Oftentimes considerations about hiring / collaborating with other developers take the precedence over security, correctness and performance.

Right now I'm maintaining a node.js project, 2 Python projects and a Rust project - mainly because node.js and Python worked best with those teams and the Rust one is a solo project.

Re: Why asynchronous Rust doesn't work

#105

Post by xondono » Sat, Nov 13, 2021, 12:54 PM UTC

valenterry wrote: post #39

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.

Why would the first example with the database be "shooting your own foot"? I'm not a Rust dev, but in other languages that code makes perfect sense to me.

For the same reason that keeping a shared excel file in a network disk is a bad idea.

The closure can write to database, and after the call, there’s no way to know if it has already written, or even if it’s writing to it right now.

Re: Why asynchronous Rust doesn't work

#106

Post by cesarb » Sat, Nov 13, 2021, 1:00 PM UTC

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…

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

You do all that work at the precise point where the last reference was dropped.

What people who complain about GC pauses dislike is the GC causing pauses in completely unrelated threads, including these threads that aren't even allocating or deallocating anything at that moment.

Re: Why asynchronous Rust doesn't work

#107

Post by tialaramex » Sat, Nov 13, 2021, 1:09 PM UTC

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…

One of the very particular "undebuggable" issues (safe) Rust solves is data races.

Experience tells us that humans can't successfully reason about non-trivial concurrent programs unless they exhibit Sequential Consistency. In Rust you're promised this is what you get. Maybe what you wrote is stupid and wrong, but it has Sequential Consistency. "Oh," you exclaim during debugging, "A might happened before B and then we're in a pretty pickle" - you found the bug, now you just need to fix it. This promise is delivered by never allowing code to have references to things some other code might change, thus eliminating data races.

In most other languages that offer concurrency this promise only applies if you wrote a program with no data races and the responsibility to ensure that is with you, so you can accidentally write programs that don't have Sequential Consistency and thus... "Wait, so, A happened before B and B happened before A? Huh? I don't even understand the bug".

Re: Why asynchronous Rust doesn't work

#108

Post by heftig » Sat, Nov 13, 2021, 1:23 PM UTC

throwaway894345 wrote: post #81

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…

> GC pauses, Rc does not, it's simply a deallocation by the last reference holder There are pauseless GCs (e.g., Azul for JVM), and Go kicked off a trend of super-low-latency GC. Also, RC deallocation is O(N) while GC is usually O(1) (ignoring pedantry about how RC is a type of GC). Further, RC can't handle cycles automatically. > Rc still has predictable memory allocation/deallocation, GC is not guaranteed to run un…

> RC deallocation is O(N)

What is N here? Number of allocations?

Re: Why asynchronous Rust doesn't work

#109

Post by scotty79 » Sat, Nov 13, 2021, 1:28 PM UTC

a_rustacean wrote: post #52

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…

`Rc` freezes the value as long as it's shared unless you use interior mutability. It's fine when you want to share immutable data, but if you ever need to mutate its contents you will have to deal with awkward cases and situations, and at runtime! Wrapping everything in `Rc` is not a good default strategy. Instead figure out an architecture that works well with the borrow checker! This normally means thinking hard ab…

I'll stick to my Rc's, thanks. Limiting yourself to immutable data is a good idea anyways for all scenarios where it is possible.

Re: Why asynchronous Rust doesn't work

#110

Post by couchand » Sat, Nov 13, 2021, 1:28 PM UTC

The author spills a lot of ink showing that they really didn't take any time at all to understand the problems they complain of.

The title is clickbait, of course aync Rust works, and the article doesn't talk about it anyway. The only mention of async is an observation that it's CPS under that hood, followed by a wandering rant about CPS that fails to account for the design constraints.

In the end, the author suggests forcing every AIO user to manually write out their polling loops, which is simply a silly idea. At least if their recommendation was a completion-based API without language support they would seem serious.