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

251–260 of 305 posts

Re: Why asynchronous Rust doesn't work

#251

Post by auggierose »

rackjack wrote: post #226
auggierose wrote: post #200

Earlier quoted context omitted.

For me, writing a program is mostly writing a bunch of libraries that I then put together. So I am consuming my libraries mostly myself. Therefore, for me it is important that both the library writing and the library using can be done efficiently. I assume that having a Rust library of something is a good thing. The question for me is: How easy and natural and quick is it to express a concept as a library in Rust?

Nobody can answer this question unless you tell us what kind of concepts and libraries you are writing. Sometimes Rust is handcuffs, sometimes it is guardrails, sometimes it is a rollercoaster track. It is impossible to tell without more information. You and the other guys are asserting things with basically no knowledge of the other's context.

If you say that "Rust sometimes is guardrails, sometimes it is handcuffs, sometimes it is a rollercoaster", that is already a lot of information. That's exactly what I want to avoid when implementing a concept: I don't want to be dependent on how well the type system fits my concept, because I am dealing with all sorts of concepts.

Re: Why asynchronous Rust doesn't work

#252

Post by pornel »

thibran wrote: post #232
pornel wrote: post #143

Earlier quoted context omitted.

Sorry to spoil your axe-grinding with hard data, but the Rust async ecosystem has exploded since 2019. It is now about 5-6 times larger than it was before async/await landing: https://lib.rs/crates/tokio/rev And Rust as a whole keeps growing exponentially: https://lib.rs/stats

That's not what I was talking about. Before async we had one ecosystem. Now we have at last three: non-async, Tokio, async-std My point is, the ecosystem experience has degraded since the async MVP is stabel.

You're conflating programming models with async runtimes, and weirdly attributing them to stabilization of a syntax sugar.

The split between blocking and non-blocking code existed in Rust before stabilization of async/await (e.g. futures 0.1 existed 3 years before, and mio is older than even Rust 1.0).

The only new thing is async-std, but that's not a stabilized part of Rust. It's just a 3rd party library. It may have been written anyway. It's relatively niche (1/10th of tokio), and you can safely ignore its existence (as far as I can tell every async-std-based crate supports tokio too, or has a direct tokio equivalent.)

I was worried that switch from futures 0.1 to std::future would fragment the ecosystem, but fortunately the whole ecosystem moved quickly, and the switch is completely over now.

Re: Why asynchronous Rust doesn't work

#253

Post by auggierose »

eximius wrote: post #219
auggierose wrote: post #200

Earlier quoted context omitted.

For me, writing a program is mostly writing a bunch of libraries that I then put together. So I am consuming my libraries mostly myself. Therefore, for me it is important that both the library writing and the library using can be done efficiently. I assume that having a Rust library of something is a good thing. The question for me is: How easy and natural and quick is it to express a concept as a library in Rust?

There are roughly two levels to the discussion: 1. Do you like strong type systems? If so, Rust us great! If you really would e itching for some python or JS, it may bother you, even though the Rust type inference really makes it a non-issue. 2. Do you care about allocations? One could be cheeky and rephrase it as "do you care about performance", but caring about allocations is one of the more advanced optimization c…

I see type systems as a necessary evil. Obviously, I like to be able to distinguish a 32 bit integer from a 64 bit integer or a String. And being able to define interfaces is important. But I am not a fan of modelling all sorts of high-level issues as a type system, because that always comes at a prize: When it works, it is great, and otherwise it really really sucks.

So yeah, Rc and stuff like that would bother me, because most of the time, these things are rather peripheral to what I am implementing.

I feel that, when performance is really really important, it is more important to be able to generate code on the fly, and I don't think Rust supports that.

But I haven't tried out ownership in Rust. I will have to work with it for a while to see if it bothers me or not.

Re: Why asynchronous Rust doesn't work

#254

Post by jude- »

eximius wrote: post #234
jude- wrote: post #231

Earlier quoted context omitted.

I'm not saying that we should go back to hand-rolling our own epoll loops. I'm saying that we can do better than async/await by making both the state machines and event loop explicit. For example, here's an API I'd prefer to use over async/await: /// A state machine that adds three numbers and uploads them to a web server struct AddAndUpload { /// I/O handle to the event loop io: IOClient, /// Buffer to store numbers…

okay, but that doesnt solve basically the main thing that async paradigms seek to solve: sharing of resources between waiting disjoint processes. your statemachine blocks the thread. if you had a more complicated state machine, maybe nested machines, theyd block each other because they dont know how to cooperate.

This code is just an example. The state machine can easily run in its own thread, separate from the main thread. As long as the state machine had an IOClient instance that lets it send I/O requests to the IOServer and receive I/O results, you're good. Also, you could imagine an IOClient having an API that takes a StateMachine instance as input, and returns an IOClient::Future that resolved to the machine's main() return value.

Re: Why asynchronous Rust doesn't work

#255

Post by metaltyphoon »

GordonS wrote: post #65
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.

Hmm, C# is my main language, and I don't think I've had an issue like you describe since back when async/await was new and I was still learning about it. And nowadays, Roslyn analyzers, like those in VS and Rider, will warn you about many problems.

Doing c# for over 9 years. I never ran into async/await issue that everyone seems to encounter. I’ve used it from creating libraries, CLIs, WPF, Winforms and doing web server with ASP.

Re: Why asynchronous Rust doesn't work

#256

Post by tialaramex »

pjmlp wrote: post #220
tialaramex wrote: post #217

Earlier quoted context omitted.

But (unless you've got an excerpt that says otherwise) the Rustonomicon is about unsafe Rust. And I was explaining that safe Rust has data race freedom. The Rustonomicon is not warning you about scary hidden problems in safe Rust, it's warning you about scary problems you need to care about when writing unsafe Rust, so that your unsafe Rust has appropriate safety rails before anybody else touches it. // Safety: Can't…

You as a user of a crate deemed safe, that underneath uses shmem, mmap, or a database, written without taking the proper care to prevent other processes to change exactly the same underlying data segment, written in what knows what, are in for a surprise and long debugging sessions. The crate public API surface is safe after all, and unless the user has experience in distributed systems, the answer won't come right a…

But this hypothetical "written without taking the proper care" code is buggy. Like I said it's just the same situation as a bad implementation of Index but more convoluted.

Rust's standard library takes this very seriously. In many languages if I try to sort() things which refuse to abide by common sense rules like "Having a consistent sort order" the algorithm used may blow up arbitrarily. But Rust's sort() is robust against that. You may create an infinite loop (legal in Rust, causes Undefined Behaviour in C++) and the result of sorting things without a meaningful ordering is unlikely to be helpful if it does finish, but it's guaranteed to be safe, you won't get Undefined Behaviour.

Re: Why asynchronous Rust doesn't work

#257

Post by khimru »

auggierose wrote: post #216
ModernMech wrote: post #207

Earlier quoted context omitted.

> 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. Rust has a long learning curve that most people won’t make it through. For them, they might feel the language is slow to developenin because they haven’t gotten to the point where they are “thinking” in Rust. As a Haskeller, you are well suited to learn Rust; due to their simil…

That's an interesting take on Rust. Given that I have written a lot of code in Standard ML, I might give Rust a try after all. GP's statement "If you care about security, correctness and performance but don't care about developer speed, use Rust." threw me a little off here. Because, Standard ML is very quick and easy to develop in. So should Rust not inherit that property?

It's very easy and simple to write Rust in Rust. Compiler is your friend and helps you all the time.

It's possible to write C++ or Java or Haskell in Rust but then compiler becomes your enemy and you fight it at every turn.

Re: Why asynchronous Rust doesn't work

#258

Post by rackjack »

auggierose wrote: post #251
rackjack wrote: post #226

Earlier quoted context omitted.

Nobody can answer this question unless you tell us what kind of concepts and libraries you are writing. Sometimes Rust is handcuffs, sometimes it is guardrails, sometimes it is a rollercoaster track. It is impossible to tell without more information. You and the other guys are asserting things with basically no knowledge of the other's context.

If you say that "Rust sometimes is guardrails, sometimes it is handcuffs, sometimes it is a rollercoaster", that is already a lot of information. That's exactly what I want to avoid when implementing a concept: I don't want to be dependent on how well the type system fits my concept, because I am dealing with all sorts of concepts.

Ok. Sometimes Rust fits good, sometimes it fits bad. If you don't want to deal with that, that's fine. I don't want to deal with memory leaks and stuff, so I use Rust instead of C/C++ when low-level, and I deal with the bad fits.

I'd still recommend learning Rust though. I find the way (the clean ways, not the ugly ways like Weak/Cell/etc.) it forces you to structure your programs is a very useful pattern when dealing with unrigid code like in C or C++, since its performance is near those languages. Then when coding C/C++ you can just break out of that pattern when you need to (e.g. self-referential structs).

BTW, what languages do you usually work with? I've been eyeing up Zig since it's nearly adjacent to C, but I'm waiting until stabilization.

Re: Why asynchronous Rust doesn't work

#260

Post by lelanthran »

jsiepkes wrote: post #17
fulafel wrote: post #13

Excellent post. Async ruins everything even in GC languages. It's just making things needlessly hard for programmers in an attempt to save effort from computers. Erlang shows how to do massive scales of slow IO if you really need it (most programs don't).

> It's just making things needlessly hard for programmers in an attempt to save effort from computers. Well actually it is supposed to make concurrency easier for programmers. What would you say is an "easy" way to deal with concurrency? Handle threading, memory visibility issues, locking, etc yourself? Doing it "reactive"? I guess personally I too would say something messaging based such as the actor pattern but not…

> What would you say is an "easy" way to deal with concurrency? Handle threading, memory visibility issues, locking, etc yourself?

Message queues, with workers atomically reading messages of a single queue, and placing responses on another queue.

Sure, it's not as flexible as starting threads[1], but 99 times out of a 100 you can use message queues and there's literally no race condition to happen, no memory visibility issues, no locking, etc.

[1] Some solutions, such as those that games employ, are rarely able to implement concurrency with just message queues, but to be honest if your problem is such that you can only employ solutions that require global state to be modified by several threads, then Rust, and similar 'safe' languages aren't usable there either.

Post reply on HN