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

181–190 of 273 posts

Re: Async Rust never left the MVP state

#181

Post by tracker1 »

reallyreason wrote: post #171
jcelerier wrote: post #116

Earlier quoted context omitted.

But this fragmentation is what needed to make good software. If you put things in the standard library you're just adding a +1 to the fragmented landscape because for instance it will never be specialized enough to cover all use cases, so people will still use their own libraries, just like for instance c++ has three dozen distinct implementations of hash maps just because one cannot fit all cases

It could also be argued that putting a specific executor model into the standard library will make the problem worse because it will give library crates license to use it without considering alternatives because it is standard. At least today taking a dependency on a specific runtime is a well-known boondoggle .

Not only that, but there kind of is a defacto standard (tokio), which is pretty much the default if you aren't in a specific, resource constrained use case.

Re: Async Rust never left the MVP state

#182

Post by krzyk »

brabel wrote: post #89
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…

As you mentioned Java, it’s interesting to notice that it has had similar problems throughout its history: logging (now it’s settled on slf4j but you still find libraries using something else), commons (first Apache Commons, now Guava), JSON (it has settled on Jackson but things like Gson and Simple-json are not uncommon to see), nullability annotations ( first with unofficial distributions of JSR-305 which never bec…

commons, is something that is eventually being migrated into the main, at least those that are decided to be required for most projects. I don't use apache commons or guava at all in java (now at 25 or 26, depending on project) - there are still some libs that depend on those, but I would argue that most use it out of inertia, than actual need.

As for slf4j, I still don't see any justification for an abstraction layer on top of logging. I never, ever migrated from one logger to another, and even if I did need to do it - it is very easy as most loggers are very similar. E.g. that's why I decided to use log4j2 in my latest project.

Re: Async Rust never left the MVP state

#183

Post by tracker1 »

adastra22 wrote: post #176
staticassertion wrote: post #173

Earlier quoted context omitted.

I'm not prominent but I disagreed with it at the time and I was wrong.

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 also be...

    const v = await fetch(...).then(r => r.json());
In any case, it still gets ugly very quickly.

Re: Async Rust never left the MVP state

#184

Post by wrs »

vlovich123 wrote: post #155
Hendrikto wrote: post #121

Earlier quoted context omitted.

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.

Also that you have to rewrite the entire standard library, because the kernel knows how to suspend kernel threads on syscalls, but not green threads. (Go and Java already had to do this anyway, of course.)

Re: Async Rust never left the MVP state

#185

Post by tracker1 »

nixpulvis wrote: post #114
meowface wrote: post #101

Earlier quoted context omitted.

I am a beginner to Rust but I've coded with gevent in Python for many years and later moved to Go. Goroutines and gevent greenlets work seamlessly with synchronous code, with no headache. I know there've been tons of blog posts and such saying they're actually far inferior and riskier but I've really never had any issues with them. I am not sure why more languages don't go with a green thread-like approach.

One of Rust's central design goals is to allow zero cost abstractions. Unifying the async model by basically treating all code as being possibly async would make that very challenging, if not impossible. Could be an interesting idea, but not currently tenable. One problem I have with systems like gevent is that it can make it much harder to look at some code and figure out what execution model it's going to run with.…

They could still come in a step short of default executor and establish some standard traits/types that are typical across executors.

By providing a default, I think you're going to paint yourself into a corner. Maybe have one of two opt-in executors in the box... one that is higher resource like tokio and one that is meant for lower resource environments (like embedded).

Re: Async Rust never left the MVP state

#186

Post by J_Shelby_J »

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 it compiles you can check the binary to see if the panic handler was included. It’s hacky.

Yes you can lint out unwraps and other panic operations, but if there was a subset of no-panic rust a large part of the issue detailed in this post goes away. But it’s frustrating working with a language that has so many operations that can, in theory, panic even if in practice they should only do so if a bit flips. Like a proving an array is non-empty or working with async. You either end up with a lot of error handling for situations which will never happen or really strange patterns like non-empty list pattern (structure with first field and then your list). Which of course ends up adding its own bloat.

Re: Async Rust never left the MVP state

#187

Post by f_devd »

groundzeros2015 wrote: post #136
repelsteeltje wrote: post #57

Earlier quoted context omitted.

Beware, they are different concepts. Threads offer concurrent execution , async (futures) offer concurrent waiting . Loosely speaking, threads make sense for CPU bound problems, while async makes sense for IO bound problems.

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

Re: Async Rust never left the MVP state

#188

Post by jayd16 »

hacker_homie wrote: post #14
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…

I’m just waiting for them to try co-operative multithreading again.

That's what async/await is, no? Yielding by awaiting is co-operative.

Re: Async Rust never left the MVP state

#189

Post by dodobirdlord »

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…

Panicking is fairly important for ergonomics and safety. If panicking wasn’t available and execution had to proceed in all situations, recovering from a situation like memory corruption where invariants have been violated would require a lot of error handling anywhere an invariant is checked. This is exactly the sort of large amounts of error handling for situations that will almost certainly never arise than you are concerned about.

Re: Async Rust never left the MVP state

#190

Post by zozbot234 »

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. 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.

The Rust-in-Linux folks are working on this with things like failable memory operations. It's required for their own use. Increased use of proof (such as proving that an array is non-empty) is also being slowly worked on.

Post reply on HN