4 ms·

I do think a lot of it is inherent in the design choices that Rust has made. Rust, as a language, has a fairly large surface area. There's a lot of different sy

I do think a lot of it is inherent in the design choices that Rust has made. Rust, as a language, has a fairly large surface area. There's a lot of different syntactical and conceptual lessons that need to be learned by new Rust programmers. Compare that to, say, Lisp. My first programming class at Berkeley was taught in Scheme, which is basically Lisp. Within the first 20 minutes of the first day, the professor had not only gone over a bunch of introductory announcements, but he'd also introduced us to every bit of syntax we would learn in the course. The second lecture covered car/cdr and recursion. Beyond those two lessons, everything we learned was about the practice of programming, not the language we were programming in. Rust occupies a fairly unique position of being high level, with lots of abstractions to make experienced programmers more productive, and low level with fairly precise control over lower-level hardware concerns. That's really impressive, but I do believe that impressive power comes at the cost of an unavoidable learning curve. You'll never get a backhoe to be as simple to operate as a shovel. Which isn't to say that there isn't ample opportunity for the work that you and Carol are doing to make learning Rust easier--beginners now have it much easier than people like me that jumped in around 0.8. But it is to say that I don't think it's possible to ever make Rust as easy to learn as conceptually simpler languages. If I were designing a CS curriculum, I'd start new students with a Lisp dialect, then move on to Assembly (which, while hard, provides what is, to me, an essential view of the actual hardware that you're using) and then move on to the more practical languages. I'd still like to teach Rust, but it would come later to help introduce advanced concepts like compilers and operating systems.

steveklabnik 9y ago
> Compare that to, say, Lisp. This makes me think of the module reform RFC: > In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious. See also Rich Hickey's "simple made easy." I do think Rust has some inherent learning curve, but I also don't necessarily agree with this framing. Simpler languages aren't always simpler to actually write software in.
- curun1r 9y ago
  > Simpler languages aren't always simpler to actually write software in. I completely agree with this. But when you're learning to program, the goal isn't to write software. It's to learn the lessons and concepts that will one day allow you to write software.
  - steveklabnik 9y ago
    This is probably where we disagree. The style you're advocating is "bottom-up" learning, that is, you learn the fundamentals, and then build from there. This is totally valid, but in my general experience of years of teaching, both professionally, and as a hobby, most people don't learn like that. I personally learn like that, so it's a bit frustrating to me that this is true! Most people want to start "top-down", that is, write something useful. After they've got things working, then they want to "dive deeper" and go back down and learn the fundamentals. It's an spiral, not a direct path. Another way to think about this is that bottom-up learning is the same spiral, but at a different level of abstraction. You're teaching software, but not hardware. You don't force people to learn about OSes before they learn about software. You don't force people to learn about hardware before they learn about software. You don't force people to learn about physics before they learn about hardware.
    - smoe 9y ago
      Do you think this depends on the peoples prior experience level whether they prefer either way? Or is mostly personal? At least in my case I remember when I had C as a first language in school about 14 years ago, after an initial rush of joy, I got a bit frustrated because I couldn't build anything "cool" and practical quickly. I was relieved when we went on to the much more practical seeming Java. But these days I have all the tools I need to get stuff done quickly and prefer learning new things more bottom-up. In fact top-down often annoys me, because it presumes what I might find useful. I think a mixed approach as often used when teaching musical instruments could work well. For example justin guitar online course splits up the practice sessions in parts that are tedious muscle-memory/rhythm training you have to push trough and parts to teach you songs from various genres as quickly as possible. So you can actually apply and most importantly enjoy what you are learning from week one. Additionally he strongly encourages doing explicit ear training and some music theory from the get go for the long term benefit. Translated to Rust I think something like rustbyexample.com but instead of splitting it up by language features, have it categorized by domain and experience level would be pretty cool. If I'm interesting in game development I can start right away with simple cli games and later add graphics and if I'm into networked services I choose that path. Both point to the same deeper concepts but like when learning an instrument it is much more encouraging when at any level you can play the types of music you like instead of having to play what the teacher likes.
Rusky 9y ago
> he'd also introduced us to every bit of syntax we would learn in the course. This doesn't seem like a very meaningful distinction to me. Lisp may not have a lot of syntax, but it still has a comparable number of features to other languages used in intro classes. You have to learn those features as you encounter them regardless of whether they come with new syntax or not, and the new syntax frankly isn't the hard part of that. Rust certainly has more features than Scheme, of course. :)

steveklabnik 9y ago

> Compare that to, say, Lisp. This makes me think of the module reform RFC: > In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious. See also Rich Hickey's "simple made easy." I do think Rust has some inherent learning curve, but I also don't necessarily agree with this framing. Simpler languages aren't always simpler to actually write software in.

curun1r 9y ago
> Simpler languages aren't always simpler to actually write software in. I completely agree with this. But when you're learning to program, the goal isn't to write software. It's to learn the lessons and concepts that will one day allow you to write software.
- steveklabnik 9y ago
  This is probably where we disagree. The style you're advocating is "bottom-up" learning, that is, you learn the fundamentals, and then build from there. This is totally valid, but in my general experience of years of teaching, both professionally, and as a hobby, most people don't learn like that. I personally learn like that, so it's a bit frustrating to me that this is true! Most people want to start "top-down", that is, write something useful. After they've got things working, then they want to "dive deeper" and go back down and learn the fundamentals. It's an spiral, not a direct path. Another way to think about this is that bottom-up learning is the same spiral, but at a different level of abstraction. You're teaching software, but not hardware. You don't force people to learn about OSes before they learn about software. You don't force people to learn about hardware before they learn about software. You don't force people to learn about physics before they learn about hardware.
  - smoe 9y ago
    Do you think this depends on the peoples prior experience level whether they prefer either way? Or is mostly personal? At least in my case I remember when I had C as a first language in school about 14 years ago, after an initial rush of joy, I got a bit frustrated because I couldn't build anything "cool" and practical quickly. I was relieved when we went on to the much more practical seeming Java. But these days I have all the tools I need to get stuff done quickly and prefer learning new things more bottom-up. In fact top-down often annoys me, because it presumes what I might find useful. I think a mixed approach as often used when teaching musical instruments could work well. For example justin guitar online course splits up the practice sessions in parts that are tedious muscle-memory/rhythm training you have to push trough and parts to teach you songs from various genres as quickly as possible. So you can actually apply and most importantly enjoy what you are learning from week one. Additionally he strongly encourages doing explicit ear training and some music theory from the get go for the long term benefit. Translated to Rust I think something like rustbyexample.com but instead of splitting it up by language features, have it categorized by domain and experience level would be pretty cool. If I'm interesting in game development I can start right away with simple cli games and later add graphics and if I'm into networked services I choose that path. Both point to the same deeper concepts but like when learning an instrument it is much more encouraging when at any level you can play the types of music you like instead of having to play what the teacher likes.

Rusky 9y ago

> he'd also introduced us to every bit of syntax we would learn in the course. This doesn't seem like a very meaningful distinction to me. Lisp may not have a lot of syntax, but it still has a comparable number of features to other languages used in intro classes. You have to learn those features as you encounter them regardless of whether they come with new syntax or not, and the new syntax frankly isn't the hard part of that. Rust certainly has more features than Scheme, of course. :)