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

61–70 of 94 posts

Re: An alternative introduction to Rust

#61

Post by ilaksh »

So basically, anyone who doesn't already really appreciate Rust must not know what a stack is, what a pointer is, or what immutability is?

I'm sorry, but this implication enrages me.

If I'm just trying to print out "Hello World", why would I use some kind of list and a pointer?

You touched on an example of where Rust simplifies non-GC memory management.

Its nice that there are various ways to track when you are done with pointers (and memory referenced by them) across the code.

I think some of the techniques are very useful. But its taken to an extreme in Rust where you will do anything to avoid GC.

Some of that stuff involving tracking and matching ownership or correspondence across the code would work better outside of a purely sort of one-dimensional textual representation. This is an example that illustrates why textual source code is a legacy.

But it IS text, and often, with Rust, its too complicated, and often not easily applied to typical "systems" programming (which is quite often used to actually mean some ordinary types of user applications, or programs that do the same thing).

Personally I think Rust could maintain a good portion of its core strength while losing about half of its complexity.

Also, in terms of an introduction it would be nice to see some real useful "systems programming" examples where the core memory tracking and other capabilities make Rust stand out. Hello World isn't a good example of this.

We want the compiler to be smart and be able to avoid collecting things at runtime when possible and practical, and for the programmer to be able to effectively indicate corresponding data so the compiler will know when it should be deallocated. However, we also need the code to be clear and concise and to avoid making the programmer do routine work when its not necessary.

Re: An alternative introduction to Rust

#63

Post by iopq »

jonnybgood wrote: post #25
kbenson wrote: post #20

I suggest you go with prose that clearer over prose that is more stylistic. For example: Line six has a closing curly brace, and so main, and thus, our program, is over. Could be rewritten as: Line six has a closing curly brace, and so main is over. By extension, our program is over as well. Maybe even with a quick reinforcing of the (hopefully earlier explained) concept that main is the main program block. It's a fi…

I agree. Dedicated tutorial authors of languages with advanced concepts such as Rust, Haskell, etc. really need to take a course or have a quick overview of technical writing. Steve does a pretty good job with Rust, I think. I wish Haskell had good tutorial authors like Steve. Haskell really needs better tutorial authors. Are CS majors typically required to take a technical writing class like other engineering discip…

I had to take one. All I remember from it is making posters and graphs. We didn't actually learn BETTER WRITING in it, but how to write RFCs.

Re: An alternative introduction to Rust

#64

Post by BuckRogers »

progman wrote: post #60
BuckRogers wrote: post #9

I'm a Python user, and always dipping my toes in other tech, working through books on Go, wrote some Node servers and so forth. I rarely find something that has enough advantages to warrant augmenting or replace Python or bring it into 'my stack'. The time involved to really master these things isn't worth it, in my opinion. Something with no GC for hard real-time systems would fit the bill, also something that I cou…

You should consider the Nim language. It "feels" like Python but has seemless integration with C, and native performance like C. http://nim-lang.org

I did at one time. I've been keeping my eye on Nim (though a far less watchful one than on Rust) to see if the standard library works one day without using the GC.

Re: An alternative introduction to Rust

#65

Post by pjmlp »

Animats wrote: post #57
pjmlp wrote: post #52

Earlier quoted context omitted.

I don't get why they just don't suggest using weak_ptr () for the backwards reference.

You need to use weak pointers for backpointers in Rust, because there's no GC. If you create a cycle with reference counted objects, objects are never released and the program will leak memory.

Of course, but my question was why it wasn't explained, I know very well the reason why weak pointers are required.

Re: An alternative introduction to Rust

#66

Post by EugeneOZ »

shadowmint wrote: post #34
EugeneOZ wrote: post #30

That example of aliasing - is it possible to write such thing in Go? Will Go compiler eat it or will not compile? Just interesting, how Go behaves in comparison to Rust, as another modern language.

You can have aliasing pointers in go; see https://gobyexample.com/mutexes for how you have to explicitly lock to update the target without undefined behaviour. However, since it's a GC, it's probably not possible to have a pointer that refers to a memory location that doesn't exist, because having a pointer to a memory location is by definition what keeps it from being free'd by the GC.

thanks. but time between 2 lines of code can be not enough for GC to be called to free first address. Maybe they just control it on language level.

Re: An alternative introduction to Rust

#67

Post by static_noise »

pjmlp wrote: post #52
pcwalton wrote: post #35

Earlier quoted context omitted.

This isn't unique to Rust, in fact, as modern C++ presents the same dilemma. Here [1] is a Stack Overflow question where someone asks how to make a doubly-linked list out of smart pointers, and all the answers either involve shared_ptr or C pointers. Same pedagogical issue: you want to deemphasize the less-safe pointers (in Rust, the ones behind an "unsafe" gate; in C++, the raw C pointers) in favor of the safer abst…

I don't get why they just don't suggest using weak_ptr () for the backwards reference.

I guess this would solve the problem but it would also be slow because traversing the list via weak_ptr requires a conversion from weak_ptr to shared_ptr for every item.

Re: An alternative introduction to Rust

#68

Post by iopq »

dbaupp wrote: post #29
Animats wrote: post #13

It's still too confusing. Try drawing actual pictures to illustrate the scope/lifetime issues. Talking about addresses on the stack is an implementation detail. Things to cover: Basic lifetime concepts in Rust: 1. Scopes are nested. 2. Variable lifetimes are tied to scopes. 3. Unlike other languages, variables can be created tied to a scope outer to the one where they are created. The user can control this by indicat…

3. Unlike other languages, variables can be created tied to a scope outer to the one where they are created. The user can control this by indicating that the lifetime of a variable is the same as that of some variable from an outer scope. This is Rust's big innovation. This isn't quite right (or I'm not understanding what you're trying to say). Given let x = 1; { let y = 1; } there's no way you can make `y` itself li…

I think traits are really confusing (dispatch by input AND output type), there's also trait inheritance, trait bounds, casting things to traits; add type inference to that, lifetime parameters and generics. You get things like

    struct Foo 
        where P: std::ops::Neg + 'a,
           ::Output: 'a {
        foo: &'a Bar
,
    }
after further research this makes sense, of course, but looks like non-sense to anyone just trying to learn the language

Re: An alternative introduction to Rust

#69

Post by pjmlp »

static_noise wrote: post #67
pjmlp wrote: post #52

Earlier quoted context omitted.

I don't get why they just don't suggest using weak_ptr () for the backwards reference.

I guess this would solve the problem but it would also be slow because traversing the list via weak_ptr requires a conversion from weak_ptr to shared_ptr for every item.

There isn't any choice in RC systems in presence of cycles, either weak pointers or a presence of cycle collector.

Anything else is unsafe, specially if the pointer is allowed to escape the RC object that contains it.

And this is one of the reasons why usually optimized GCs outperform RC solutions.

Unless approaches like affine types or counting elision are used, but those fail down in the presence of cycles, forcing the developers to use other approaches to represent cycles.

Post reply on HN