Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A half-hour to learn Rust (2020)

fasterthanli.me

Post reply on HN
Print view View original

51–60 of 86 posts

Re: A half-hour to learn Rust (2020)

#51

Post by melagonster »

gary17the wrote: post #30
skulk wrote: post #9

This is, more or less, how I learned Rust circa 2015 (might have been a couple years later). I quickly started to write programs like I would have in C but got completely thwarted by the borrow checker because I wanted pointers everywhere. This made me throw my hands up and leave for other languages. However, 8 years later I did eventually come to love rust after learning the One Weird Trick of using indices instead…

> got completely thwarted by the borrow checker IMvHO, Rust Ownership and Lifetime rules aren't really that hard to learn. The only trick is that a programmer cannot learn Rust exclusively by trial-and-error (which programmers love to do), trying dozens of syntax combinations to see what works. A programmer is forced to learn Rust by RTFM (which programmers hate to do), in order to understand how Rust works. That's a…

maybe this is because Rust have new mind model, most of mind models can be used in most of language, first time is harder.

Re: A half-hour to learn Rust (2020)

#52

Post by trane_project »

masklinn wrote: post #42
trane_project wrote: post #33

Earlier quoted context omitted.

Not sure if I disagree but your example is terrible. Let patterns in if statements greatly simplify things. The alternatives are a lot more convoluted. See example from code I wrote this week: https://github.com/trane-project/trane/blob/master/src/data/... Without the let, I'd have to do a match statement followed by an unwrap just to check if a field in an enum is set.

> Without the let, I'd have to do a match statement followed by an unwrap just to check if a field in an enum is set. You... would not? An `if let` trivially desugars to a `match`. if let = { ... } becomes match { => { ... } _ => {} }

See my example. I am trying to extract the value of an optional field in the enum. That's where the unwrap comes in.

Re: A half-hour to learn Rust (2020)

#54

Post by CoastalCoder »

rewmie wrote: post #49
CoastalCoder wrote: post #39

Earlier quoted context omitted.

I get the impression that Rust revisions are (at least intended to be?) backwards compatible: [0] Are there are good workarounds when breaking changes to occur? No idea if/how well breaking language changes can be isolated to stay within individual crates. [0] https://subscription.packtpub.com/book/programming/978178934...

> I get the impression that Rust revisions are (at least intended to be?) backwards compatible I don't think that matters at all. If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.

> If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.

Usually when people worry about language evolution, the concern is that a newer compiler can't handle older code.

Re: A half-hour to learn Rust (2020)

#55

Post by mcronce »

distcs wrote: post #2

I know this is not going to make me an expert in Rust. That'll probably take 10 years. But this is just the kind of thing I was looking for to get started with Rust. Thanks for sharing it here.

If you're already an expert in some other programming discipline (e.g. another language) I wouldn't expect it to take 10 years to become a Rust expert. I'd expect one or two if you're using it primarily, which is similar to what I'd expect for most other languages.

Re: A half-hour to learn Rust (2020)

#57

Post by steveklabnik »

AlanSE wrote: post #56

Can someone explain to me where the feeling_lucky variables comes from in the match example? I don't get it. The variable isn't defined anywhere in the relevant scope.

It's not a full example, that code would not compile because that variable is not defined.

Re: A half-hour to learn Rust (2020)

#58

Post by steveklabnik »

zer0tonin wrote: post #6
distcs wrote: post #2

I know this is not going to make me an expert in Rust. That'll probably take 10 years. But this is just the kind of thing I was looking for to get started with Rust. Thanks for sharing it here.

If becoming an expert in Rust had to take 10 years, that would mean there are currently not a single Rust expert in the world

There are dozens of us, dozens! (I started learning Rust ten and a half years ago. Anyway I agree with your point it's just amusing.)

Re: A half-hour to learn Rust (2020)

#59

Post by masklinn »

trane_project wrote: post #52
masklinn wrote: post #42

Earlier quoted context omitted.

> Without the let, I'd have to do a match statement followed by an unwrap just to check if a field in an enum is set. You... would not? An `if let` trivially desugars to a `match`. if let = { ... } becomes match { => { ... } _ => {} }

See my example. I am trying to extract the value of an optional field in the enum. That's where the unwrap comes in.

What I wrote up is the spec-defined desugaring of a single-branch `if let`, aside from desugaring bugs there should be no counter-example.

The snippet you link to should be replaceable by something along the lines of

    match &passages.asset {
        TranscriptionAsset::Track {
            artist_name: Some(artist_name),
            ..
        } => {
            metadata
                .entry(ARTIST_METADATA.to_string())
                .or_default()
                .push(artist_name.clone());
        }
        _ => {}
    }
no `unwrap` needed. I don't know where you got that idea.

Re: A half-hour to learn Rust (2020)

#60

Post by jandrewrogers »

skulk wrote: post #9

This is, more or less, how I learned Rust circa 2015 (might have been a couple years later). I quickly started to write programs like I would have in C but got completely thwarted by the borrow checker because I wanted pointers everywhere. This made me throw my hands up and leave for other languages. However, 8 years later I did eventually come to love rust after learning the One Weird Trick of using indices instead…

A lot of systems software, especially in C++ but perhaps less so in C, makes heavy use of indices too, for reasons unrelated to the borrow checker obviously. I always felt this should produce less friction in the adoption of Rust than it seems to since it is idiomatic for many types of C++ software.
Post reply on HN