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

An alternative introduction to Rust

words.steveklabnik.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: An alternative introduction to Rust

#41

Post by steveklabnik »

comex wrote: post #23

I agree with some of the caveats listed by other people here (in general, that this guide seems wishy-washy about what type of programmer it's catering to), but I like the memory layout tables. While I don't remember much about how I thought at the time I might have benefited from such a tutorial myself, when these days I mess around with exploits and the like which do weird things to memory, it often feels surprisin…

Yes, it's always about the right level of abstraction. Making it clear that it's not _actually_ 0x00 would be good, but then you can get into discussions about virtual memory, and all that other stuff that you're talking about, which just muddies the point of the example. It's a fine line.

Re: An alternative introduction to Rust

#43

Post by steveklabnik »

mkishi wrote: post #17

I like the new structure much better! Now, I'm in no way a writer. English isn't even my main language.. So take this next point accordingly: Unfortunately, I get an even more condescending vibe from this draft than I got from the book. Not as in "I'm an expert and you're treating me like a newbie," but as if I was a kid instead of an aspiring Rust programmer (beginner or otherwise). I wish I could point out -exactly…

> I wish I could point out -exactly why- I get this feeling, but I'd be lying.

It's hard, for sure. There are certain sentence structures that strike certain people this way, and my style sometimes triggers them. For example, "basically" has no negative connotation for me, but really gets some people going, so I've been eliminating it wherever possible. I wonder which aspect does it for you... thanks for the brain dump, this is helpful.

Re: An alternative introduction to Rust

#44

Post by hackuser »

> Rust’s variable bindings are immutable by default, but can become mutable, allowing them to be re-bound to something else

From someone reading about these details for the first time:

Calling them variable bindings confuses the matter. You say, just moments earlier, that variables are called by that name because they can change over time, they’re mutable. But this variable is immutable? But only sometimes? !

I know you mean that the mutability varies and that it makes sense in the context of the jargon of functional languages, but that's something that will make sense to language developers who have worked on Rust for years and maybe to the HN crowd, and not to new coders trying to grasp difficult, novel (to them) concepts.

How about "multimode bindings" or "multiphase bindings" (as in liquid/solid phase transitions) or dual-mode or something more entertaining like "double-agent bindings". Is it too late to change?

Maybe I'm missing something, but I suspect years from now people will be saying, 'so variable bindings are not always variable? huh?'

Re: An alternative introduction to Rust

#45

Post by dbaupp »

hackuser wrote: post #44

> Rust’s variable bindings are immutable by default, but can become mutable, allowing them to be re-bound to something else From someone reading about these details for the first time: Calling them variable bindings confuses the matter. You say, just moments earlier, that variables are called by that name because they can change over time, they’re mutable . But this variable is immutable? But only sometimes? ! I know…

'Variable' is a jargon-y term in mathematics/programming in general, it doesn't literally mean "this thing can vary in the run of this program", e.g. even Haskell calls its name bindings "variables", and it is focused on immutability much more than Rust (I suppose this is the functional programming aspect you were mentioning).

One way to view it is that the bindings don't have a value that is fixed at compile time: they vary between runs.

In any case, I'm not sure what you mean by "mutability varies".

Re: An alternative introduction to Rust

#46

Post by jrapdx3 »

steveklabnik wrote: post #6
shorodei wrote: post #3

It definitely feels a little long winded for a person with some background already in systems langauages like C. Do you plan a TLDR for systems language people?

A Redditor put it best: > My only concern is that lot of the motivating of the ownership > system seems to be directed at C/C++ programmers, but at the same > time you're explaining pointers and memory management as almost new concepts. I think this is a weakenss of this draft, yeah. I want to make it accessible to non-systems people, but also okay for systems people. In the current, actual intro, I treat everything…

Writing is very hard. Despite the draft's "weaknesses", I thought it was well-written.

Being one who has "enjoyed" numerous encounters with C pointers (and pointers to pointers, etc.), a lot of the explanation seemed elementary indeed. But I didn't mind the "review", in fact, kind of fun imagining I was a beginner and how amazing it would be to learn the details.

I can see why Rust's concept of ownership is essential to grasp. However, the tutorial was a little murky when it came to the deeper subjects of "mutable borrow" and the cause of the example error.

It took a few readings to get what made the line "let x = &v[0];" so crucial: "...&mut is a promise that there are no other references...", i.e., meaning the promise to "x", since "x" is the recipient (owner?) of the "&mut" of "v".

The final paragraph is the key to the entire exposition, so it would be enormously helpful to take a few extra lines of text to clarify just how the expression "v.push("B");" violates the promise to "x". That's even more vital to your purpose as describing pointers in vivid detail.

People new to Rust are beginners re: ownership, borrowing, et.al., and would benefit from a step-by-step walk through of these less familiar parts.

Re: An alternative introduction to Rust

#47

Post by kibwen »

hackuser wrote: post #44

> Rust’s variable bindings are immutable by default, but can become mutable, allowing them to be re-bound to something else From someone reading about these details for the first time: Calling them variable bindings confuses the matter. You say, just moments earlier, that variables are called by that name because they can change over time, they’re mutable . But this variable is immutable? But only sometimes? ! I know…

"Variable" means that the value within can vary, as opposed to a constant, where the value never varies. This has nothing to do with mutation. For instance, a function's arguments are always variables as the value within each argument can vary each time the function is invoked, and they are variables regardless of whether or not the function ever mutates them.

Re: An alternative introduction to Rust

#48

Post by kibwen »

MichaelGG wrote: post #21
shorodei wrote: post #3

It definitely feels a little long winded for a person with some background already in systems langauages like C. Do you plan a TLDR for systems language people?

A very short TLDR, in my limited opinion, is basically "Take an ML-ish, make sure everything has C-like performance, while prohibiting all memory safety issues and eliminating aliasing". From those basic principles things you can start reasoning a lot about what Rust must do. But I agree it does feel a bit weird to need to explain pointers while also assuming people understand memory layouts. There should probably be…

Note that Rust doesn't eliminate aliasing, it merely tracks it very precisely. Taking a reference is a trivial way to create an alias, though obviously while the alias is alive you are restricted in what you can do to the referent.

Re: An alternative introduction to Rust

#49

Post by majika »

bjz_ wrote: post #15
shorodei wrote: post #3

It definitely feels a little long winded for a person with some background already in systems langauages like C. Do you plan a TLDR for systems language people?

Not quite a TLDR, but this is a nice presentation by Lars Bergstrom that assumes more background knowledge: https://vimeo.com/120512790

I didn't find this video helpful at all. You have to skip 10 minutes ahead to get to the actual talk. The talk is stunted and, as always with Rust documentation, dwells only on the basics. Audio isn't clear, but neither is the speaking.

I don't know of a succinct overview of Rust for experienced system programmers, and this video certainly isn't that.

Re: An alternative introduction to Rust

#50

Post by MichaelGG »

kibwen wrote: post #48
MichaelGG wrote: post #21

Earlier quoted context omitted.

A very short TLDR, in my limited opinion, is basically "Take an ML-ish, make sure everything has C-like performance, while prohibiting all memory safety issues and eliminating aliasing". From those basic principles things you can start reasoning a lot about what Rust must do. But I agree it does feel a bit weird to need to explain pointers while also assuming people understand memory layouts. There should probably be…

Note that Rust doesn't eliminate aliasing, it merely tracks it very precisely. Taking a reference is a trivial way to create an alias, though obviously while the alias is alive you are restricted in what you can do to the referent.

How about "eliminating problems caused by aliasing", which I suppose is a subset of memory safety.
Post reply on HN