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

Flattening Rust’s learning curve

corrode.dev

Post reply on HN
Print view View original

271–280 of 405 posts

Re: Flattening Rust’s learning curve

#271

Post by ModernMech »

greazy wrote: post #220
jillesvangurp wrote: post #140

Rust has a few big hurdles for new users: - it's very different from other languages. That's intentional but also an obstacle. - it's a very complex language with a very terse syntax that looks like people are typing with their elbows and are hitting random keys. A single character can completely change the meaning of a thing. And it doesn't help that a lot of this syntax deeply nested. - a lot of its features are ha…

> it has widely used macros that obfuscate a lot of things that further adds to the complexity. This is what's stumped me when learning Rust. It could be the resources I used, whixh introduced macros early on with no explanation.

Macros are introduced early in Rust for a couple reasons.

1. println!() is a macro, so if you want to print anything out you need to grapple with what that ! means, and why println needs to be a macro in Rust.

2. Macros are important in Rust, they're not a small or ancillary feature. They put a lot of work into the macro system, and all Rust devs should aspire to use and understand metaprogramming. It's not a language feature reserved for the upper echelon of internal Rust devs, but a feature everyone should get used to and use.

Re: Flattening Rust’s learning curve

#272

Post by steveklabnik »

sesm wrote: post #37

Is there a concise document that explains major decisions behind Rust language design for those who know C++? Not a newbie tutorial, just straight to the point: why in-place mutability instead of other options, why encourage stack allocation, what problems with C++ does it solve and at what cost, etc.

I’m not aware of one, but I’m happy to answer questions.

> in-place mutability

I’m not sure what this means as.

> why encourage stack allocation

This is the same as C++, things are stack allocated by default and only put on the heap if you request it. Control is imporrant

> what problems with C++ does it solve and at what cost

The big one here is memory safety by default. You cannot have dangling pointers, iterator invalidation, and the like. The cost is that this is done via compile time checks, and you have to learn how to structure code in a way that demonstrates to the compiler that these properties are correct. That takes some time, and is the difficulty people talk about.

Rust also flips a lot of defaults that makes the language simpler. For example, in C++ terms, everything is trivially relocatable, which means Rust can move by default, and decided to eliminate move constructors. Technically Rust has no constructors at all, meaning there’s no rule of 3 or 5. The feeling of Rust code ends up being different than C++ code, as it’s sort of like “what if Modern C++ but with even more functional influence and barely any OOP.”

Re: Flattening Rust’s learning curve

#273

Post by steveklabnik »

umajho wrote: post #169

> …. For instance, “a trait is a bit like an interface” is wrong, … Wait. What's wrong with this statement?

I think this is just a mistake, in that “a bit like” is correct. The ways in which it are different depend on which language you are taking the concept of “interface” from, but the statement that it’s like one is accurate.

Re: Flattening Rust’s learning curve

#274

Post by steveklabnik »

ModernMech wrote: post #271
greazy wrote: post #220

Earlier quoted context omitted.

> it has widely used macros that obfuscate a lot of things that further adds to the complexity. This is what's stumped me when learning Rust. It could be the resources I used, whixh introduced macros early on with no explanation.

Macros are introduced early in Rust for a couple reasons. 1. println!() is a macro, so if you want to print anything out you need to grapple with what that ! means, and why println needs to be a macro in Rust. 2. Macros are important in Rust, they're not a small or ancillary feature. They put a lot of work into the macro system, and all Rust devs should aspire to use and understand metaprogramming. It's not a languag…

At the same time, you don’t need to author macros. I have basically never written one, for example.

Re: Flattening Rust’s learning curve

#275

Post by lvass »

jmull wrote: post #267

I'm not sure there are many cases where I would choose rust. I'm open to it. I just think in any given situation there would most likely be a better option. Perhaps it will become prevalent enough that it will make sense in the future.

It's definitely the perfect language for writing a browser from scratch, as it was designed for almost 20 years ago. Of course nowadays it's already completely dominating that area, and their creator's "unix" has taken over the world and was not overtaken by something a random dude called ladybird.

Re: Flattening Rust’s learning curve

#276

Post by nmeofthestate »

"You will have a much better time if you re-read your code to fix stupid typos before pressing “compile.”"

This is a strange one - I thought the rust compiler had famously helpful error messages, so why would I want to pore over my code looking for stupid typos when I can let the compiler find them for me? I am guaranteed to make stupid typos and want the computer to help me fix them.

Re: Flattening Rust’s learning curve

#277

Post by steveklabnik »

nmeofthestate wrote: post #276

"You will have a much better time if you re-read your code to fix stupid typos before pressing “compile.”" This is a strange one - I thought the rust compiler had famously helpful error messages, so why would I want to pore over my code looking for stupid typos when I can let the compiler find them for me? I am guaranteed to make stupid typos and want the computer to help me fix them.

cargo fix can automatically fix some, but not all, issues.

Re: Flattening Rust’s learning curve

#278

Post by swiftcoder »

steveklabnik wrote: post #265
swiftcoder wrote: post #191

Earlier quoted context omitted.

> There are programs that Rust will simply not let you write. Can you specify a few of these programs? I can see where Rust might not allow you to write something the way you want to , but I fail to see how a program would not be expressible in rust...

They mean in Safe Rust. Unsafe is included in Rust for this reason.

Is safe rust not Turing complete? I can see the argument that a purist "safe rust only" program might be slow, but it still will be expressible

Re: Flattening Rust’s learning curve

#279

Post by Hackbraten »

frankie_t wrote: post #186
Animats wrote: post #18

It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff. Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples. - Each data object in Rust has exactly one owner. - Ownership can be transferred in ways that preserve the one-owner ru…

Maybe it's my learning limitations, but I find it hard to follow explanations like these. I had similar feelings about encapsulation explanations: it would say I can hide information without going into much detail. Why, from whom? How is it hiding if I can _see it on my screen_. Similarly here, I can't understand for example _who_ is the owner. Is it a stack frame? Why would a stack frame want to move ownership to it…

I think your comment has received excellent replies. However, no one has tackled your actual question so far:

> _who_ is the owner. Is it a stack frame?

I don’t think that it’s helpful to call a stack frame the owner in the sense of the borrow checker. If the owner was the stack frame, then why would it have to borrow objects to itself? The fact that the following code doesn’t compile seems to support that:

    fn main() {
        let a: String = "Hello".to_owned();
        let b = a;
        println!("{}", a);  // error[E0382]: borrow of moved value: `a`
    }
User lucozade’s comment has pointed out that the memory where the object lives is actually the thing that is being owned. So that can’t be the owner either.

So if neither a) the stack frame nor b) the memory where the object lives can be called the owner in the Rust sense, then what is?

Could the owner be the variable to which the owned chunk of memory is bound at a given point in time? In my mental model, yes. That would be consistent with all borrow checker semantics as I have understood them so far.

Feel free to correct me if I’m not making sense.

Re: Flattening Rust’s learning curve

#280

Post by echelon »

geodel wrote: post #269
echelon wrote: post #241

Earlier quoted context omitted.

> Ownership is easy, borrowing is easy 100%. It's the programmer that needs to adapt to this style. It's not hard by any means at all, it just takes some adjustment.

Indeed. Programmers are holding Rust wrong.

Programmers new to Rust, you mean.

It's kind of like career Java programmers using JavaScript or Python for the first time and bringing their way of doing things.

Post reply on HN