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

191–200 of 273 posts

Re: Async Rust never left the MVP state

#191

Post by positron26 »

J_Shelby_J wrote: post #186

I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. My understanding is that the panic handler is about 300kb, and the only way to exclude it is if your code has no paths that can panic when it compiles. And after i…

The OS running the program isn't even perfect.

I tire so much of complainers who want someone else to make all their tools infallible yet want to do nothing. Let's just full-stop there. They not only want to avoid working on the tools. They prefer if the tool does everything for them, and they prefer having things done for them without bound.

Complainers want easy APIs. When the API isn't easy enough, they want easy Kubernetes containers "programmed" by YAML. When that isn't easy enough, it's all point-and-click hosted services on GCP and Amazon. You people don't want to program. You want apps. Infallable apps. You want to be consumers, fed from the sky like little birds who endeavor only never to fledge, never to fly. And you want to pay nothing for it.

The secret you people need to figure out is that the lifestyle you think is sustainable is actually a commensal relationship with people building things for you. There is no vast alliance to wrest power from corporations, to dissolve capitalism, no grass roots movement to "shake things up." There is food falling from higher in the water column from an ecosystem filled with people who do things. Those above do not have time to look down, but if they did, all they would feel is overwhelming contempt, so they only look across at the horizon.

But why do people seek to confirm comments like this? Because Rust scary. Churn on, little ant mill. Let be free any who understand the pointlessness of this performance.

Re: Async Rust never left the MVP state

#192

Post by oxag3n »

If you read documentation around Rust Async and Tokio, you'll find proper explanation why CPU intensive parts should not be part of async stack, how to use primitives efficiently (like std::sync::Mutex in async blocks), how to glue sync and async code.

A lot of code doesn't follow there guidelines because they don't care about efficiency and don't need it. But there are numerous projects who care about performance and efficiency, and realize the pitfalls once code runs in production (ScyllaDB is one example).

LLMs don't help as well, generating everything async up to the main, using wrong primitives and not properly designing the system.

Re: Async Rust never left the MVP state

#193

Post by amluto »

mahkoh wrote: post #178
amluto wrote: post #156

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…

Because foo might call process::abort().

I disagree. If the codegen / optimizer is trying to preserve the rule that futures don’t have side effects until polled, then it seems fine to assume that the future being wrapped also follows that rule.

So if I call a foo() that violates the rule, it seems odd to complain that the generated bar() also violates it.

Re: Async Rust never left the MVP state

#194

Post by groundzeros2015 »

jandrewrogers wrote: post #174
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…

> So threads was the right programming model. It depends on what you are doing. Threads are the right model for compute-bound workloads. Async is the right model for bandwidth-bound workloads. Optimization of bandwidth-bound code is an exercise in schedule design. In a classic multithreading model you have limited control over scheduling. In an async model you can have almost perfect control over scheduling. A well-o…

If this is a classic exercise can you show me the material?

Why can’t a scheduler be written which optimizes around IO? What additional information is present in code that has async/await annotations?

Re: Async Rust never left the MVP state

#195

Post by ptx »

vlovich123 wrote: post #153
ptx wrote: post #55

Earlier quoted context omitted.

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.

No, JetBrains use Swing in IntelliJ IDEA. You can tell from how it (for example) fails to layout dialogs correctly the first time they're displayed, just like every other Swing application. And how windows have no minimum size because Swing doesn't expose that functionality. And the various baffling bugs involving window focus that are inherent to Swing applications.

Eclipse uses SWT instead, which wraps the platform's native widgets.

Re: Async Rust never left the MVP state

#196

Post by steveklabnik »

J_Shelby_J wrote: post #186

I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. My understanding is that the panic handler is about 300kb, and the only way to exclude it is if your code has no paths that can panic when it compiles. And after i…

> I don’t understand why Rust even has panics if its primary goal is safety.

Rust's goal is memory safety. Panics are perfectly memory safe.

Re: Async Rust never left the MVP state

#197

Post by groundzeros2015 »

vlovich123 wrote: post #154
groundzeros2015 wrote: post #48

Earlier quoted context omitted.

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…

Wait which programming model are you arguing is the low latency one? I thought you said it was JS because non-blocking.

Re: Async Rust never left the MVP state

#198

Post by groundzeros2015 »

f_devd wrote: post #187
groundzeros2015 wrote: post #136

Earlier quoted context omitted.

Why? You write the same code with async await but with a keyword at the beginning of every function.

Because if you go down the callstack eventually you won't get the await keyword anymore; you'll get the actual 'waiters' and 'wakers' which define your scheduling

Yeah. The OS handles scheduling and preemption so it’s done for you rather than a call in the stack.

Re: Async Rust never left the MVP state

#199

Post by adastra22 »

tracker1 wrote: post #183
adastra22 wrote: post #176

Earlier quoted context omitted.

I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?

Contrast it with async in JS/ES as an example... now combine it with the using statement for disposeAsync instances. await using db = await sqlite.connect(await ctx.getConfig("DB_CONN")); It's not so bad when you have one `await foo` vs `foo.await`, it's when you have several of them on a line in different scopes/contexts. Another one I've seen a lot is... const v = await (await fetch(...)).json(); Though that could…

I’ve never in my life used JS, so I’ll have to take your word for it.

Re: Async Rust never left the MVP state

#200

Post by forrestthewoods »

swiftcoder wrote: post #40
forrestthewoods wrote: post #25

Love Rust. They simply missed the mark with async. Swing and a miss. The risk they took was very calculated. Unfortunately they’re bad at math and chose the wrong trade-offs. Ah well. Shit happens.

> Unfortunately they’re bad at math and chose the wrong trade-offs They chose the exact same tradeoffs as C++'s async/await (and the same overall model as Python/NodeJS), so I'm not sure what that says about programming as a whole.

the C++ committee makes consistently god awful terrible decisions

Source: am professional C++ developer

Post reply on HN