Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async Rust never left the MVP state

tweedegolf.nl

Post reply on HN
Print view View original

151–160 of 273 posts

Re: Async Rust never left the MVP state

#151

Post by surajrmal »

ignoreusernames wrote: post #66

Agree with the other commenters that the title is a bit too dramatic. The content was well written and got the point across. I still don’t have enough experience to have a strong opinion on Rust async, but some things did standout. On the good side, it’s nice being able to have explicit runtimes. Instead of polluting the whole project to be async, you can do the opposite. Be sync first and use the runtime on IO “edge…

It's very much possible to use rust for a lot of areas with async without needing to be dependent on tokio. I think it's really just the web/server stuff that's entirely tokio dependent. Writing libraries to be executor agnostic is not terribly difficult but does require some diligence which isn't necessarily present in most of the community.

Re: Async Rust never left the MVP state

#152

Post by groundzeros2015 »

Salgat wrote: post #150
groundzeros2015 wrote: post #4

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right program…

Awaiting allows you to efficiently yield the thread to other tasks instead of blocking it. That's one of its biggest advantages.

When you block the OS does the same thing - yields to other threads.

Re: Async Rust never left the MVP state

#153

Post by vlovich123 »

ptx wrote: post #55
vlovich123 wrote: post #23

Earlier quoted context omitted.

Well, if you offload heavy compute into an async task, then usually it depends strictly on how many concurrent inputs you are given. But even something as “simple” as a performance editor benefits from this if done well - that’s why JS text editors have reasonably acceptable performance whereas Java IDEs always struggled (historically anyway since even Java has adopted green threads).

Are you sure Java's UI issues are caused by threading and not just Swing being a glitchy pile of junk? For example, if you don't explicitly call the java.awt.Toolkit.sync() method after updating the UI state (which according to the docs "is useful for animation"), Swing will in my experience introduce seemingly random delays and UI lag because it just doesn't bother sending the UI updates to the window system.

only netbeans is written in swing . Eclipse and Jetbrains use their own thing and still generally struggled.

Re: Async Rust never left the MVP state

#154

Post by vlovich123 »

groundzeros2015 wrote: post #48
vlovich123 wrote: post #38

Earlier quoted context omitted.

Why do you think they don’t struggle with input latency? Because the non blocking nature built into the browser model is so powerful and you cannot get that with threads.

I disagree with the premise. I cannot imagine a better latency experience than blocking loop IDEs like VS6. Which inputs are getting latency? The keyboard? The files? > the non blocking nature https://youtu.be/bzkRVzciAZg?si=BuBXxHTgN0OqsAhI

Hate to break it to you but windows gui programming, emblemified by VS6, is about as far away from a blocking threaded model as you get. You literally have a UI event loop and any compute intensive work is meant to be offloaded to other threads via messages/COM. This is why when they failed to do that correctly the entire UI would lock up - because they didn’t have good hygiene around how to offload compute intensive operations that also interacted with the GUI.

You’ve literally argued against yourself without realizing.

Re: Async Rust never left the MVP state

#155

Post by vlovich123 »

Hendrikto wrote: post #121
LelouBil wrote: post #109

Earlier quoted context omitted.

Can you explain more ? I always heard this.

The most promiment example is probably Go with its goroutines, but there are so many more. You can easily spawn tens of thousands of goroutines, with low overhead and great performance.

I thought it was obvious from context: OS threads are too heavyweight for fine grained concurrency

Go uses userspace threads. It’s also interesting that Go and Java are the only mainstream languages to have gone this route. The reason is that it has a huge penalty when calling FFI of code that doesn’t use green threads whereas this cost isn’t there for async/await.

Re: Async Rust never left the MVP state

#156

Post by amluto » 

    async fn bar(input: u32) -> i32 {
        let blah = input > 10; // Preamble
        let result = foo(blah).await;
        result * 2 // Postamble
    }
> If only we were allowed to execute the code up to the first await point, then we could get rid of the Unresumed state. But "futures don't do anything unless polled" is guaranteed, so we can't change that.

Is that actually valid reasoning? If we know that foo(blah) doesn’t do “anything” until polled, then why can’t bar call foo without polling it before foo itself is polled? After all, there’s no “anything” that will happen.

Re: Async Rust never left the MVP state

#157

Post by satvikpendem »

treyd wrote: post #130
K0nserv wrote: post #64

Earlier quoted context omitted.

There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`. For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2] I…

Keyword generics are probably not happening because it's kinda a hack. Algebraic effects are the way forward, but that's a long way off.

Yes I hope in the future we can get to what OCaml 5 has with their algebraic effects system, and hopefully fix any flaws we see in there, so that async will just be syntactic sugar over the underlying effects system.

Re: Async Rust never left the MVP state

#158

Post by Salgat »

groundzeros2015 wrote: post #152
Salgat wrote: post #150

Earlier quoted context omitted.

Awaiting allows you to efficiently yield the thread to other tasks instead of blocking it. That's one of its biggest advantages.

When you block the OS does the same thing - yields to other threads.

And how much slower is that? What happens when I run a thousand async tasks? I'll give you a hint, with async/await, it has barely any overhead.

Re: Async Rust never left the MVP state

#159

Post by vlovich123 »

groundzeros2015 wrote: post #33
vlovich123 wrote: post #28

Earlier quoted context omitted.

That’s incorrect. Even when expressed suboptimally, it still tends to result in overall higher throughput and consistently lower latency (work stealing executors specifically). And when you’re in this world, you can always do an optimization pass to better express the concurrency. If you’ve not written it async to start with, then you’re boned and have no easy escape hatch to optimize with.

Why can’t you do the same optimization? Are you maxing out you OS system resources on thread overhead?

That’s part of it. Then you add a thread pool to dispatch your tasks into to mitigate the cost of a thread start. Then you run into blocking problems and are like “I wish I had some keyword to express when a function needed to be run on the thread pool”. Then you’ve done a speed run of the past 40 years of research.

Re: Async Rust never left the MVP state

#160

Post by satvikpendem »

Rust in my opinion needs an algebraic effects system to truly fix the function coloring problem. We have OCaml 5 which has one in production as well as a few other languages like Koka experimenting with it but hopefully we can add that to Rust as well. I'm not sure how the keyword generics initiative is going though, haven't heard any news on that.
Post reply on HN