You do not have to use the result of an async function to avoid getting a warning. You have to use the future returned by the underlying sync function (I.e., you have to invoke “await”), in order for the async code to actually run. That warning probably caught a real bug.
No bug caught, just a mild annoyance. In this setup I have an async function `index` returning `actix_web::HttpResponse` which is to be used for an actix-web route `.route("/", web::get().to(index))`, inside `index` as a side effect I want to call another async function `write_metadata` which returns `Result<bool, anyhow::Error>` but I don't actually care about the result. I can play with the return type of the `write_metadata` async function, making it return a custom error or even a `HttpResponse`, or I can use `let _`, anyhow, lots of work for something this trivial. As said initially: seeing a fully completed Rust project, syntax ugliness aside, it's rather interesting, building one gradually, trying things out, means plenty of pain from meaningless/context irrelevant language quirks.
That’s because Result is must_use. Nothing to do with async.
In that case, yes, let _ is the usual pattern. But it’s rare that I ever actually want to use that. Typically I either return the error upwards or just unwrap. But if you truly don’t care about whether the operation was successful you can indeed ignore the error.
There are plenty of pain points with Rust but I don’t really think this is one.
Btw, the article you linked argued against the claim that Rust’s syntax is ugly, and instead claims that Rust’s noisyness is due to its semantics, largely in service of performance (which is why production C++ code is often similarly ugly).
