4 ms·

The blog post resonates with me. From the outside (not actually writing Rust code yet) it looks like Rust saw C++ metastasize from an overcomplex big language

by fefe23 6y ago

The blog post resonates with me. From the outside (not actually writing Rust code yet) it looks like Rust saw C++ metastasize from an overcomplex big language into an even more overcomplex huge language, and then said HOLD MY BEER! Encouraging people to go async / event based looks like a huge mistake to me. Code becomes much harder to reason about and you get a ton of additional complexity to worry about. A much better way is to provide a layer that looks synchronous on top of asynchronous mechanisms. Like going for declarative programming, or make it look like "one thread per request" and have implicit timeout handling via exception you can catch or so. I think the compartment threading model is one of the main reasons why COM is so successful.

pornel 6y ago
This is a common outsider view, but it's based on wrong assumptions. You think Rust 1.0 was released as a complete language, and now they're just adding useless bells and whistles. While in fact Rust 1.0 was a bare-bones MVP, missing basic functionality, with an annoyingly inflexible implementation of the borrow checker. You couldn't print or copy an array larger than 32 elements! People still complain that the standard library can't generate random numbers and you need a 3rd party library to cast an integer to an enum (really!) Since 1.0, Rust has been mostly filling in holes, and removing gotchas. Apart from async, a lot of changes can be summed up as "this obvious code didn't compile before for weird technical reasons, but now it just compiles". Async started in 2015 with mio library, which was a thin wrapper over Linux epoll. People have recognized that it's tedious to use it, and proposed Futures in 2016, which made it easier. Multiple limitations of Future's APIs were became apparent, so in 2017-2019 there was a lot of work to remove known problems and annoyances. That's the async API: 4 years of real-world experience and simplification of async code. As someone who's used it during that time I can assure you that `async fn` today is easier and clearer than everything Rust had before it.

by fefe23 6y ago

pornel 6y ago

This is a common outsider view, but it's based on wrong assumptions. You think Rust 1.0 was released as a complete language, and now they're just adding useless bells and whistles. While in fact Rust 1.0 was a bare-bones MVP, missing basic functionality, with an annoyingly inflexible implementation of the borrow checker. You couldn't print or copy an array larger than 32 elements! People still complain that the standard library can't generate random numbers and you need a 3rd party library to cast an integer to an enum (really!) Since 1.0, Rust has been mostly filling in holes, and removing gotchas. Apart from async, a lot of changes can be summed up as "this obvious code didn't compile before for weird technical reasons, but now it just compiles". Async started in 2015 with mio library, which was a thin wrapper over Linux epoll. People have recognized that it's tedious to use it, and proposed Futures in 2016, which made it easier. Multiple limitations of Future's APIs were became apparent, so in 2017-2019 there was a lot of work to remove known problems and annoyances. That's the async API: 4 years of real-world experience and simplification of async code. As someone who's used it during that time I can assure you that `async fn` today is easier and clearer than everything Rust had before it.