3 ms·

Disclaimer: I say this having spent much of last year learning Go and the last couple months learning Rust. I'm a big fan of both languages. I see Go as my go t

by curun1r 11y ago

Disclaimer: I say this having spent much of last year learning Go and the last couple months learning Rust. I'm a big fan of both languages. I see Go as my go to language for more situations right now, but I think that once Rust has matured a bit more, I'll choose it for more and it will probably become more useful to me than Go. I doubt I'll ever get to the point where I'd choose it for everything over Go, but I can see that possibility. That said, if you haven't already, I think you should learn Haskell instead. Learning Haskell, for me, was the biggest departure from my previous programming experience. It forced me to re-examine more of the things that I thought I knew about organizing my thoughts into a program. And while I don't feel that I ever really got good at Haskell, I feel that my time learning Go and Rust has been so much more valuable for having learned Haskell first. It's very unlikely that you'll find a job programming Haskell...there are a few, but not many. But I feel confident in saying that learning Haskell will make you a better programmer in whatever language you do end up getting paid to write. That said, if the choice is really between the two, I'd probably say learn Go. 3-4 months into programming Go and you'll probably be quite adept with it. 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. I'm a couple months into Rust and I feel like I'm a least 6 months away from being productive with it.

oever 11y ago
I've programmed only tiny bits in Go and Rust, so I will not comment on those languages. My main programming languages have been C++, Java, JavaScript and XSLT. Going from that background to Haskell is mindblowing. The language is very clean and there is very little mental capacity needed for worrying about errors because many errors that are possible in other languages are ruled out entirely or hard to make in the first place. Currently, I'm writing a website with Yesod. In Yesod, the URLs on the site are grouped in types and database queries are constructed from these checked types. Any change in database scheme will simply give a compile error. Rust also sounds attractive, but I think the web stack is not as nice as Yesod yet.
commentzorro 11y ago
> 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.

by curun1r 11y ago

oever 11y ago

I've programmed only tiny bits in Go and Rust, so I will not comment on those languages. My main programming languages have been C++, Java, JavaScript and XSLT. Going from that background to Haskell is mindblowing. The language is very clean and there is very little mental capacity needed for worrying about errors because many errors that are possible in other languages are ruled out entirely or hard to make in the first place. Currently, I'm writing a website with Yesod. In Yesod, the URLs on the site are grouped in types and database queries are constructed from these checked types. Any change in database scheme will simply give a compile error. Rust also sounds attractive, but I think the web stack is not as nice as Yesod yet.

commentzorro 11y ago

> 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.