[xscott]

> Rust eliminates each of these points: all integer types have an explicit size, and all types are prefixed with either i or u for signed and unsigned respectively. There’s no bias towards a certain size or signedness.

Most of that paragraph is objectively false:

    fn main() {
        let i = 1;
        let j = 1;
        print!("i: {:?}\n", !i);
        print!("j: {:?}\n", !j);

        // spooky action at a distance
        let v = vec![1, 2, 3];
        v[i];
    }

Only a small percentage of rust programmers could explain what's going on here before compiling and running this program. I fully expect one of the more obnoxious ones to come along any second and defend it by throwing in a lot of unrelated information and not addressing the fact this is a confusing example despite being so simple.

[whytevuhuni]

Yeah, this has come up a few times when I was coding Rust. From just reading your code I know for sure that i is a usize (indexing is very common), but don't know what j is (I usually expect Rust to throw some kind of "could not infer integer type" compiler error, and it doesn't do that here). I'm guessing maybe i32. Code at the end of the function changing the meaning of code at the beginning of a function has also surprised me a couple times.

In my particular case I'm using Zed with type hints enabled, so the editor displays that expression as `let i: usize = 1;` automatically (which is really useful in a language with type inference, especially with expression as weird/complex as Rust iterator method chains). You're right that I wouldn't know if I were to open the file in a simple text editor.