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

61–70 of 139 posts

Re: Building a shared vision for Async Rust

#61

Post by millstone »

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 would not think to consider C# outside of Windows, but maybe I am wrong and should update my priors.

Are there any C# programs that are regularly used ex-Windows? Something analogous to Docker (written in Go) or ripgrep (written in Rust)?

Re: Building a shared vision for Async Rust

#62

Post by Animats »

h0l0gr4ph1c wrote: post #54
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…

Complexity kills code. Being able to reason about what your code is doing, is FAR more valuable to me than async. Having tokio act as my runtime and switch tasks as it sees fit will be debug hell. The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in. As in, the code works regardless of an async runtime, async is added magic if you want it, but it wi…

The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in.

That sums this discussion up nicely.

Re: Building a shared vision for Async Rust

#63

Post by adwn »

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…

> what is Rust bringing to the WASM table?

Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.

Re: Building a shared vision for Async Rust

#64

Post by millstone »

kmeisthax wrote: post #47
geofft wrote: post #39

Earlier quoted context omitted.

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

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

Re: Building a shared vision for Async Rust

#65

Post by dodobirdlord »

millstone wrote: post #64
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…

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.

Re: Building a shared vision for Async Rust

#66

Post by millstone »

adwn wrote: post #63
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…

> what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.

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.

Re: Building a shared vision for Async Rust

#67

Post by lmm »

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…

95% of people who think they want Rust should just be using OCaml or similar, IMO.

That said, Rust should mostly be as easy to write and debug as C# - if it's not, that's a problem to be fixed. And interop between two languages causes more subtle issues that you don't notice - your architecture ends up distorted, refactoring across the interop boundaries is painful. I used to work on mixed C++/Python projects and thought I was getting the best of both worlds - it was only when I didn't have to do that that I noticed how much it had actually slowed me down.

And of course any nontrivial piece of real-world C++ code is undefined behaviour. So having a memory-safe replacement for that part is a huge improvement.

Re: Building a shared vision for Async Rust

#68

Post by jayd16 »

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

Earlier quoted context omitted.

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 t…

Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.

Re: Building a shared vision for Async Rust

#69

Post by adwn »

millstone wrote: post #66
adwn wrote: post #63

Earlier quoted context omitted.

> what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.

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 want my code to be correct, even if it runs in a sandbox.

Re: Building a shared vision for Async Rust

#70

Post by BuckRogers »

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, Java and probably Rust qualify as true technical innovation. I'm not saying that's the only thing that matters either. Everything has its contributions, but I'm not sure many rise to my standard of technical innovation (solving a problem), and most are pure churn.

Rust solves a real problem that has plagued software for decades (or so I'm told, I'm not a Rust user), but that can be true while everything else you said is also true. I don't plan on picking up Rust either, and yes a combo like C#/C(++) is incredibly potent, and Rust is ages away from replacing C.

A language ends up being the sum of its parts though. C# is "write once, jobs everywhere". Great serverside platform with .NET 5. Native on the most popular desktop platform, produces iOS apps and games. It's industrial-strength in language design. Good IDE support, good backwards compatibility (or side by side support). And also importantly, like my experience writing Python, I enjoy writing C#.

[0]https://en.wikipedia.org/wiki/Timeline_of_programming_langua...

Post reply on HN