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

31–40 of 139 posts

Re: Building a shared vision for Async Rust

#31

Post by throwaway81523 »

Animats wrote: post #29
bsder wrote: post #25

Earlier quoted context omitted.

> Is there any thought to including a default executor in the standard library? This is more difficult than you think, and you probably don't want the current async stuff to anchor to a weak implementation. For example, at least one of the current Rust async things doesn't work when pointed to UNIX/Linux character device file descriptors.

I hope not. Then it would be hard to turn async off. My general position on this is that all-async (like Javascript) is OK, and all-threaded is OK, and all green threads (like Go's goroutines) are OK. But those concepts do not play well together in the same program.

GHC is ok at mixing OS threads and green threads. You launch an OS thread if you want it to make blocking system calls etc. But from the user perspective it's just like a "normal" (green) thread, uses the same mutexes etc.

Re: Building a shared vision for Async Rust

#32

Post by songqin »

Animats wrote: post #30
songqin wrote: post #28

Earlier quoted context omitted.

Your comment touches on a few misconceptions I see a lot. Firstly, `reqwest` exposes both an async and a synchronous API, allowing the developer to choose which one to use. They are largely interchangeable code-wise. [1] Secondarily, and more broadly, async is possible to opt out of. You must understand that most web and network related libraries will be async by default for performance, because people who write in R…

"reqwest" exposes a synchronous API, but it's doing async stuff underneath. If you turn on logging, you can see 30 or so async events associated with a single HTTP client side request. It's starting up and shutting down a polling thread just to make one HTTP client request. You must understand that most web and network related libraries will be async by default for "performance" . That's what scares me - async contam…

I had understood your concern as wanting to avoid the complexity of asynchronous code execution in your codebase, I did not realize your concern is about writing very low level systems code. In that case, you are doing the right thing: libraries like ureq, minreq, Isahc, curl, and more all offer what you want.

It is unclear to me what you mean by keeping the community "in check". There are a lot of people who rely on and enjoy the async story, and they will continue to produce code that improves that story. Simultaneously, there are people who do not need that, and they are not hindered by this. People will build what they want and need. You've just picked some libraries from some of the biggest async contributors in the community and requested that they be kept in check so that you don't have to switch to a synchronous alternative, of which there are plenty.

Re: Building a shared vision for Async Rust

#33

Post by Const-me »

wffurr wrote: post #27
Const-me wrote: post #24

Earlier quoted context omitted.

> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C performance. The only large area where C# lags behind is SIMD. They made a good progress in .NET 3 and 5, but still somewhat worse than C/C++ with intrinsics. Here’s a library which implements media player component for ARM Linux: https://github.com/Const-me/Vrma…

C# ties you to CLR and is also garbage collected by default. That’s very different from C++ and Rust both.

> C# ties you to CLR

C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB.

> and is also garbage collected by default

By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.

Re: Building a shared vision for Async Rust

#34

Post by lmm »

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…

You want libraries to be able to offer implementations that are polymorphically async-or-not (perhaps using higher-kinded types). That's how I'm used to working in Scala.

Re: Building a shared vision for Async Rust

#35

Post by hda2 »

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…

> The main thing I want for Async Rust is the ability to not use it.

This is what many of us want. Sadly this doesn't seem to be a use-case many in rust are interested in supporting as a first class citizen (from what I've read at least).

I remember seeing someone being down-voted into oblivion for the mere suggestion of some sort of basic fallback executor in the standard library.

Rust's async story is a weird one.

Re: Building a shared vision for Async Rust

#36

Post by atweiden »

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…

I'd just like to mention popol here [1]:

    Popol is designed as a minimal ergonomic wrapper
    around poll, built for use cases such as peer-to-peer
    networking, where you typically have no more than a
    few hundred concurrent connections. It’s meant to be
    familiar enough for those with experience using mio,
    but a little easier to use, and a lot smaller.
[1]: https://cloudhead.io/popol/

Re: Building a shared vision for Async Rust

#37

Post by AgalmicVentures »

songqin wrote: post #32
Animats wrote: post #30

Earlier quoted context omitted.

"reqwest" exposes a synchronous API, but it's doing async stuff underneath. If you turn on logging, you can see 30 or so async events associated with a single HTTP client side request. It's starting up and shutting down a polling thread just to make one HTTP client request. You must understand that most web and network related libraries will be async by default for "performance" . That's what scares me - async contam…

I had understood your concern as wanting to avoid the complexity of asynchronous code execution in your codebase, I did not realize your concern is about writing very low level systems code. In that case, you are doing the right thing: libraries like ureq, minreq, Isahc, curl, and more all offer what you want. It is unclear to me what you mean by keeping the community "in check". There are a lot of people who rely on…

You're replying to John Nagle, as in https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm -- perhaps it would be worth considering his words further, before dismissing his concerns?

Surely we can all agree that spinning up unnecessary threads is undesirable?

Re: Building a shared vision for Async Rust

#38

Post by SAI_Peregrinus »

Const-me wrote: post #24
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.

> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C performance. The only large area where C# lags behind is SIMD. They made a good progress in .NET 3 and 5, but still somewhat worse than C/C++ with intrinsics. Here’s a library which implements media player component for ARM Linux: https://github.com/Const-me/Vrma…

Last I checked STM32 microcontrollers can't run .Net, and thus can't use C#. They can run Rust.

Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.

Re: Building a shared vision for Async Rust

#39

Post by geofft »

lmm wrote: post #34
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…

You want libraries to be able to offer implementations that are polymorphically async-or-not (perhaps using higher-kinded types). That's how I'm used to working in Scala.

This is also a problem over in Python-land. One of the interesting approaches is automatically generating non-async code from async code by editing out the async annotations (at the source level). The Trio folks call this "bleaching" the code, in reference to the "What color is your function?" blog post https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... complaining about how the common approach to async in JavaScript divides the world into "red" (async) and "blue" (sync) functions that interoperate poorly - you can bleach your code if it's the wrong color.

https://github.com/urllib3/urllib3/issues/1323 is a discussion of this. "Solution: we maintain one copy of the code – the version with async/await annotations – and then a little script maintains the synchronous copy by automatically stripping them out again. It's not beautiful, but as far as I can tell all the alternatives are worse.

https://github.com/python-trio/unasync is the current production implementation of this approach.

Re: Building a shared vision for Async Rust

#40

Post by jjtheblunt »

Animats wrote: post #30
songqin wrote: post #28

Earlier quoted context omitted.

Your comment touches on a few misconceptions I see a lot. Firstly, `reqwest` exposes both an async and a synchronous API, allowing the developer to choose which one to use. They are largely interchangeable code-wise. [1] Secondarily, and more broadly, async is possible to opt out of. You must understand that most web and network related libraries will be async by default for performance, because people who write in R…

"reqwest" exposes a synchronous API, but it's doing async stuff underneath. If you turn on logging, you can see 30 or so async events associated with a single HTTP client side request. It's starting up and shutting down a polling thread just to make one HTTP client request. You must understand that most web and network related libraries will be async by default for "performance" . That's what scares me - async contam…

Exactly
Post reply on HN