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

Inside Rust's Async Transform

blag.nemo157.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: Inside Rust's Async Transform

#51

Post by markdog12 »

skybrian wrote: post #38
2bitencryption wrote: post #27

Async/await pattern always confuses me, someone please let me know if I get this right: First, async/await does NOT mean "threading" or "multiprocessing" or "concurrency". It simply means "using a state machine to alternate between tasks, which may or may not be concurrent." Right? Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events)…

Incremental computation can be useful for better responsiveness even if you only have one thread. A simple example in JavaScript would be a Mandelbrot viewer, where you don't want to lock up the UI doing a heavy computation. So, you could have something that looks like an async call that really does the heavy computation in small chunks using idle callbacks, and the future completes when it'd done. (Using a backgroun…

Concrete example right on the Dart homepage: https://www.dartlang.org/

Re: Inside Rust's Async Transform

#52

Post by sifoobar »

int_19h wrote: post #50
sifoobar wrote: post #48

I'll take fibers that yield automatically on blocking operations over async/await most days for most tasks. It's slightly less flexible, since you can only wait for one async action at a time per fiber; but a pleasure to use in comparison. But for that you need fibers built in. Go sort of does the same thing, but insists on running fibers in separate threads at its convenience; which means giving up the lovely simpli…

The problem with fibers is interop. The moment you need to do some FFI, especially FFI that involves callbacks, things get a lot more complicated, since code you're calling into/through doesn't have any of that fiber magic (and, depending on how you implemented yours, it might actually break it).

Another win for embedded languages/inside-out FFI in my book, since controlling the outside world (C in Snigl's case) makes it trivial to register a trampoline with whatever state needed to deliver the call.

Re: Inside Rust's Async Transform

#53

Post by ghusbands »

int_19h wrote: post #49
2bitencryption wrote: post #27

Async/await pattern always confuses me, someone please let me know if I get this right: First, async/await does NOT mean "threading" or "multiprocessing" or "concurrency". It simply means "using a state machine to alternate between tasks, which may or may not be concurrent." Right? Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events)…

Look into continuation-passing style. Semantically , async/await is much like syntactic sugar for CPS (or rather futures, but at the most basic level they can be thought of as single-shot continuations). But ultimately, to make use of async, you need async primitives - something that lets you say "do this in the background somehow, and let me know once you're done". Any async/await call should ultimately end at one o…

It's only semantically CPS in as much as all code is semantically CPS. Thinking about the parallels with CPS does nothing to help, here. Async/await is just like threaded code with the blocking/concurrent calls specially marked.

Re: Inside Rust's Async Transform

#54

Post by throwaway487552 »

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work?

It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code.

My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to gain more momentum, etc) rather than tech per se.

To have a select and receive as a language constructs (with pattern matching, of course) and coroutines (basically, software interrupt handlers) is a much better approach for a system programming language, just by being close to a system.

Universal frameworks like tokyo or async/await is cancer and , it seems, does not suit a system language at all.

Re: Inside Rust's Async Transform

#56

Post by steveklabnik »

throwaway487552 wrote: post #54

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work? It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code. My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to…

Those lose zero-overhead interop with C, which is a core constraint for Rust.

Your guesses are incorrect.

Re: Inside Rust's Async Transform

#57

Post by throwaway487552 »

steveklabnik wrote: post #56
throwaway487552 wrote: post #54

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work? It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code. My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to…

Those lose zero-overhead interop with C, which is a core constraint for Rust. Your guesses are incorrect.

> lose zero-overhead interop

How many LOC is tokyo nowadays?

Re: Inside Rust's Async Transform

#58

Post by bfrydl »

throwaway487552 wrote: post #54

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work? It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code. My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to…

It isn't about “memes” or “ignorant coders.” Please grow up.

The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions. In order for a goroutine to suspend and resume at arbitrary points in otherwise normal functions, each goroutine needs its own stack. This is convenient but comes at a cost, and I certainly wouldn't say that it matches reality or is close to the system.

The way Rust implements async ensures that there is zero overhead. You can think of the compiler as constructing an elaborate state machine. Each task is a normal structure in memory, just a few bytes rather than an 8 kb stack. This means that by paying the cost of dealing with a somewhat invasive language feature, Rust async code is more efficient than the equivalent Go code.

This is part of Rust's core design. The language should be as convenient or productive as possible, but never at the cost of performance or efficiency even if that cost is very small.

Re: Inside Rust's Async Transform

#59

Post by throwaway487552 »

bfrydl wrote: post #58
throwaway487552 wrote: post #54

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work? It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code. My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to…

It isn't about “memes” or “ignorant coders.” Please grow up. The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions. In order for a goroutine to suspend and resume at arbitrary points in otherwise normal functions, each goroutine needs its own stack. This is convenient but comes at a cost, and I certainly wouldn't say that it matches reality or is close to the system. The wa…

If "zero-cost abstractions" and "zero overhead" are not memes, then what memes are?

> I certainly wouldn't say that it matches reality or is close to the system.

The call assembly instruction uses stack, the ret uses stack. Procedures therefore are hardware-assisted stack-based entities. So are interrupt handlers, which are specialization of a procedure. These are the right abstractions to use for fine-granded modularity exactly because they are hardware-assisted and stack-based. Threads are the wrong abstractions (Erlang authors explains why).

I have zero interest to investigate the rest of your claims, but I think they are unsubstantiated as the one above.

Re: Inside Rust's Async Transform

#60

Post by bfrydl »

throwaway487552 wrote: post #59
bfrydl wrote: post #58

Earlier quoted context omitted.

It isn't about “memes” or “ignorant coders.” Please grow up. The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions. In order for a goroutine to suspend and resume at arbitrary points in otherwise normal functions, each goroutine needs its own stack. This is convenient but comes at a cost, and I certainly wouldn't say that it matches reality or is close to the system. The wa…

If "zero-cost abstractions" and "zero overhead" are not memes, then what memes are? > I certainly wouldn't say that it matches reality or is close to the system. The call assembly instruction uses stack, the ret uses stack. Procedures therefore are hardware-assisted stack-based entities. So are interrupt handlers, which are specialization of a procedure. These are the right abstractions to use for fine-granded modula…

lol how boring do you have to be to troll engineers

it's like if an accountant tried to start internet fights over what kind of rounding is best

Post reply on HN