Comment by oconnor663 | Hacker News Reader

Comment by oconnor663 | Hacker News Reader

Parent Full thread

> something way less accessible

This is subjective, but there are at least a couple big counterexamples. Non-lexical lifetimes are a huge benefit for newcomers. I've gone through my old projects and just deleted all the nested blocks that I used to need to satisfy the borrow checker. Everything just works now. Also being able to match on `&T` or `&mut T` without putting the `ref` and `ref mut` keywords in each non-`Copy` binding, is another pretty big win. That's an entire keyword that we no longer need to teach to newcomers.

> Basic crates use so many generics, impl Trait and abstractions over abstractions over abstractions that it's really difficult to follow what concrete types you need to satisfy these.

Again this is subjective, but not following concrete types it the entire point of `impl Trait`. The type of `foo.iter().map(...).filter(...).step(...).take(...)` is a monster. Life is better when we don't have to type it. There are also new capabilities that come along with it: APIs don't have to commit to returning a certain kind of unboxed iterator, and unboxed closures can now be returned.

> async/await don't solve much, as besides textbook examples

See the real code examples here: https://docs.rs/dtolnay/0.0.3/dtolnay/macro._01__await_a_min...

Is there a way to ask Rust to tell me the type of an expression like `foo.iter().map(...).filter(...).step(...).take(...)`? I often feel very much in the dark about Rust types and some kind of command to show me Rust's interpretation of the type of an expression in context might help a lot.

The hack that I've seen people use the most is to write a line like this:

    () = foo;

Then rustc will print out an error that includes the type of `foo`.

Nice, thanks!

Scott Meyers also suggests the same sort of thing in Effective Modern C++ when not using an IDE.

Personally, I use the technique a lot for debugging template errors in the language.

Specifically:

template<typename T> struct TD;

Instantiate this as ‘TD<decltype(foo)>’ to get the full name of the type.

Rust’s does seem more concise.

Note that you don't get the full name of the type with a bad assignment in Rust, you only get the part of the type that was deduced before type checking failed. A generic type might have undeduced blanks, eg. Vec<_>. A side-effect of type inference.

Just try assigning the expression to a variable of definitely the wrong type, and the compiler will print out the full type in the error message, e.g.

let x: () = foo.iter().map(...).filter(...).step(...).take(...);

In VSCode, you can assign it to a variable and then mouse over to see what type it infers.

This usually works, but type inference in RLS (or Rust-Analyzer) breaks often enough that it's not a complete solution.

IntelliJ shows the inferred types by default. However it Gasversorgung it’s limitations with complex Rust types.

> However it Gasversorgung it’s limitations

I guess this is some autocorrect error? What did you mean to say?

Oh wow, I just saw that now. It was certainly autocorrect on phone. Should only have been "has".

If you are curious: Gasversorgung would be be "gas supply".

    let _ = 5 + foo.iter().bar().quux().asdf();

The compiler will now tell you that <your type> cannot be added to an `i32`.

In the old days in C++ we'd try to assign it to int and look at the compiler error message. (That literally was the instruction of how to figure out the type to use in one of boost's libraries in pre-c++11 times ...)

    const foo = await callApi(url)
    console.log(foo.bar)

Why do we need anything more complex than this?

Translating that to Rust:

    let foo = call_api(url).await;
    println!("{}", foo.bar);

Syntatical differences aside, what's complex about it?

Reply on news.ycombinator.com