Discussion on: My first impressions of Rust

View post

I'm not sure why implicit return would be error prone since you have to specify the return type. Do you have an example?

Regarding this, it might be easier to think about everything in Rust having a type and a value. Thats why you can do things like:

let x = match { ... };
let y = if ... { ... } else { ... };

This is true even when you don't explicitly return a type. A function without a specific return type actually returns a unit type ().

Shadowing is a bit more complex than you've mentioned here, and does have its uses, though I think it's more often than not a bit of a smell if you're using it. Below is an example of how it can be used with scoping blocks, note that when the second x goes out of scope, the first one still exists. This is because you're not resetting it, you're creating a new var with let and using that instead.

let x = 1;
{
  let x = 2;
  println!("{}", x); // 2
}
println!("{}", x); // 1

The differences between &str and String are complex (not to mention &String and all the other types such as OsString or raw data in a &[u8]). It definitely took me some time to get my head around, but all these different types actually perform very important functions.

Lots of languages provide iterators as well as loops (also things like generators which Rust also provides but only in nightly atm), but I do agree again that having 3 different types of function is confusing, I still struggle with it.

TL;DR: I think your frustration at the complexities of the language are sound, however the more you use it I think the more you'll understand why they made those decisions (also, just wait until you hit lifetimes).

Deepu K Sasidharan • Nov 9 '19 • Edited

Thanks for the response. The reason I thought the implicit return is error-prone is as below

    let number = {
        5 + 6;
    };

    let number = { 
        5 + 6 
    };

Both are valid as per compiler but have different meanings. I wasn't aware of the () type and it makes a bit more sense, and ya seems like in most cases compiler would catch if you accidentally miss a ; or add one in a block scope. Anyway, it was a nitpick and I think I'll retain it as such as I still don't like it. Maybe having a keyword like yield would have been much nicer and explicit. I'm not a fan of anything implicit.

For shadowing, I think you missed my point. I have no problem with shadowing in a different scope, it is indeed a good thing. My problem as mentioned in post is with same scope shadowing, see below

fn main() {
    let foo = "hello";

    // do stuff here

    let foo = "world";

    println!("The value of number is: {}", foo);
}

How is it any different from below in actual practice, it gives you a way to work around an immutable variable without marking it immutable. Again its a bit implicit IMO

fn main() {
    let mut foo = "hello";

    // do stuff here

    foo = "world";

    println!("The value of number is: {}", foo);
}

About iterators and stuff, I would still prefer to have fewer ways to that

Also, I agree, as I use the language more I'm sure I would come to terms with these and I might even like some of them more, the same case with JavaScript, there is a lot of things I don't like about it but it is still one of my favorite languages.

Ya, I found the lifetime stuff to be strange but didn't form an opinion on them yet. So far it seems like a necessity due to language design.

Louis Cloete • Nov 10 '19

The compiler will tell you exactly why your number, which is of the unit type (()) won't work in a context expecting an integer. I don't think that's really so much of an issue. Also, you can post on users.rust-lang.org and probably be helped within 30 minutes with a very detailed explanation of your mistake and its fixes.

Deepu K Sasidharan • Nov 10 '19

Yes, I agree that Rust compiler is quite wonderful and when actually using it, it will not be a big deal. But from a readability standpoint I would still prefer explicit intent. To me good code should be readable even to someone not familiar with a language. Of course no language is perfect in that sense but one can dream of it right.