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

21–30 of 139 posts

Re: Building a shared vision for Async Rust

#21

Post by jayd16 »

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…

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.

Re: Building a shared vision for Async Rust

#22

Post by Ar-Curunir »

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…

Nobody’s forcing you to use Rust, you can just ignore it.

Re: Building a shared vision for Async Rust

#23

Post by fpgaminer »

steveklabnik wrote: post #15
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…

Not everyone needs to use Rust. If you don’t have a desire to, that’s 1000% okay! I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic?

> I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic?

It doesn't follow the HN guidelines: "Have curious conversation" and "Comments should get more thoughtful and substantive". It doesn't add to the discussion about Rust's async story.

Re: Building a shared vision for Async Rust

#24

Post by Const-me »

jayd16 wrote: post #21
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…

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/Vrmac/tree/master/VrmacVideo#per... It calls native code to present decoded video frames with GLES, and decode audio with third-party DLLs. Also consumes kernel C APIs like V4L2, ALSA, message queues from librt.so, and a few things from libc.so. Everything else is in C#: file I/O, containers parsing, decoders configuration, multithreading, buffering, A/V sync. The performance is same as VLC player which is written in C.

Re: Building a shared vision for Async Rust

#25

Post by bsder »

scudd wrote: post #7

Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it. I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107 This makes sense to me; however, I fe…

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

Re: Building a shared vision for Async Rust

#26

Post by Animats »

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 switch from using "reqwest", which now seems to always bring in tokio, to "ureq", a minimal HTTP client. The way to do HTTP requests used to be with "hyper", but that became a lower level for "reqwest", and then "tokio" was slipped in underneath to make it "async". It always uses async, even if you make a blocking request.

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

Re: Building a shared vision for Async Rust

#27

Post by wffurr »

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…

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

Re: Building a shared vision for Async Rust

#28

Post by songqin »

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…

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 Rust and people who write web servers typically care greatly about performance. This is the intersection of those two groups. That being said, there are options outside of that ecosystem. [2]

If you truly want to use an asynchronous library without migrating your application to run entirely on an async runtime like tokio, you can run it inside of a synchronous function without much trouble. I've put together a playground link for you. [3]

1. https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html

2. Iron: https://github.com/iron/iron Rouille: https://github.com/tomaka/rouille

3. https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Building a shared vision for Async Rust

#29

Post by Animats »

bsder wrote: post #25
scudd wrote: post #7

Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it. I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107 This makes sense to me; however, I fe…

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

Re: Building a shared vision for Async Rust

#30

Post by Animats »

songqin wrote: post #28
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…

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 contamination of the low level Rust ecosystem. The async enthusiasts have to be kept in check to prevent breaking Rust as a systems language.

Post reply on HN