3 ms·
> You also don't need async in many if not most cases, especially if you're writing kernel code. Have you seen how much communication with the hardware in driv
by WesolyKubeczek 4y ago
> You also don't need async in many if not most cases, especially if you're writing kernel code.
Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it.
But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
- wongarsu 4y agoCurrently the rust ecosystem is rapidly moving towards treating tokio as the default-and-only async runtime. If the linux kernel community establishes an async runtime tuned for embedded/kernel use cases that could bring some much needed diversity and speed up the process of making async ergonomic and less bolted-on.
- nomel 4y ago> It’s all hand rolled C What do you consider "hand rolled"? The kernel has extensive support for these use cases since, as you said, hardware is usually async. Async with hardware is rarely tangled, from my limited experience. It's usually event driven.
- WesolyKubeczek 4y agoI mean that it’s not hidden behind some all-encompassing event loop, nor is there an all-encompassing framework with an event loop hidden from you. It’s more like an exploded view of a mechanism in comparison.