Hacker News new | past | comments | ask | show | jobs | submit login

Hi everyone! I just woke up to find all this, and I'm speaking at a conference today where there's no laptops allowed, so we'll see when I get to read these comments. A few things:

1. Consider this a 'first draft.' I wrote this in sections, see [1], and now it's time to edit as a whole.

2. Because of that, there are still changes coming. There's even an active one in the queue right now. [2]

3. This guide is fairly long (The PDF is 80~ pages), tries to make little assumptions about systems programming knowledge, and will get you from 'I know nothing about Rust' to 'I'm an intermediate Rust programmer.' There's plans to make an abridged version for people who are already familiar with systems or want something faster with less explanation.

To expand on (3) a bit, one of the hard parts of teaching is that you have such varying background levels of skill in your audience. This means different people need different things, one learning resource will never fit all. I very specifically went for extra explanation and an informal tone with this piece, based on my years of experience teaching programmers new languages. You all here are generally much further along, know more programming concepts and features, and are just generally more advanced. I want to include _everyone_ with the introductory documentation I write, and that means spelling things out a bit more. And it also means you all may not like it. You'll probably prefer the abridged version.

Feedback very welcome. I'll read all this eventually, or just open some issues.

1: https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3As...

2: https://github.com/rust-lang/rust/pull/17155




Hey Steve,

Who do we have to harangue to get Rust to rename "Vector"? It is kind of embarrassing and confusing terminology, and there is no reason to propagate it. Just call an array an array and an immutable array an immutable array.

There's no good reason to perpetuate the mistakes of the C++ people.

(Note to those not understanding the objection: A vector is defined an element of a group that is closed under addition and multiplication. This is a very specific and very widely-useful meaning, and any program that does stuff with math is going to use vectors. So when you come along and put into your standard the idea that 'vector' means an arbitrary collection of elements that probably are not even scalars, you not only show that you don't know what vector means, but you confuse the programs of many many of your users, because now they have two totally different things both of which are called Vector and that are both used very heavily. [There is no way in hell anyone is going to call a math vector anything but vector, since that would be insanely confusing.])


My understanding is that in order to make a proposal like this (any change to the syntax or semantics of the language or standard library), the way to advocate a change is to write an RFC. To do so, you fork the rfcs repo on GitHub (https://github.com/rust-lang/rfcs), and write a document describing your proposal and its pros and cons. Then the community can discuss it, and if there's sufficient interest someone will champion for it a shepherd it through the RFC process.


Short because I'm on my phone: my sibling is correct. But I think it's important to understand that Vec<T>, [T, ..N], and &[T] (vectors, arrays, and array slices) aren't different because of mutability. The differences are in ownership, growability, and where the backing memory is allocated. Also, Vec<T> isn't part of the language, but part of the standard library, while the other two are language items. Any RFC would have to take this into account.


I know you're not exactly opposing the above comment, but I'll make a supporting argument here which acknowledges what you've said:

I feel as though we can retain understanding of those differences without using the name "Vec", which can be considered a poor choice for the reasons mentioned above (by C++ and Rust alike).

Array<T> for a growable array

[T, ..N] for a fixed-length array

&[T] for a slice into either of these array types

Even forgetting the mathematical concept, I would argue that throwing the term "Vector" into the mix only makes things more complicated than they need to be, since sticking to "Array" homogenizes everything. For good reason, we don't call a resizable string a "Hobnob" in an attempt to disambiguate, so why call a resizable array a "Vector", which makes just as much sense?


I recommend critically reading Mark Pilgrim's "Dive Into Python": http://www.diveintopython3.net/

I think that he manages to serve both audiences: new programmers, and experienced programmers who are new to Python. He achieves this, I think, through two main methods:

1. The emphasis is always on doing things. He introduces and explains the language concepts while using the constructs he's explaining to achieve an understandable task.

2. Code comes first, explanations come after. Hence the title, "Diving Into". Chapter 1 shows this very well: http://www.diveintopython3.net/your-first-python-program.htm..., as does the chapter on classes and iterators: http://www.diveintopython3.net/iterators.html

The idea is that the emphasis and structure enable experienced programmers to quickly recognize "Oh, that's how that is done here - I can move on", but new programmers can also see applications that accomplish some task, and then read line-by-line how it works. Code always has a context.


I love Mark's writing, and "Dive into Python."

I was originally intending on having the guide by driven by sample projects, but I had a hard time making it work when introducing just one thing at a time. I think that's the difference here: I want to build up from small things, rather than say "here's a big thing, you may not understand it all." That approach is the one I'll be using for the abridged guide.


In the Guessing Game, you suggest using abs() to get a nonnegative number, but this is wrong, since it would make 0 less probable than all the other values.


What is your opinion about this HN comment [0] (TL;DR the guide should be terse to a skilled profile, overly explanatory to a beginner)? I personally agree with him

[0] https://news.ycombinator.com/item?id=8306868


Fundamentally disagree. Terse is bad for teaching. There's value in having something terse for those who know they want it, but it's bad for primary material.


> Feedback very welcome.

Negative feedback is being pruned and buried.


That's not even close to true. The top comment is very negative.

A ridiculous bikeshed did get downvoted a bunch though. See https://news.ycombinator.com/item?id=8310203




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: