5 ms·

The thing is, learning Rust is Hard, with a capital H. Even experienced programmers have to work really hard to grasp it. I’ve started the process but the light

The thing is, learning Rust is Hard, with a capital H. Even experienced programmers have to work really hard to grasp it. I’ve started the process but the light has not yet switched on. I want to be great at Rust, but I’m nowhere near there. Getting basic things done like defining functions, passing data remain challenging every single step of the way. For this reason alone, Rust will remain the domain of dedicated and motivated programmers. It’s never going to be crowded in this community. Unless of course I’m a slow witted dunce, in which case, maybe Rust ain’t hard.

radicalriddler 5y ago
Definitely agreed. I'm just a lowly javascript developer, but getting my head around the borrowing and ownership concepts is pretty challenging for me. Just need to keep practicing though. I still remember the day that javascript clicked for me, so hopefully the same will happen for rust.
retrac 5y ago
Like with functional programming, I'm not sure it's hard, exactly. Maybe it's not so hard if you learn it from the start. It is very different, though. Most programmers are not used to the idea of carefully tracking where, and how, their data ends up in a program. Many high-level languages do heavy lifting to abstract that away as much as possible. Is it on the stack or in the heap? Is it a copy or a reference? How many references to it are floating around? You don't need to worry about that. The implementation will juggle that for you. Rust is targeted pretty much as a C replacement. And the thing is, you have to do the borrow checker's work when you program in C too. You must know whether it's copy-by-value or a reference. If it's a reference and it needs to be a copy, you must do that manually. You must know how many threads are accessing something by a reference, and you must guarantee that more than one thread is not writing a non-mutex variable at the same time. You must know when your objects are created, where they go (heap? stack?) and you must track those objects over their lifetime, and then you must free them at the end. (Or tell a garbage collector about them, and remember to run the garbage collector periodically.) Except a C program still compiles when you don't get that right. And then it segfaults. Rust's borrowing model ends up enforcing much of that as language policy, rather than just good programming style. It's a bit like how you have to cast types explicitly in many languages (including Rust, of course). Any implementation can wrap an integer used as a pointer to guarantee you're not pointing into dead memory. But when the compiler knows the type explicitly, it can often generate fast unwrapped code that is safe and will not crash. All of this comes with explicitness which is burdensome to the programmer, unfortunately. Sometimes you need to state, explicitly, what should be obvious to allow the compiler to show something is correct and fast. In this regard, Rust is, at least, nicer than C, even when you have to fight the borrow checker. (In my opinion.) Which is probably why it's growing so fast. I don't expect it to displace more than the C niche of systems programming, though.
- terminalserver 5y ago
  One forgets how hard it was to climb the mountain once one has climbed the mountain.
  - retrac 5y ago
    You're right, in fairness. It's gruelling sometimes. Five years of on-off hobby programming with Rust and I still fight the borrow checker with every other function. How to implement things in a way that makes Rust happy is often not at all obvious. But the idea does seem useful enough to keep persisting at it.
    - Measter 5y ago
      I'm really curious why some people have such a hard time picking it up. My experience has been the complete opposite, everything just clicked and it all made sense (at least, until you get to the gnarly stuff). What was the difference in our mental models that caused this?
      - retrac 5y ago
        The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how do I express working things in it? The obvious approaches conflict with the rules. A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe. How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.
        zozbot234 5y ago
        > But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. ... How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? You can use atomic types with custom memory ordering, just like you would in C.
diragon 5y ago
I think learning a programming language has similar logic/intuition that learning natural languages has. That is, learning a language that you actually use is much easier than learning a language you don't use. So for instance, if you just read tutorials / grammar books and never actually solve problems / communicate with people you will have a harder time. It matters less how difficult the language actually is -- you can easily spend months or even years wrestling with those tutorials without getting beyond a beginner stage. Then you get some motivation to actually use it for something and you advance in weeks more than you advanced in a year before. Rust especially, thanks to the efficient hypemachine, will have the problem of people wanting to learn it but not having anywhere to apply it immediately. I actually have a similar problem with French.
- A-Train 5y ago
  I like the analogy to learning a language. The immersion is very important. I did exactly what you said. I didn't read many tutorials I just sat down and rewrote a project in Rust. I don't use lifetimes properly right now (I abuse cloning many times) but I am happy with the progress. Another thing worth mentioning is that while being a great language Rust is still a tool. Designing the architecture, algorithms, logic of the system, refactoring are much more difficult than the language itself in my opinion.
willtim 5y ago
This is of course why garbage collected languages exist. If you don't need the performance or efficiency gained from having full control of memory, then GC'd languages will offer less cognitive load. IMHO, programming in Rust is no harder than C++ or C. It just forces one to be explicit about lifetimes and ownership, concepts one should be carefully thinking about in other systems programming languages.
tech_tuna 5y ago
But if that extra complexity and difficulty helps to improve the overall quality and safety of the code people write with it, then maybe it's worth it? Or put another way, C and C++ make some things easy when perhaps they shouldn't.
orwin 5y ago
Rust is hard, but it is easiER if you did a lot of C programming prior to that (with memory/mutex managment and all). If you did not, i expect the learning curve to be really steep.

radicalriddler 5y ago

Definitely agreed. I'm just a lowly javascript developer, but getting my head around the borrowing and ownership concepts is pretty challenging for me. Just need to keep practicing though. I still remember the day that javascript clicked for me, so hopefully the same will happen for rust.

retrac 5y ago

Like with functional programming, I'm not sure it's hard, exactly. Maybe it's not so hard if you learn it from the start. It is very different, though. Most programmers are not used to the idea of carefully tracking where, and how, their data ends up in a program. Many high-level languages do heavy lifting to abstract that away as much as possible. Is it on the stack or in the heap? Is it a copy or a reference? How many references to it are floating around? You don't need to worry about that. The implementation will juggle that for you. Rust is targeted pretty much as a C replacement. And the thing is, you have to do the borrow checker's work when you program in C too. You must know whether it's copy-by-value or a reference. If it's a reference and it needs to be a copy, you must do that manually. You must know how many threads are accessing something by a reference, and you must guarantee that more than one thread is not writing a non-mutex variable at the same time. You must know when your objects are created, where they go (heap? stack?) and you must track those objects over their lifetime, and then you must free them at the end. (Or tell a garbage collector about them, and remember to run the garbage collector periodically.) Except a C program still compiles when you don't get that right. And then it segfaults. Rust's borrowing model ends up enforcing much of that as language policy, rather than just good programming style. It's a bit like how you have to cast types explicitly in many languages (including Rust, of course). Any implementation can wrap an integer used as a pointer to guarantee you're not pointing into dead memory. But when the compiler knows the type explicitly, it can often generate fast unwrapped code that is safe and will not crash. All of this comes with explicitness which is burdensome to the programmer, unfortunately. Sometimes you need to state, explicitly, what should be obvious to allow the compiler to show something is correct and fast. In this regard, Rust is, at least, nicer than C, even when you have to fight the borrow checker. (In my opinion.) Which is probably why it's growing so fast. I don't expect it to displace more than the C niche of systems programming, though.

terminalserver 5y ago
One forgets how hard it was to climb the mountain once one has climbed the mountain.
- retrac 5y ago
  You're right, in fairness. It's gruelling sometimes. Five years of on-off hobby programming with Rust and I still fight the borrow checker with every other function. How to implement things in a way that makes Rust happy is often not at all obvious. But the idea does seem useful enough to keep persisting at it.
  - Measter 5y ago
    I'm really curious why some people have such a hard time picking it up. My experience has been the complete opposite, everything just clicked and it all made sense (at least, until you get to the gnarly stuff). What was the difference in our mental models that caused this?
    - retrac 5y ago
      The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how do I express working things in it? The obvious approaches conflict with the rules. A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe. How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.
      - zozbot234 5y ago
        > But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. ... How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? You can use atomic types with custom memory ordering, just like you would in C.

diragon 5y ago

I think learning a programming language has similar logic/intuition that learning natural languages has. That is, learning a language that you actually use is much easier than learning a language you don't use. So for instance, if you just read tutorials / grammar books and never actually solve problems / communicate with people you will have a harder time. It matters less how difficult the language actually is -- you can easily spend months or even years wrestling with those tutorials without getting beyond a beginner stage. Then you get some motivation to actually use it for something and you advance in weeks more than you advanced in a year before. Rust especially, thanks to the efficient hypemachine, will have the problem of people wanting to learn it but not having anywhere to apply it immediately. I actually have a similar problem with French.

A-Train 5y ago
I like the analogy to learning a language. The immersion is very important. I did exactly what you said. I didn't read many tutorials I just sat down and rewrote a project in Rust. I don't use lifetimes properly right now (I abuse cloning many times) but I am happy with the progress. Another thing worth mentioning is that while being a great language Rust is still a tool. Designing the architecture, algorithms, logic of the system, refactoring are much more difficult than the language itself in my opinion.

willtim 5y ago

This is of course why garbage collected languages exist. If you don't need the performance or efficiency gained from having full control of memory, then GC'd languages will offer less cognitive load. IMHO, programming in Rust is no harder than C++ or C. It just forces one to be explicit about lifetimes and ownership, concepts one should be carefully thinking about in other systems programming languages.

tech_tuna 5y ago

But if that extra complexity and difficulty helps to improve the overall quality and safety of the code people write with it, then maybe it's worth it? Or put another way, C and C++ make some things easy when perhaps they shouldn't.

orwin 5y ago

Rust is hard, but it is easiER if you did a lot of C programming prior to that (with memory/mutex managment and all). If you did not, i expect the learning curve to be really steep.