This repository has been archived by the owner. It is now read-only.

Rust should have a lower learning curve #3

Open
aturon opened this Issue Nov 7, 2016 · 21 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Nov 7, 2016

Overview

Rust offers a unique value proposition in part because it offers a unique feature: its ownership model. Because the concept is not (yet!) a widespread one in other languages, it is something most people have to learn from scratch before hitting their stride with Rust. And that often comes on top of other aspects of Rust that may be less familiar. A common refrain is "the first couple of weeks are tough, but it's oh so worth it." How many people are bouncing off of Rust in those first couple of weeks? How many team leads are reluctant to introduce Rust because of the training needed? (1 in 4 survey respondents mentioned the learning curve.)

Here are some strategies we might take to lower the learning curve:

  • Improved docs. While the existing Rust book has been successful, we've learned a lot about teaching Rust, and there's a rewrite in the works. The effort is laser-focused on the key areas that trip people up today (ownership, modules, strings, errors).

  • Gathering cookbooks, examples, and patterns. One way to quickly get productive in a language is to work from a large set of examples and known-good patterns that can guide your early work. As a community, we could push crates to include more substantial example code snippets, and organize efforts around design patterns and cookbooks. (See the commentary on the RFC thread for much more detail.)

  • Improved errors. We've already made some big strides here, particularly for ownership-related errors, but there's surely more room for improvement.

  • Improved language features. There are a couple of ways that the language design itself can be oriented toward learnability. First, we can introduce new features with an explicit eye toward how they will be taught. Second, we can improve existing features to make them easier to understand and use -- things like non-lexical lifetimes being a major example. There's already been some discussion on internals

  • IDEs and other tooling. IDEs provide a good opportunity for deeper teaching. An IDE can visualize errors, for example showing you the lifetime of a borrow. They can also provide deeper inspection of what's going on with things like method dispatch, type inference, and so on.

Projects

Documentation

Language improvements

Compiler improvements

  • Currently no sustained work on further improving error messages, but this is an area we should revisit.

Tooling improvements

Data points

@aturon aturon added the Vision label Nov 7, 2016

@rjammala

This comment has been minimized.

Show comment
Hide comment
@rjammala

rjammala Nov 14, 2016

Also, please consider adding as many screencasts as possible to http://intorust.com/
I found it very useful and instructive.

Also, please consider adding as many screencasts as possible to http://intorust.com/
I found it very useful and instructive.

@Selhar

This comment has been minimized.

Show comment
Hide comment
@Selhar

Selhar Jan 31, 2017

I'm currently learning rust, and what has worked for me was using the rust book and docs as one big reference material, since the book is far too dry to read from cover to cover. "Rust essentials" is better at teaching rust as a language instead of a reference material, however it lacks in depth at times.
Using "rust essentials" as a guideline, rust book as a reference material and project euler / hackerrank's 30 days of code exercises has been the most effective method for me.

One other thing that has been problematic for me as a beginner is rust's IO, it was quite difficult to figure it out how to parse input into other data types, finding a snippet that works is fairly easy but understanding how it works was nightmarish. Specially for beginners that can be a let down, as most exercises expect you to use IO effectively.

Selhar commented Jan 31, 2017

I'm currently learning rust, and what has worked for me was using the rust book and docs as one big reference material, since the book is far too dry to read from cover to cover. "Rust essentials" is better at teaching rust as a language instead of a reference material, however it lacks in depth at times.
Using "rust essentials" as a guideline, rust book as a reference material and project euler / hackerrank's 30 days of code exercises has been the most effective method for me.

One other thing that has been problematic for me as a beginner is rust's IO, it was quite difficult to figure it out how to parse input into other data types, finding a snippet that works is fairly easy but understanding how it works was nightmarish. Specially for beginners that can be a let down, as most exercises expect you to use IO effectively.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jan 31, 2017

Member

@GregoryGoncalves the new book has a whole chapter on IO, covering env variables, command-line arguments, and files: http://rust-lang.github.io/book/ch12-00-an-io-project.html

Member

steveklabnik commented Jan 31, 2017

@GregoryGoncalves the new book has a whole chapter on IO, covering env variables, command-line arguments, and files: http://rust-lang.github.io/book/ch12-00-an-io-project.html

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Feb 6, 2017

Member

Another potential area of focus: rustdoc. Since that's the way a lot of people encounter APIs, making rustdoc's output as clear and useful as possible is extremely important. See this thread about Rocket for an example.

If anyone listening is interested in taking on rustdoc work, please let me know!

Member

aturon commented Feb 6, 2017

Another potential area of focus: rustdoc. Since that's the way a lot of people encounter APIs, making rustdoc's output as clear and useful as possible is extremely important. See this thread about Rocket for an example.

If anyone listening is interested in taking on rustdoc work, please let me know!

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Feb 6, 2017

Member
Member

steveklabnik commented Feb 6, 2017

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Feb 6, 2017

Collaborator

@steveklabnik - let's chat. I'm actually meeting with @alexcrichton to brainstorm in an hour and a half. Putting some notes together now.

Collaborator

jonathandturner commented Feb 6, 2017

@steveklabnik - let's chat. I'm actually meeting with @alexcrichton to brainstorm in an hour and a half. Putting some notes together now.

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Feb 7, 2017

I'd think the module system concerns mostly boils down to error messages, i.e. you might want implicit modules not so much because you want people to use them but because you need the compiler to examine the source files that lack a mod directive so that it can say "You wrote my_mod::foo() but you forgot to add mod my_mod;."

burdges commented Feb 7, 2017

I'd think the module system concerns mostly boils down to error messages, i.e. you might want implicit modules not so much because you want people to use them but because you need the compiler to examine the source files that lack a mod directive so that it can say "You wrote my_mod::foo() but you forgot to add mod my_mod;."

@mbrubeck

This comment has been minimized.

Show comment
Hide comment
@mbrubeck

mbrubeck Feb 9, 2017

Errors caused by linking to multiple versions of a crate are a very common source of questions on IRC. For example, a project depends on crate A, which depends on serde 0.8, and also crate B, which depends on serde 0.9. Passing types from crate A to functions from crate B doesn't work, because they implement the wrong versions of the serde traits.

Solving this usually involves multiple steps:

  1. Recognize the cause of the problem. Improved compiler diagnostics have helped this somewhat, but there still seem to be mysterious errors in some cases. (rust-lang/rust#22750)
  2. Examine Cargo.lock to see which crate(s) have multiple versions being built. (Really this only matters if these crates are "public dependencies" in the rust-lang/cargo#2064 sense.)
  3. Work backward through the dependency graph to see which direct dependencies depend on different versions of the same indirect dependency. (Tools like cargo-tree can make steps 2 and 3 easier.)
  4. Search crates.io to see if there is a set of versions of these direct dependencies which have compatible constraints on the indirect dependencies.

If step 4 finds a viable set of dependency versions, then the solution is to edit Cargo.toml to specify those versions. If not, then a possible next step is to check the lagging crates' repositories to see if there are any forks or branches with updated dependencies, or create such a fork if not.

All of this process is difficult both to discover and to execute. It would be useful to automate as much of it as possible, for example by adding logic to Cargo to find and suggest sets of crate versions that are likely to "play well" together. This would likely require some imperfect guessing, though additional metadata like rust-lang/cargo#2064 could improve the accuracy.

mbrubeck commented Feb 9, 2017

Errors caused by linking to multiple versions of a crate are a very common source of questions on IRC. For example, a project depends on crate A, which depends on serde 0.8, and also crate B, which depends on serde 0.9. Passing types from crate A to functions from crate B doesn't work, because they implement the wrong versions of the serde traits.

Solving this usually involves multiple steps:

  1. Recognize the cause of the problem. Improved compiler diagnostics have helped this somewhat, but there still seem to be mysterious errors in some cases. (rust-lang/rust#22750)
  2. Examine Cargo.lock to see which crate(s) have multiple versions being built. (Really this only matters if these crates are "public dependencies" in the rust-lang/cargo#2064 sense.)
  3. Work backward through the dependency graph to see which direct dependencies depend on different versions of the same indirect dependency. (Tools like cargo-tree can make steps 2 and 3 easier.)
  4. Search crates.io to see if there is a set of versions of these direct dependencies which have compatible constraints on the indirect dependencies.

If step 4 finds a viable set of dependency versions, then the solution is to edit Cargo.toml to specify those versions. If not, then a possible next step is to check the lagging crates' repositories to see if there are any forks or branches with updated dependencies, or create such a fork if not.

All of this process is difficult both to discover and to execute. It would be useful to automate as much of it as possible, for example by adding logic to Cargo to find and suggest sets of crate versions that are likely to "play well" together. This would likely require some imperfect guessing, though additional metadata like rust-lang/cargo#2064 could improve the accuracy.

@nox

This comment has been minimized.

Show comment
Hide comment
@nox

nox Feb 25, 2017

Errors caused by linking to multiple versions of a crate are a very common source of questions on IRC. For example, a project depends on crate A, which depends on serde 0.8, and also crate B, which depends on serde 0.9. Passing types from crate A to functions from crate B doesn't work, because they implement the wrong versions of the serde traits.

This wouldn't happen if cargo didn't update all point releases for no reason whenever it can, settling on trying to find a common compatible version of all crates.

This also wouldn't happen if people properly did breaking bumps in their project for breaking bumps in their dependencies, but apparently not everyone agree that this is what should be done.

nox commented Feb 25, 2017

Errors caused by linking to multiple versions of a crate are a very common source of questions on IRC. For example, a project depends on crate A, which depends on serde 0.8, and also crate B, which depends on serde 0.9. Passing types from crate A to functions from crate B doesn't work, because they implement the wrong versions of the serde traits.

This wouldn't happen if cargo didn't update all point releases for no reason whenever it can, settling on trying to find a common compatible version of all crates.

This also wouldn't happen if people properly did breaking bumps in their project for breaking bumps in their dependencies, but apparently not everyone agree that this is what should be done.

@mbrubeck

This comment has been minimized.

Show comment
Hide comment
@mbrubeck

mbrubeck Feb 25, 2017

This wouldn't happen if cargo didn't update all point releases for no reason whenever it can, settling on trying to find a common compatible version of all crates.

It wouldn’t happen then when updating an existing project, but it would still be an issue when creating a new project, for example if one crate has released a version that uses serde 0.9 while another crate is still using serde 0.8 in its latest release. Someone creating a project that calls generic functions from crate A using types from crate B can’t simply choose the latest release of each from crates.io.

This wouldn't happen if cargo didn't update all point releases for no reason whenever it can, settling on trying to find a common compatible version of all crates.

It wouldn’t happen then when updating an existing project, but it would still be an issue when creating a new project, for example if one crate has released a version that uses serde 0.9 while another crate is still using serde 0.8 in its latest release. Someone creating a project that calls generic functions from crate A using types from crate B can’t simply choose the latest release of each from crates.io.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Feb 25, 2017

Member

settling on trying to find a common compatible version of all crates.

This is an NP-Hard problem. There's an open issue on Cargo for a year or two to integrate with an SMT solver but no one has stepped up to actually do the work.

Member

sfackler commented Feb 25, 2017

settling on trying to find a common compatible version of all crates.

This is an NP-Hard problem. There's an open issue on Cargo for a year or two to integrate with an SMT solver but no one has stepped up to actually do the work.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Feb 28, 2017

Member

Here's a nice post talking about some roadblocks to learning Rust today.

Member

aturon commented Feb 28, 2017

Here's a nice post talking about some roadblocks to learning Rust today.

@RUSshy

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 28, 2017

Don't try to mimic how they did with c/c++/ or other old and ugly language, just learn from Java/C#/JS, how easy it is just just learn and start to use it to build, i'm noob, and i first tried c, then c++, i hated them cause they feel old, IDE/DOC/SYNTAX is just boring to read on eyes, so i gave up and then found, Java, then C#, it was so smooth to learn compared to C/C++, please see how modern langauge do, even Kotlin, it is so nice to learn and read

RUSshy commented Feb 28, 2017

Don't try to mimic how they did with c/c++/ or other old and ugly language, just learn from Java/C#/JS, how easy it is just just learn and start to use it to build, i'm noob, and i first tried c, then c++, i hated them cause they feel old, IDE/DOC/SYNTAX is just boring to read on eyes, so i gave up and then found, Java, then C#, it was so smooth to learn compared to C/C++, please see how modern langauge do, even Kotlin, it is so nice to learn and read

@RUSshy

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 28, 2017

Look at this beauty, learning is just a game, so easy to understand with example, not just block of boring text http://try.kotlinlang.org/

RUSshy commented Feb 28, 2017

Look at this beauty, learning is just a game, so easy to understand with example, not just block of boring text http://try.kotlinlang.org/

@RUSshy

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 28, 2017

In your new book here http://rust-lang.github.io/book/ch02-00-guessing-game-tutorial.html

Code isn't even documented, you have to search what happens in block of text, then check back code, then check back block of text, need to find where you left, then check back code... this is plain boring and non-user friendly, computer isn't a book, it is meant to be interactive, like that kotlin page

I want to learn native language, but why it is just boring, hard to read and old looking ??

RUSshy commented Feb 28, 2017

In your new book here http://rust-lang.github.io/book/ch02-00-guessing-game-tutorial.html

Code isn't even documented, you have to search what happens in block of text, then check back code, then check back block of text, need to find where you left, then check back code... this is plain boring and non-user friendly, computer isn't a book, it is meant to be interactive, like that kotlin page

I want to learn native language, but why it is just boring, hard to read and old looking ??

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Feb 28, 2017

Member

Code isn't even documented, you have to search what happens in block of text

The block of text contains the relevant bits of code, though. The idea is that you read the text and refer to the full code, not the other way around.

What you're looking for is http://rustbyexample.com/ . The book isn't intended to be everything at once.

Member

Manishearth commented Feb 28, 2017

Code isn't even documented, you have to search what happens in block of text

The block of text contains the relevant bits of code, though. The idea is that you read the text and refer to the full code, not the other way around.

What you're looking for is http://rustbyexample.com/ . The book isn't intended to be everything at once.

@RUSshy

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 28, 2017

Oh thanks this is better i can test what happen directly, would still love some more example like the kotlin one

RUSshy commented Feb 28, 2017

Oh thanks this is better i can test what happen directly, would still love some more example like the kotlin one

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Feb 28, 2017

Member

@RUSshy It'd be great to leave this feedback directly on the resources, rather than on this tracking issue (which is used for broader discussion about learning curve goals).

Member

aturon commented Feb 28, 2017

@RUSshy It'd be great to leave this feedback directly on the resources, rather than on this tracking issue (which is used for broader discussion about learning curve goals).

@RUSshy

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 28, 2017

oh sorry! Can you link me the resources page please ? is it the forum ?

RUSshy commented Feb 28, 2017

oh sorry! Can you link me the resources page please ? is it the forum ?

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents

carols10cents Feb 28, 2017

Member

oh sorry! Can you link me the resources page please ? is it the forum ?

@RUSshy The repo for the new book is here: https://github.com/rust-lang/book and rustbyexample.com's repo is here: https://github.com/rust-lang/rust-by-example

computer isn't a book, it is meant to be interactive

NoStarch is going to be printing the new book, though, so it will be a book, and we're writing it with print primarily in mind.

Member

carols10cents commented Feb 28, 2017

oh sorry! Can you link me the resources page please ? is it the forum ?

@RUSshy The repo for the new book is here: https://github.com/rust-lang/book and rustbyexample.com's repo is here: https://github.com/rust-lang/rust-by-example

computer isn't a book, it is meant to be interactive

NoStarch is going to be printing the new book, though, so it will be a book, and we're writing it with print primarily in mind.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 13, 2017

Member

Added the Rust Cookbook.

Member

aturon commented Apr 13, 2017

Added the Rust Cookbook.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.