31–40 of 94 posts
I'd love to see this kind of explanation done in a non-text medium. For example, a slideshow or interactive webpage (ex: http://www.redblobgames.com/pathfinding/a-star/introduction....)
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…
As [1] says: "Rust for C programmers != Rust for functional programmers."
[1] http://science.raphael.poss.name/rust-for-functional-program...
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.
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.
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.
In what sense this introduction is alternative? It's just like every other intro that explains basic and easily understood things about the borrow checker, but doesn't go into details on how you actually live and work with the damned thing. The second thing you do after learning basics is trying to implement some simple data structures, like lists, or even (horror!) double-linked lists. In Rust this is the moment whe…
This seems like an unfortunate pathological case caused by the abstraction level Rust sits at. The kinds of tree- and graph-like data structures that garbage collected languages can represent in safe code (at the cost of performance) don't work as well in Rust; you can still implement them with various mechanisms (std::swap is very important for trees; Rc and Weak; replacing pointers with indices into a global Vec; e…
C++ has it easier in practical terms, I guess—few projects actually use smart pointers as pervasively as modern C++ guidelines stipulate (and they're hard-wired into the language in a couple places like operator new and this), so C pointers usually have to be taught pretty early anyway. In Rust, by contrast, unsafe pointers are considered evil things you touch only when you know you have to. But the problem is still there: it feels like something that comes with the territory of manual memory management in general.
[1]: http://stackoverflow.com/questions/15384443/doubly-linked-li...
In what sense this introduction is alternative? It's just like every other intro that explains basic and easily understood things about the borrow checker, but doesn't go into details on how you actually live and work with the damned thing. The second thing you do after learning basics is trying to implement some simple data structures, like lists, or even (horror!) double-linked lists. In Rust this is the moment whe…
Well, I wrote our existing introduction, this is a different version, that takes a fundamentally different approach: small example, high level of detail, rather than larger examples at a higher level of detail.
Your point about it being an introduction stands, but that's why it's an alternate _introduction_.
Steve, really great work, I've appreciated all your efforts as I've played around with Rust as it approaches 1.0. I think this kind of really deep treatment of an important topic belongs somewhere in the introductory docs. I especially like that you give concrete examples of the problems that Rust's concept of ownership solves. The memory diagrams are actually quite helpful (IMHO) regardless of the "direction". Keep…
I really like your writing style - it's a little verbose in places. The paragraphs detailing what each line number does would be easier just as pictures / diagrams with arrows to the source code sections. Likewise quite a lot of this could be made mode succinct, which would aid readability. Along with that, it's really hard for me to get used to right-hand line numbers. Shoving them along the left hand side like most…
I do agree better diagrams would help, for sure. And yeah, the right hand numbers were kind of a compromise: they kept the exercises compileable without needing to mess with markup stuff, which is just a weakness of markdown :/
Earlier quoted context omitted.
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…
What about two intros? One for the low levelers, one for the high levelers? It's extra work, but it allows to treat more appropriately what each side needs to learn. As [1] says: "Rust for C programmers != Rust for functional programmers." [1] http://science.raphael.poss.name/rust-for-functional-program...
I liked the structure of the guide. However pairing the memory tables while mentally executing the code line-by-line got confusing for me. (Especially because the code was offscreen because the tables take up vertical space) I'd love to see this kind of explanation done in a non-text medium. For example, a slideshow or interactive webpage (ex: http://www.redblobgames.com/pathfinding/a-star/introduction.... )