3 ms·

> 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively sim

> 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively simple code to compile. This exactly is why I can never get past the first couple weeks of playing with Rust. Every few months I revisit it and every couple weeks after that I put it aside again. When I was first learning C++ I spent a huge amount of my time inside the debugger trying to figure out why a pointer wasn't ... pointing. There was always a reasonable explanation that way my fault and if I had just understood what my code was really doing I would have coded things right and it wouldn't have crashed. Now we have Rust that essentially takes away that entire problem. Just wipes it out by way of a clever compiler. Only now we substitute this same learning curve "debugging" the compiler rather than debugging memory space. (Probably a better trade-off in the long run. Rust sort of bets on that being true anyway.) Go does not suffer from either of these traits. For me, Go is not often a "fun language" to code in but it's eminently practical and is remarkably fast to pick up for what it does express. I've ported a couple pieces of C# application systems to Go and they've worked really well. But it's kind of a grind unwinding the higher level abstractions from C# into the more primitive Go space. I wish there was some way to bury Rust's borrow checker for those parts of an application where you don't want to care about it and then surface it gradually when you do want it. Because the elegance of the rest of the language is what pulls me back every few months.

steveklabnik 11y ago
I'm always interested in trying to figure out how to explain these things better, if you ever want to vent some frustrations at someone :) > bury Rust's borrow checker for those parts of an application The problem with that is, if you did, you're back to > I spent a huge amount of my time inside the debugger trying > to figure out why a pointer wasn't ... pointing. What I can say is that after you get over the hump, the borrow checker isn't really a big deal. Or rather, it _is_ a big deal, but when it errors, I know it's caught a bug for me, and I can just fix it without much effort. Small comfort for those before that point thought :/
- nickpsecurity 11y ago
  I swear I've seen more than one person gripe about this. Mostly from a change of thinking but it seems recurring. Might hurt adoption. I'd have expected Rust proponents to have a link on-hand for this to a guide that teaches this stuff in a way to reduce the effect. To be clear, this is not a critique of the Rust team so much as an observation of a larger problem in PL adoption that might be affecting Rust. The trick, IIRC, was to have some smart people create a series of programming exercises that are complex enough to be a learning experience, teach a subset of the language at a time, and gradually let the concepts sink in. Practical Common LISP and Land of the LISP do this pretty well for a very confusing language. Rust will probably benefit from such a work, even more than CL. Just a suggestion in case someone's not working on it. ;) That stuff works wonders for ease-of-adoption but such writing takes talent to produce. Takes someone with strong, tech skills who can also break anything down into English a layperson can understand. As in, it's really a series of consistent abstractions that form an effective, mental foundation for using and applying the language. Not regular definitions and examples but a true, gradual, practical process. Hopefully, you've seen such a great work vs a regular, language guide so you know what I'm talking about.
  - steveklabnik 11y ago
    > I'd have expected Rust proponents to have a link on-hand for this to > a guide that teaches this stuff in a way to reduce the effect. I mean, yeah, I can link you to several. But reading a bunch of rules isn't the same as programming with them for a long time. Even once you understand the rules, the compiler will still catch you. If humans could reliably program safely without the compiler being involved, well, Rust wouldn't need to exist; C and C++ code would be written in a safe way. Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)
    - nickpsecurity 11y ago
      I'd actually like to have those links in case I take up Rust or someone I know trying it gripes about the problem. Good to have them stashed away. I see what you mean, though, if it's just rules you have to memorize and apply in many situations. Might be potential for my proposal but I'll take your word for now. "Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)" Makes sense.

steveklabnik 11y ago

I'm always interested in trying to figure out how to explain these things better, if you ever want to vent some frustrations at someone :) > bury Rust's borrow checker for those parts of an application The problem with that is, if you did, you're back to > I spent a huge amount of my time inside the debugger trying > to figure out why a pointer wasn't ... pointing. What I can say is that after you get over the hump, the borrow checker isn't really a big deal. Or rather, it _is_ a big deal, but when it errors, I know it's caught a bug for me, and I can just fix it without much effort. Small comfort for those before that point thought :/

nickpsecurity 11y ago
I swear I've seen more than one person gripe about this. Mostly from a change of thinking but it seems recurring. Might hurt adoption. I'd have expected Rust proponents to have a link on-hand for this to a guide that teaches this stuff in a way to reduce the effect. To be clear, this is not a critique of the Rust team so much as an observation of a larger problem in PL adoption that might be affecting Rust. The trick, IIRC, was to have some smart people create a series of programming exercises that are complex enough to be a learning experience, teach a subset of the language at a time, and gradually let the concepts sink in. Practical Common LISP and Land of the LISP do this pretty well for a very confusing language. Rust will probably benefit from such a work, even more than CL. Just a suggestion in case someone's not working on it. ;) That stuff works wonders for ease-of-adoption but such writing takes talent to produce. Takes someone with strong, tech skills who can also break anything down into English a layperson can understand. As in, it's really a series of consistent abstractions that form an effective, mental foundation for using and applying the language. Not regular definitions and examples but a true, gradual, practical process. Hopefully, you've seen such a great work vs a regular, language guide so you know what I'm talking about.
- steveklabnik 11y ago
  > I'd have expected Rust proponents to have a link on-hand for this to > a guide that teaches this stuff in a way to reduce the effect. I mean, yeah, I can link you to several. But reading a bunch of rules isn't the same as programming with them for a long time. Even once you understand the rules, the compiler will still catch you. If humans could reliably program safely without the compiler being involved, well, Rust wouldn't need to exist; C and C++ code would be written in a safe way. Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)
  - nickpsecurity 11y ago
    I'd actually like to have those links in case I take up Rust or someone I know trying it gripes about the problem. Good to have them stashed away. I see what you mean, though, if it's just rules you have to memorize and apply in many situations. Might be potential for my proposal but I'll take your word for now. "Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)" Makes sense.