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

201–210 of 305 posts

Re: Why asynchronous Rust doesn't work

#201

Post by pjmlp »

tialaramex wrote: post #179
pjmlp wrote: post #163

Earlier quoted context omitted.

Only for data races via threads on the same process, it does nothing to prevent data races via shared memory using IPC mechanisms across processes.

How so? Obviously you can build an unsafe IPC mechanism with concurrent access, label it "safe" when it isn't, and then say "Look at this horrible mess, I blame Rust" but it seems like it'd be faster to just implement std::ops::Index unsafely and then blame Rust because thing[len+1] blew up even though Rust has "memory safety". Now I'm going to write an amusing aside. One way you could get into this trouble is if you…

Because as explained on rustnomicon, there are many ways to access data in parallel ways, and the language only prevents a tiny subset of those cases.

However almost every time data races and Rust come together in the same sentence it is as if it would prevent all use cases.

Re: Why asynchronous Rust doesn't work

#202

Post by sweeneyrod »

scotty79 wrote: post #22
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…

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…

You can get those cool features in languages such as OCaml/F#/Scala/Haskell, and then you don't have to worry about managing memory because you have a GC.

Re: Why asynchronous Rust doesn't work

#203

Post by __s »

jude- wrote: post #199

"Maybe we could just have kept Rust as it was circa 2016, and let the crazy non-blocking folks write hand-crafted epoll() loops like they do in C++. I honestly don’t know, and think it’s a difficult problem to solve." I think this is the most underappreciated part of this article. Since when did everything have to be async? There are other ways to represent concurrency that more accurately reflect what the computer i…

> but the task of converting a high-level workstream into a state machine could be automated by the tooling

That tooling is literally async/await. async/await transforms functions into state machines

Re: Why asynchronous Rust doesn't work

#204

Post by ipodopt »

pornel wrote: post #122
microtonal wrote: post #56

Earlier quoted context omitted.

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

You can't do that using anything here?

https://doc.rust-lang.org/std/mem/index.html

Genuine question, I don't mess around with memory typically.

Re: Why asynchronous Rust doesn't work

#205

Post by brabel »

karmakaze wrote: post #150
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 don't use Rust but was curious if this was a real or imagined problem--it seems to be the latter. Two points: 1. the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function. Why is this not required anyway? i.e. How does Rust know/decide who owns the mut& db if both the closure and the function that creates the closure can reference it? 2. as mentioned,…

> the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function.

No. If you did that, you could only pass functions in that took the db as a closure argument, nothing else... you're thinking about this example only, and forgetting the problem is with the general case of capturing whatever is needed for the callback to work.

Re: Why asynchronous Rust doesn't work

#206

Post by staticassertion »

kortex wrote: post #178
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…

> Python is not an option for me, since I like static typing. Have you checked out mypy recently (past few years)? With all the strict flags, it's pretty damn hard to get anything but bulletproof static typed code to pass. The only major downside is it lacks higher kinded types at the moment, and there is a PR in the works to add that. But it has all of the other accoutrements you'd expect from a modern type system:…

There are way more downsides than that.

1. No recursive types, so you can't express a lot of basic things like a "Json" type. This ends up coming up a lot more than you might imagine.

2. Not great support for every pep ie: Protocol

3. Generics are extremely confusing in mypy. Generic classes suffer from the lack of recursive types I'd mentioned as well.

4. Implicit 'Any' everywhere unless you use the strictest settings, which I don't believe anyone does on real code because of the above issues. I've never once managed to get a real codebase to typecheck with mypy.

Honestly mypy works as a somewhat fancy linter, not as a type checker.

Re: Why asynchronous Rust doesn't work

#207

Post by ModernMech »

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

> 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 similar ML lineage (the original Rust compiler was written in OCaml), Rust and Haskell make some similar design considerations. I’d say one thing Rust does right is take a lot of the things that make Haskell safe and make them fit in an imperative language.

Re: Why asynchronous Rust doesn't work

#208

Post by chriskrycho »

thinkharderdev wrote: post #172
throwaway894345 wrote: post #80

Earlier quoted context omitted.

While I understand that with Graal and .Net you can ostensibly make native, static binaries for Kotlin or C#, I'm very skeptical that it works well in practice. In particular, I'm guessing it will feel like swimming upstream, fighting an ecosystem and build tooling which mostly assume you're running on a VM. And then there's the question of performance... And of course, with Python your code will run 100x slower than…

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 outperforms naïve Java/C#/etc.)

The other thing is that true warmup (not just startup) time to reaching optimization is a lot weirder and less predictable than people realize. See e.g. [1] and [2] for a fascinating analysis (caveat: about a decade old) of the actual warmup characteristics of a number of different VMs (Graal, HHVM, HotSpot, LuaJIT, PyPy, TruffleRuby, and V8). Spoilers: there are bizarre deopt cliffs, scenarios where it appears to optimize and then de-optimizes if you run it long enough, and programs which just never optimize… and this is on benchmark tests!

[1]: https://tratt.net/laurie/blog/entries/why_arent_more_users_m...

[2]: https://tratt.net/laurie/blog/entries/why_arent_more_users_m...

Re: Why asynchronous Rust doesn't work

#209

Post by md8z »

convolvatron wrote: post #198
md8z wrote: post #174

Earlier quoted context omitted.

IME, using reference counts there is also not a good idea. In practice I think it's better to treat async tasks just like goroutines and then use channels to communicate.

I've found that when I've structured things that way in the past I do have some performance issues if the grain is very small. more importantly to me is that those machines dont really compose that well over larger scales - that is to add a new component I need to look at the overall scheduling and connectedness of the existing components and need to rework them to order to handle a new control flow. it is a nice mod…

By default I think the simplest model is to just use references, that should work if you don't move anything into the async task.
Post reply on HN