Hacker News Reader

Comment by fnord77 | Hacker News Reader

I'm a big user of Rust, but I'm kinda dismayed that async IO wasn't part of the original design.

It's nice they're making Futures a zero-cost abstraction, but it feels like it is at the expense of ergonomics.

You have to prioritize something. Development of other features was prioritized over async first. Futures support came later, and async later still. It's an iterative approach. In the end, it let people get a LOT of value out of rust well before async was fully baked.

For myself, I'd been waiting for the syntax to finalize as I'm still learning and didn't want to really delve into old and new ways, though I'm sure I will see them in practice. For others, depending on your needs, if you didn't need it, or willing to jump through the hoops, you could still get value along the way.

Futures were developed outside Rust core, in a third-party library, before being brought into the language. Working with them in combinator form definitely was less ergonomic, but async/await fixes that.

Fun fact: there was a future type in the rust standard library, long, long ago.

https://doc.rust-lang.org/0.10/sync/struct.Future.html

That version of Rust also did async I/O in the runtime. Async I/O has always been part of Rust. The model changed because there was too much overhead doing it the more ergonomic way and it got booted out of the runtime.

Yep, this is a great point.

Someday, we should get a book about the history of Rust together...

I didn’t know about this.. I’d love to read that book :)

Reply on news.ycombinator.com