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

31–40 of 136 posts

Re: Rust without the async (hard) part

#31

Post by eloff »

zaphar wrote: post #3

Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…

Yes, async is hard. It adds lots of complexity, both to the code and in your mental model. That slows development. I'd rather have faster development most times. It's why I prefer to use Go over Rust whenever possible. That's why I'm really interested in what lunatic is doing here. It might narrow the gap a little.

Re: Rust without the async (hard) part

#32

Post by dboreham »

api wrote: post #8
ianbutler wrote: post #4

Earlier quoted context omitted.

I started writing rust ~6mo ago and while I agree with your sentiment, the issue I've run into is that so many packages I need to use, because there isn't an alternative and I don't want to build it myself, already uses async. I then have to either heavily wall off that part of my code or at a certain threshold realize I may have to adopt async myself because keeping two concurrency models going is really a lot of ov…

Async has really taken over anything networking-related because, well, it offers much better scaling and performance. If you're a package author you're going to get more people asking for async than people that don't want it. There is no sane way to make async optional in a library and reuse code.

> it offers much better scaling and performance

Myth. Performance won't be better. Scaling arguably is better, but usually the use-case doesn't require the level of scaling where async is superior to OS threads.

Re: Rust without the async (hard) part

#33

Post by the__alchemist »

duped wrote: post #25
dboreham wrote: post #23

Earlier quoted context omitted.

This "async virality" syndrome is the main reason why async is harmful imho. _Some_ async can be very useful in certain constrained circumstances, I believe. However forcing the async execution model on all code is a terrible idea.

How would you propose mixing async and sync code from an implementation perspective?

I'll use an embedded analogy. I'm not as familiar with concurrency on GPOS, but consider this:

I have an I/O task that might take long, compared to CPU operations:

  - Start the task, but don't wait for its result.
  - Your program continues as normal
  - When the IO task is complete, its hardware sends an interrupt (at a specific priority) to the CPU. The CPU stops what it's doing (assuming there isn't a higher priority task in progress). Here, you can read the now-ready IO data, and do something with it. Or maybe cue another task.
You could also examine the case of DMA. Ie, your peripheral (Maybe your network chip in the case of a desktop PC?) commands an IO task. It runs in the background on your network hardware. You then read from, or write to the buffer that's associated with the DMA transfer as required. (Sometimes using DMA-related interrupts)

Could you apply this model to GPOS networking? Of note, some people are trying to do the opposite: Use Async on embedded, to wrap interrupts and DMA.

Re: Rust without the async (hard) part

#34

Post by bruce343434 »

lalaithion wrote: post #20
bruce343434 wrote: post #6

> However, if you are doing web apps or any networking stuff, massive concurrency benefits are almost always too important to ignore No, you will benefit from parallelism/multithreading. Why only use 1 core? Multitasking as it was once called, or "async" as it is now, is fundamentally _synchronous_ because everything still happens on one core. Just that the order of execution may be a bit wonky, which technically all…

Even if you use N cores, you still get a massive benefit from being able to let >N threads wait on IO events simultaneously using concurrency/multitasking/async.

There's only so much a "apache" or "nginx" can do though in between io operations right? And there's only so much io per second a whole system can do. Basically, from disk to memory, maybe run a language interpreter if the site is not static, then from memory to the internet. Maybe if your pages are very dynamic and involve a lot of scripts it could be worthwhile. Do you have any numbers to back up your claim?

Re: Rust without the async (hard) part

#35

Post by mamcx »

kirbyfan64sos wrote: post #24
loeg wrote: post #15

Earlier quoted context omitted.

Too many major packages in the ecosystem only support an async model now. It's pretty frustrating if you are just writing a synchronous program, or one with a straightforward OS threading model.

If your program is mostly synchronous, you can manually create the async runtime and just use block_on to call async functions from a sync context: https://tokio.rs/tokio/topics/bridging#a-synchronous-interfa...

No, this not work well.

The highly infectious nature of async means you need to do that A LOT.

ie: reverse ALL things await.

That is too much. I refactor all my codebase (a huge refactor!) because this.

Re: Rust without the async (hard) part

#36

Post by jstx1 »

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 the use cases that it's pitched for. Am I wrong to think this?

Re: Rust without the async (hard) part

#37

Post by sealeck »

api wrote: post #8
ianbutler wrote: post #4

Earlier quoted context omitted.

I started writing rust ~6mo ago and while I agree with your sentiment, the issue I've run into is that so many packages I need to use, because there isn't an alternative and I don't want to build it myself, already uses async. I then have to either heavily wall off that part of my code or at a certain threshold realize I may have to adopt async myself because keeping two concurrency models going is really a lot of ov…

Async has really taken over anything networking-related because, well, it offers much better scaling and performance. If you're a package author you're going to get more people asking for async than people that don't want it. There is no sane way to make async optional in a library and reuse code.

https://github.com/jimblandy/context-switch/ suggests that it's not substantially better

Re: Rust without the async (hard) part

#39

Post by estebank »

api wrote: post #8
ianbutler wrote: post #4

Earlier quoted context omitted.

I started writing rust ~6mo ago and while I agree with your sentiment, the issue I've run into is that so many packages I need to use, because there isn't an alternative and I don't want to build it myself, already uses async. I then have to either heavily wall off that part of my code or at a certain threshold realize I may have to adopt async myself because keeping two concurrency models going is really a lot of ov…

Async has really taken over anything networking-related because, well, it offers much better scaling and performance. If you're a package author you're going to get more people asking for async than people that don't want it. There is no sane way to make async optional in a library and reuse code.

> There is no sane way to make async optional in a library and reuse code.

FWIW, there's an effort to do exactly that, but because it will require language level changes and it is just on the drawing board phase, it will likely be a while before it can be widely used.

The "optionality" of `async` while sharing code also applies for `const` and mutability (why do we need `Deref` and `DerefMut`?). Finding a solution that can work for these three (and maybe others?) parts of the language will be a welcome improvement.

Post reply on HN