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

Rust without the async (hard) part

lunatic.solutions

Post reply on HN
Print view View original

91–100 of 136 posts

Re: Rust without the async (hard) part

#91

Post by jjnoakes »

xrobledo84 wrote: post #62
verdagon wrote: post #21

Does anyone else get the feeling that we (as a field) are missing something basic about concurrency? Like there's a really elegant solution just around the corner, that has the low overhead of async/await without the complexity. Or otherwise put, the ease of goroutines but without GC. I know it sounds crazy. I recently dove into the area, and was pretty surprised at how many interesting building blocks there are out…

What you are looking for is called Erlang

How is that "the ease of goroutines but without GC" ?

Re: Rust without the async (hard) part

#92

Post by cshenton »

Why isn’t imperative event loop programming more widely used? It’s a reasonably common pattern for games networking libraries like Enet, and has the added bonus that you get to design exactly how you lay out the memory of all your in flight work and therefore have it be easily debuggable.

Re: Rust without the async (hard) part

#93

Post by mcronce »

amelius wrote: post #73
smilekzs wrote: post #71

Earlier quoted context omitted.

FTFY: thousands of GREEN threads

Does it matter? The point is that Go has excellent throughput and latency, while using only a single concurrency model.

I would not describe latency as "excellent" in Go, unless you're measuring average or p90.

Re: Rust without the async (hard) part

#94

Post by beebmam »

I've been asking this for months, and I can't seem to find an answer anywhere:

I'm unable to get debugger breakpoints in Async functions in Rust to actually break.

Is this a known bug with Async Rust? Or is this simply unsupported (yet)? Seems like a really broken experience currently.

Re: Rust without the async (hard) part

#95

Post by loudmax »

jstx1 wrote: post #36

I've done some beginner Rust and Go programming (read "the books" on both, written small programs) and I'm wondering which one to spend more time on or try to get a job with in the future. When I see discussions like this one about Rust, I start to worry that it's unnecessarily complicated and difficult to work with and that this will only get worse in the future to the point that it won't be a good fit for many of t…

Go is very easy to learn. You can be up and running with Go very quickly and it's fantastic for simple applications. The time investment to be reasonably good at writing Go is low. There's little reason not to learn Go.

Rust is difficult to learn, unless you already have a lot of experience with existing low level languages. Getting complex programs up and running with Rust is cumbersome. But the performance is excellent, you can have a high degree that your program is rock solid, and there are entire classes of security issues don't happen in Rust. For the types of applications where Rust does well, it does very well indeed. The time investment to become a decent Rust programmer is high, but this higher barrier to entry can make your programming skills even more valuable since there's less supply to meet the demand.

Re: Rust without the async (hard) part

#96

Post by amelius »

jen20 wrote: post #78
amelius wrote: post #73

Earlier quoted context omitted.

Does it matter? The point is that Go has excellent throughput and latency, while using only a single concurrency model.

Yes, it does matter. It has excellent throughput and latency for certain classes of systems, while others are impossible to build. Rust may not impose this constraint while meeting its goals.

You can say the same about assembly language. Yet it is used only by a very narrow audience.

Re: Rust without the async (hard) part

#97

Post by eklitzke »

Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

I agree and this article seems pretty misinformed. Creating and managing threads on Linux is extremely cheap, especially when a lot of them are idle, and a lot of big companies (Google, Facebook, Amazon) have tons of huge C++ applications that have thousands of threads and it's fine. I also think a lot of people who don't work on these problems at these kinds of companies assume that it must be incredibly difficult to write code like this and debug it, but that's not really true. For one thing, generally the tricky parts to write are abstracted away so that regular engineers don't have to think much about threading concurrency issues. And when they come up, tsan and lock annotations[1] will catch 99.9% of these problems in testing and make it easy to understand why things are breaking.

In the real world here are the kinds of problems that people at Google etc. care about when it comes to performance or scalability issues with hugely concurrent programs:

  - Noisy neighbor problems from other threads messing with your TLB and L1 cache
  - High cost of context switches
  - Unpredictable scheduling/priority inversion in the scheduler
The first problem isn't actually made any better by using async coroutines or green threads/fibers, if you switch to another coroutine or fiber and it does something naughty (e.g. munmaps memory, which will cause a TLB shootdown) it's going to degrade performance for your unrelated coroutine/fiber.

The second and third problems can be solved in some cases by things like fibers and userspace scheduling, but this is a fairly advanced topic and "just use async" is definitely not the solution. If you're interested in learning more about how these problems are actually solved at Google for example I recommend [2] and [3].

[1] https://abseil.io/docs/cpp/guides/synchronization#thread-ann... [2] https://www.youtube.com/watch?v=KXuZi9aeGTw [3] https://storage.googleapis.com/pub-tools-public-publication-...

Re: Rust without the async (hard) part

#98

Post by woah »

Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available.

If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.

Re: Rust without the async (hard) part

#99

Post by ibraheemdev »

eklitzke wrote: post #97
Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

I agree and this article seems pretty misinformed. Creating and managing threads on Linux is extremely cheap, especially when a lot of them are idle, and a lot of big companies (Google, Facebook, Amazon) have tons of huge C++ applications that have thousands of threads and it's fine. I also think a lot of people who don't work on these problems at these kinds of companies assume that it must be incredibly difficult t…

> - Noisy neighbor problems from other threads messing with your TLB and L1 cache

Switching between threads within the same process doesn't require a TLB or L1 cache flush. Not sure if you were implying this, just wanted to point that out.

> - High cost of context switches

Userspace schedulers (like rust's tokio) do make context switching cheaper, however, most of the context switching in the case of a web server is due to blocking I/O and the most expensive part of the switch, entering the kernel, is already accounted for by the I/O request. Kernel context switching is unlikely to be your bottleneck.

> Unpredictable scheduling/priority inversion in the scheduler

This can definitely be an issue at scale, but a general purpose async scheduler like most use is unlikely to be any better.

Re: Rust without the async (hard) part

#100

Post by rat9988 »

woah wrote: post #98
Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.

Because he is talking about massive concurrency, not embedded or wasm or other contexts where there not be as many resources available.
Post reply on HN