Ideas for making Rust easier for Beginners

[carols10cents]

Another is documentation. It strangely avoids any assumptions that the reader has programming experience and is trying to explain as for non-programmer of age of 5. Let’s face the fact, Rust in the nearest future is choice of hacker minded people. Please, provide some references to Java and C++ programmers. For example, how traits are different from interfaces. Split section 4 of the book into several subsections please. Right now it contains 80% of the language.

You may be interested in the in-progress rewrite of the book. If you have any feedback on the new version, please file an issue!

[bestouff]

Of the last proposition (python slicing syntax) I would only keep the negative bounds; they look really handy and natural. OTOH the “step” conveys something else which does not belong here IMO.

+1 for @zackw 's view of the first proposition.

[repax]

I’d rather have negative slice bounds cause a panic than silently corrupt the state.

[konstin]

The idea is that negativ indices should become an (imho extremely useful) feature, so there’s no point in panicking.

[repax]

An erroneous calculation resulting in a negative index ought to be dealt with stringently. Remember, Rust is trying to be a safe language.

Therefore such mistakes should, as a first line of defence, be caught at compile-time. And, when this is not possible, at the very least cause a panic so as to not have state corruption creep in. Rust already employs the fail fast principle to great succcess in many cases.

[konstin]

If your value is only valid for non-negative integers, then you should have used a usize in the first place. This fully solves this problem on the compiler level, which btw is much more the rust way than panicking. Otherwise, why would you forbid using a great syntactic sugar only because you might have a bug in different part of the code? From the sight of language design this makes no sense. It’s like forbidding ring buffers because you could get to wrapping range by using the wrong index: The bug is still not the buffer but the index computation.

[notriddle]

You don’t have to use negative indexing just to have indexing from the end. You can do that with a method, like:

assert_eq!(3, [1, 2, 3].end(0));
assert_eq!(Some(2), [1, 2, 3].get_end(1));

Way more readable than negative indexing, especially since it can be zero indexed (I’ve tried to use list[-0] too many times in Python…).

[scottmcm]

I’m a wary of negative indexing since it mixes poorly. It’s hard to tell whether v[-4..2] is empty, for example.

Hmm, .rev() does propagate RandomAccessIterator, but it has unstable idx, not Index. I wonder what it would take for something like [1, 2, 3].rev()[0] to work. I agree with the desire to keep using [] for indexing, even backwards, instead of methods that feel second-class.

[konstin]

I’m a wary of negative indexing since it mixes poorly. It’s hard to tell whether v[-4…2] is empty, for example.

This should simply be handled in the same way as e.g. v[3..2] is handled. The v[-4..2] is a very rare edge-case anyway and would be bad practice as in intentional code obfuscation.

[scottmcm]

v[3..2] is clearly and unambiguously empty for all v.

But v[-4..2]? For len<4, converting the isize to the correct usize index overflows unless done carefully, but I guess it has two elements? For len 4 it has two elements, for len 5 it has one element. For len>5 it’s empty. That’s substantially more work to reason about.

If that kind of thing is possible, then anything taking signed indexes needs to deal with it, even if it’s bad style.

[leonardo]

Negative indexes is a bad idea. Take a look at the much better D language solution, it uses "-i", where is a contextual variable that’s equal to len().

[repax]

What you’re asking for, @konstin, is the confounding of two types of operations (forward and backward indexing) into the same value. This will only make reasoning about dynamically computed indices more complicated and error-prone.

There’s no reason to believe that “beginners” would find negative indices easier. If anything, it’s just yet another special case. Just say `v[2 … v.len()-3] if this is what you mean.

[vi0]

Ideas for making Rust easier for Beginners

Maybe make a playpen-based environment where users can also:

• Report that they are fed up and abandoning attempts (with optional comment). Maybe analysing the “graveyard” database of such snippets may point to the typically tricky, hard-to-get parts.
• Request help (of a bot and/or a human)
• Do some exercises from a book sequentially (with automatic tests)? There may be dedicated customized auto-help based on possible error messages when doing them wrong.

[johnthagen]

Do some exercises from a book sequentially (with automatic tests)? There may be dedicated customized auto-help based on possible error messages when doing them wrong.

+1 This is a cool idea.

[vi0]

Next playpen idea:

Dual pane playpen: library + app.

With this one can experiment with orphan rules, Macros 1.1, etc.

Also users will subconsciously prepare to libify there code from early. Also help requests about creating libraries can have nice playpen links.

Obviously, default view should be single-pane.

[DanielKeep]

Seems like it would be better to just support something like multipart scripts that expand to multiple files. Then you could put more complete multi-file examples into a playpen.

[konstin]

I like the idea of some improved playpen kind of thing, but that idea should be better discussed in its own thread. I’ve just collected my own ideas in this thread to avoid spamming.

Anyways, is the any feedback on my ideas besides generics and negative indices?

[Ixrec]

Since you asked:

For “Shorten the Compiler’s Type Errors” and “Allow tests to work through visibility and scope borders”, I simply don’t understand the points being made well enough to respond to them. But these both sound like they might be good ideas, so I’d suggest starting separate threads to explain them in more detail with concrete examples for people like me that aren’t bothered by whatever these problems are.

For “From and To in the html docs” I couldn’t quite parse what you were trying to say, but if you’re suggesting some kind of special case in rustdoc for aggregating From impls, To impls, etc in a way that makes the full list of impls more readable then I’m 100% with you on that.

[ekuber]

When there are type mismatches, which can be caused by a variety of problems,the compiler tends to print extremly long lines creating badly understandable error messages. Those error messages should be broken down to fit in a 120 char line. It would be an extra sugar if the compiler would also propose specific solutions.

I’m working on making these errors slightly easier to read:

[Enamex]

Isn’t the example equivalent to

fn take_iterator(it: impl Iterator) {}

, though?