4 ms·

Rust seems nice when you see someone like Jon Gjengset writing it [1], however when actually writing it yourself you discover that your errors have errors which

Rust seems nice when you see someone like Jon Gjengset writing it [1], however when actually writing it yourself you discover that your errors have errors which only show some kind of alien fishing when you Google them. Perhaps ChatGPT could help here, it's quite useful/pleasant for trivial quizzes, however I asked it recently how to handle a file upload using actix-web and it hallucinated some really nice methods, too bad they aren't in the code base. Just a random recent example: call an async function for a side effect without caring what its result is, Rust yells at you that the result must be handled "`#[warn(unused_must_use)]` on by default", so you'd think I would just annotate with `#[allow(unused_must_use)]`, but no way, you must store the result in a _ variable: "let _ = my_async_fn().await;". It's a great language, it's just ugly, sorry, not sorry. [1] https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVErFiWDOAVrPt7aYmnuuOLYvOa https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...

c-cube 4y ago
Nitpick: _ is not a variable, it's a wildcard pattern that means "ignore this value". It can occur in other places like tuple deconstruction and the likes.
- ly3xqhl8g9 4y ago
  Nitpicking the nitpick: _ is a wildcard pattern when stated in a match as in [1], otherwise it's indeed a placeholder as a standalone, but also a special character when using it in the normal code flow to allow for unused variables as in `let _foo`. Asked even ChatGPT about it (they must add permalinks for the answers), they answered: "In Rust, the '_' symbol is a special value that can be used in a number of ways. Here are a few common uses: 1. As a placeholder for unused variables. 2. In pattern matching. 3. In iterators." [1] https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
  - c-cube 4y ago
    `let` takes a pattern, these are not just found in `match`. The `_` here is still a pattern.
School-Cotton 4y ago
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.
- ly3xqhl8g9 4y ago
  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. Fun fact: Google-ing "syntax ugliness" gets as first result "Rust’s Ugly Syntax", https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
  - School-Cotton 4y ago
    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).

c-cube 4y ago

Nitpick: _ is not a variable, it's a wildcard pattern that means "ignore this value". It can occur in other places like tuple deconstruction and the likes.

ly3xqhl8g9 4y ago
Nitpicking the nitpick: _ is a wildcard pattern when stated in a match as in [1], otherwise it's indeed a placeholder as a standalone, but also a special character when using it in the normal code flow to allow for unused variables as in `let _foo`. Asked even ChatGPT about it (they must add permalinks for the answers), they answered: "In Rust, the '_' symbol is a special value that can be used in a number of ways. Here are a few common uses: 1. As a placeholder for unused variables. 2. In pattern matching. 3. In iterators." [1] https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
- c-cube 4y ago
  `let` takes a pattern, these are not just found in `match`. The `_` here is still a pattern.

School-Cotton 4y ago

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.

ly3xqhl8g9 4y ago
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. Fun fact: Google-ing "syntax ugliness" gets as first result "Rust’s Ugly Syntax", https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
- School-Cotton 4y ago
  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).