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

Building a shared vision for Async Rust

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 139 posts

Re: Building a shared vision for Async Rust

#71

Post by h0l0gr4ph1c »

geofft wrote: post #52
kmeisthax wrote: post #47

Earlier quoted context omitted.

In Rust, you don't need to do this. If you want a blocking version of a non-blocking function, you spin on poll. Several async libraries ship a block_on function that does just that. If you can't do that, but don't want to bring in a proper big-boy executor; you can spin off another thread, have it block, and join it when it's done. (or use something like crossbeam's scoped threads) Colored functions are a problem in…

Well, 'Animats expresses a desire in another comment for functions not to go off and spawn a new thread. I do somewhat agree with that desire - I don't think that this is a problem for performance , but since most of my use of Rust is dropping it into existing C code, I think that spawning a thread is likely to have annoying visible side effects on the calling code, which might not be expecting me to do that. Using a…

> "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)"

Why do I need all this other bloat just to run a function? Why can't I just run the function?

Re: Building a shared vision for Async Rust

#72

Post by rng_civ »

millstone wrote: post #60
jayd16 wrote: post #21

Earlier quoted context omitted.

I think people want a language with C performance and are willing to sacrifice effort but not safety. Pouring effort into C++ does not guarantee safety. I think that's why something like Rust is desired.

I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support threads; so what is Rust bringing to the WASM table? I think it's a monoculture phenomenon. Rust has a website and a pitch; C++ does not. Rust has a single compiler and one way to do things; C++ is overly diverse. Rust has learned from npm, etc. and has made p…

> But WASM is already sandboxed

Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0]

IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic buffer overflow attacks. Rust still buys you safety in that regard.

[0] https://www.usenix.org/conference/usenixsecurity20/presentat...

Re: Building a shared vision for Async Rust

#73

Post by geofft »

h0l0gr4ph1c wrote: post #71
geofft wrote: post #52

Earlier quoted context omitted.

Well, 'Animats expresses a desire in another comment for functions not to go off and spawn a new thread. I do somewhat agree with that desire - I don't think that this is a problem for performance , but since most of my use of Rust is dropping it into existing C code, I think that spawning a thread is likely to have annoying visible side effects on the calling code, which might not be expecting me to do that. Using a…

> "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)" Why do I need all this other bloat just to run a function? Why can't I just run the function?

I'm not sure exactly what you're asking, but I think it's either answered by the "What color is your function?" article I linked above, or by the answer that this is exactly why unasync exists and why I suggested that approach is worth considering, or by the answer that you can, in fact, just run the function and the "bloat" (which is just syntactic bloat - note that performance is generally going to be better!) is taken care of behind the scenes by a wrapper that calls an executor for you.

Re: Building a shared vision for Async Rust

#74

Post by millstone »

dodobirdlord wrote: post #65
millstone wrote: post #64

Earlier quoted context omitted.

Does spin-on-poll imply actual spinning (100% CPU) or actual blocking (waiting in a syscall)?

That would have to be determined at the discretion of the implementer of the library. Rust is after all capable of being used to write code that will run in a context where there is no kernel and thus no syscalls.

I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?

Re: Building a shared vision for Async Rust

#75

Post by millstone »

rng_civ wrote: post #72
millstone wrote: post #60

Earlier quoted context omitted.

I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support threads; so what is Rust bringing to the WASM table? I think it's a monoculture phenomenon. Rust has a website and a pitch; C++ does not. Rust has a single compiler and one way to do things; C++ is overly diverse. Rust has learned from npm, etc. and has made p…

> But WASM is already sandboxed Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0] IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic bu…

Sorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code.

Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.

Re: Building a shared vision for Async Rust

#76

Post by millstone »

adwn wrote: post #69
millstone wrote: post #66

Earlier quoted context omitted.

How do you find Rust to be so much more productive than C++? I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight with typechecked generics, inserting & and '_ here or there, adding and deleting imports, refactoring to add Some and Ok - tons of nonsense housekeeping. These features have value but are quite a slog when writing code.

Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I wa…

I agree. In Rust I write correct code slowly. "Productive" I am not.

But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.

Re: Building a shared vision for Async Rust

#77

Post by shock »

BuckRogers wrote: post #70
Const-me wrote: post #8

I admire the passion, but I’m not sure why I would want Rust at all, not just async. When I want memory safety, async-await, I/O performance, easy multithreading, I write C#. When I want performance of CPU bound code, or lots of integration with native libraries/APIs, I write C++. Sometimes I want both in the same software, compile C++ code into a DLL (or shared library on Linux), and consume it from C#. I don’t have…

Downplaying Rust isn’t going to go over well in this thread. I happen to completely agree with you, but I would add or say that Rust is the first new programming language in a very long time that qualifies as technical innovation and not technical churn. Maybe the only one since Java. And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. But standing back and looking at the big list[0], only C…

> And I'm a C# guy, I wouldn't want to use anything else, it's Java done right.

It has colored functions. Every async function is turned by the compiler into a class with an embedded FSM. Async is viral in C#, so much so that even main() had to be made async. So, no, it's not Java done right.

Re: Building a shared vision for Async Rust

#78

Post by h0l0gr4ph1c »

geofft wrote: post #73
h0l0gr4ph1c wrote: post #71

Earlier quoted context omitted.

> "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)" Why do I need all this other bloat just to run a function? Why can't I just run the function?

I'm not sure exactly what you're asking, but I think it's either answered by the "What color is your function?" article I linked above, or by the answer that this is exactly why unasync exists and why I suggested that approach is worth considering, or by the answer that you can, in fact, just run the function and the "bloat" (which is just syntactic bloat - note that performance is generally going to be better!) is t…

yes sorry, those were rhetorical questions. Your point about asking you fail to see why not using a blocking executor to deal with the async code. My problem is with needing the executor at all. I must have skipped a couple of you previous pints in this thread. Apologies about that...

Maybe we should start trying to think about async as being something can use if they want and ignore if they want. Code being async compatible rather than async required.

Re: Building a shared vision for Async Rust

#79

Post by adwn »

millstone wrote: post #76
adwn wrote: post #69

Earlier quoted context omitted.

Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I wa…

I agree. In Rust I write correct code slowly. "Productive" I am not. But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.

> I agree. In Rust I write correct code slowly. "Productive" I am not.

I'm confused by that statement. Do you not care whether your code works correctly? Do you consider finding and fixing bugs to be separate from writing code?

Re: Building a shared vision for Async Rust

#80

Post by alfiedotwtf »

Animats wrote: post #26

The main thing I want for Async Rust is the ability to not use it. What I'm doing involves a virtual world viewer with maybe a dozen threads. Some are compute bound. Some are talking to the GPU. Some are waiting for I/O. The normal situation is about 2 or 3 CPUs of work. Sometimes more. I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy. Already I've had to switc…

> "Async" is a specialized tool for web servers with very large numbers of clients. Outside of that niche, it's seldom needed.

Web is just 2 ports out of the 65535 TCP/IP ports. Network servers can benefit from an async model depending on the server design.

Let’s not sweep all of networking into “web”.

Post reply on HN