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

281–290 of 305 posts

Re: Why asynchronous Rust doesn't work

#281

Post by Too »

scotty79 wrote: post #114
tialaramex wrote: post #103

Earlier quoted context omitted.

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.

> Using Exceptions for things that aren't actually exceptional is perverse. In python using exceptions for some control flow is actually accepted practice if you don't go overboard. I think it's better that way because it turns them into something familiar instead of pushing them back to some extraordinary circumstances. The thing that C++ does with exception means that programmers mind is encouraged to stay on happy…

C++ exception handling is nothing special, it’s just surrounded by a lot of FUD, premature optimization, outdated benchmarks and cargo cult practices. Like you say, limited exposure adds to all this mystery around it.

If you follow “rule of zero” they just work. The problems come when you start implementing your own destructors “to handle exceptions”, which unfortunately seem to be a very common practice in the wild.

Re: Why asynchronous Rust doesn't work

#282

Post by native_samples »

mplanchard wrote: post #154
scotty79 wrote: post #127

Earlier quoted context omitted.

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.

Yes, doing big drops in a subthread is a good way of avoiding pauses when dropping large objects of any kind.

Which is, of course, largely what concurrent GC is about.

Re: Why asynchronous Rust doesn't work

#283

Post by native_samples »

throwaway894345 wrote: post #75
dgb23 wrote: post #70

Earlier quoted context omitted.

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

And you still run into all sorts of ergonomic issues when you inevitably need to dereference your Rc pointer. That said, I sympathize with the parent's desire for a proper Rust-lite with a GC: C-family syntax, great tooling, great documentation, great standard library and ecosystem, native+static compilation by default. Of course, someone will ignore those criteria and come in suggesting OCaml/Reason...

Take a look at Kotlin Native. It compiles to native code, the standard library is pretty good, and the latest versions have introduced a GC so it's now much easier to convert Java to it (Java can be rewritten into Kotlin automatically at the source level).

However I'd just use Graal native image. Most libraries work and it's far easier to write a config or tweak one that doesn't, than not have access to the library at all!

Re: Why asynchronous Rust doesn't work

#284

Post by xondono »

valenterry wrote: post #280
xondono wrote: post #105

Earlier quoted context omitted.

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 .

Well, without further ado that's true. But the callback could of course set a result type somewhere (so, behave similar to a future/promise) and then we could know if/when it is finished and if it was successfully, or if it's still running (or broke without an error). But that's not Rust specific, that's just plain language-independent logic no?

> But the callback could of course set a result type somewhere [..] then we could know if/when it is finished

That would be a Mutex, the author mentions it in the comments. This would solve the “writing at the same time issue”, but not the lifetimes, so you’d need another change.

Instead of trying the mess of implementing special closures, you could just make your db static.

Re: Why asynchronous Rust doesn't work

#285

Post by thinkharderdev »

chriskrycho wrote: post #208
thinkharderdev wrote: post #172

Earlier quoted context omitted.

With the modern JVM you actually have to work quite hard to write native code (Rust/C++/C) that outperforms an equivalent Java/Kotlin/Scala implementation. And it is quite easy to perform worse with a native implementation. Of course that is subject to various caveats: 1. Anything running on the JVM will need a 50-500ms of startup time. 2. The JVM implementation will not reach max performance until the runtime has op…

Those are some very large qualifications, though, right? I think a better way of saying this is something like “you actually have to work quite hard to write native code that outperforms an equivalent Java/Kotlin/Scala implementation for a specific kind of long-running process which can amortize the startup costs and the JIT time .” And that can be true! (Though in my experience naïve Rust often substantially outperf…

That's a fair point. But I think that "long-running processes which can amortize the startup cost and JIT time" covers a very large swath of software development.

Re: Why asynchronous Rust doesn't work

#286

Post by auggierose »

ModernMech wrote: post #272
auggierose wrote: post #216

Earlier quoted context omitted.

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?

Yes, I think Rust does get there. The thing of it is, I think people are measuring "time of development" differently. To some, the time developing a thing is the time spent writing it, and then getting it out the door. They often don't include things like fixing bugs that are discovered down the line and handled maybe by a completely different team. There's a difference between writing something and writing something…

I also don't use the m-word! Maybe Rust is for me after all.

Re: Why asynchronous Rust doesn't work

#287

Post by pjmlp »

tialaramex wrote: post #275
pjmlp wrote: post #261

Earlier quoted context omitted.

Rust's npm like approach to crates and micro approach to standard library make it a real problem, regardless of the quality approach to the standard library. You would have a point if the standard library was batteries included. When a language sells safety it has to go all in.

Cargo-geiger and similar tools allow you to audit crates you depend on to discover whether they're definitely safe. Of course just because some Rust is unsafe does not mean it's wrong, it just means that you're relying on it being correct as you have to with all code in unsafe languages.

Even those tools don't validate data corruption, using perfectly safe Rust accessing a table row from multiple threads without being protected from a transaction block or a table row lock.

Hence why doing blank statements like Rust prevents data races, without the context when that is actually 100% true, does no favours to the language advocacy.

Re: Why asynchronous Rust doesn't work

#288

Post by flohofwoe »

gpderetta wrote: post #218
flohofwoe wrote: post #57

I don't have any experience with async Rust (but I stuggled a lot with Rust's closures when I dabbled with Rust a while back so I can at least feel the pain the article tries to convey), but one important reason to not build async-await on top of fibers or threads but instead on code transformation (aka 'compiler magic') is 'weird architectures' like WASM, which doesn't have easy access to threading (locked behind CO…

I think you can implement fibers and continuations in WASM by converting the whole program into a giant switch statement and heap allocating frames. There are a few scheme-to-C compilers that do that I think. Mind, it is not going to be fast as it is going to be hard to generate efficient code ...

Emscripten actually has an "ASYNCIFY" feature which does exactly that but (AFAIK) down on the WASM level. It also has surprisingly little performance overhead.

Re: Why asynchronous Rust doesn't work

#289

Post by dnautics »

pcwalton wrote: post #274
dnautics wrote: post #266

Earlier quoted context omitted.

This is a very bad take. By your argument there's no reason why sel3 should exist, which is written in C and safer than rust.

Assuming you mean seL4, that was formally verified by taking a manual specification of the L4 kernel and laboriously proving that the C code implements that specification. That is not at all what the compiler's lifetime/borrow check subsystems do for Rust. They know nothing about what the program is supposed to do ; they only check that some relatively-simple rules are followed. That's why Rust requires so much less…

Nobody is arguing anything on the level of doing a full on Sel4 -- but

Sel4 does have generalized no memory leak, no uaf guarantees as a subset of all specification proofs, so my point "memory safely is possible to bolt onto even C" is still valid.

Re: Why asynchronous Rust doesn't work

#290

Post by [deleted] »

tptacek wrote: post #273
hitekker wrote: post #271

Earlier quoted context omitted.

The original article is just as inflammatory as its top comment if you’ve read it: > In 2017, I said that “asynchronous Rust programming is a disaster and a mess”. In 2021 a lot more of the Rust ecosystem has become asynchronous – such that it might be appropriate to just say that Rust programming is now a disaster and a mess. As someone who used to really love Rust, this makes me quite sad. I imagine withoutboats re…

I'm less comfortable projecting my own opinions into the head of 'withoutboats than you are. The author of the comment they responded to and the author of this post are not the same person.

[deleted]
Post reply on HN