Next Day Edit: Sorry. Forgot to use my Canadian Aboriginal syllabics again. Because apparently it’s too hard to admit HTML-sanitizing source markdown was wrong!
One thing that irks me in these articles is gauging the opinion of the “Rust community” through Reddit/HN/Lemmy😉/blogs… etc. I don’t think I’d be way off the mark when I say that these platforms mostly collectively reflect the thoughts of junior Rustaceans, or non-Rustaceans experimenting with Rust, with the latter being the loudest, especially if they are struggling with it!
And I disagree with the argument that poor standard library support is the major issue, although I myself had that thought before. It’s definitely current lack of language features that do introduce some annoyances. I do agree however that implicit coloring is not the answer (or an answer I want to ever see).
Take this simple code I was writing today. Ideally, I would have liked to write it in functional style:
async fn some_fn(＆self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
(bool_cond).then(|| async {
// ...
// res_op1().await?;
// res_op2().await?;
// ...
Ok(bytes)
})
}
But this of course doesn’t work because of the opaque type of the async block. Is that a serious hurdle? Obviously, it’s not:
async fn some_fn(＆self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
if !bool_cond {
return None;
}
let res = || async {
// ...
// res_op1()?;
// res_op2()?;
// ...
Ok(bytes)
};
Some(res().await)
}
And done. A productive Rustacean is hardly wasting time on this.
Okay, bool::then() is not the best example. I’m just show-casing that it’s current language limitations, not stdlib ones, that are behind the odd async annoyance encountered. And the solution, I would argue, does not have to come in the form of implicit coloring.
Lemmy also escaped the ampersands in their comment’s link 😉
Isn’t broken sanitization great!