Hacker News Reader

Comment by skrtskrt | Hacker News Reader

I like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

View on HN

There's this common belief that "rust is too hard", which used to be actually true, but the docs and the language itself came a long way since those times.

I'd say: If you can code in C#/TS (or anything like) + go, then it only depends if you have a free weekend.

Rust has quite a few concepts you won't find in (some of) those languages like borrowing, lifetimes, traits, monomorphization, macros, type semantics around concurrency, (partial) expression based syntax, pattern matching and match guards...

However you can litter your code with unwrap and clone to reach the finish line quickly, but then you lose the two main value props of the language and likely lose performance and runtime consistency over other languages.

New concepts, yes, but I think anyone who has spent any significant time programming in C++ will immediately recognize the problems that they are solving and how the solution works. That significantly eases the learning curve in my opinion.

But we weren't talking about those who had spent significant time working in C++.

Indeed I am coming from Python (and some Go), and I'm coming to Rust because I want a language that makes me think about these things. But those who do not want to be bothered are likely to be turned off.

Okay, fair. For myself, I'm coming from extensive experience in both Python and C++, and although I'm admittedly still in the honeymoon phase, my assessment so far is that Rust is an excellent union of the two.

Basically I get the high level abstractions and package management that I expect from Python, while inheriting a set of tools that help finally realize some of the high performance, zero-copy idealism of C++ (slices, lifetimes).

C++ programmers are used to think in terms of object lifetimes, were they should be allocated, and how to signal ownership and object consumption over the API.

That's why is better to learn Rust coming from a C++ background.

(And in my experience this mental model can also be of value even in languages were memory management is handled by the language runtime)

It really depends on what you are going to do with Rust. Sometimes it can be really tricky, but for simple tasks where we used to use scripting languages Rust can be similarly simple.

I mean the biggest change for most people with rust is really the borrow checker or aka the lack of a (automatic) garbage collector. I think it takes much longer to get used to it if one hasn't worked with say C or C++ before.

I'm taking my second crack at learning Rust and I have to say I've made a lot more progress this second attempt. It could be just giving things time to stew in my head, but I really think it's because I'm using rust-analyzer with vscode and before I was using RLS. Rust-analyzer is a much richer experience and its informative error messages and suggestions lessens the learning-curve drastically.

I am having the exact same experience.

I think one think that could seriously be improved is high-quality explanations of Rc, RefCell, etc, and where and why they are used.

I have found myself piecing together explanations from various books, Reddit threads, etc just to try to wrap around these.

In my experience a combination of the rust book followed by the too many linked lists book was enough to give a pretty good idea of Rc, RefCell etc and how they can be used.

With Rust, sometimes I'm just breezing along wondering why people say Rust is hard. Then I try to deserialize some JSON into a type that borrows a reference...

Also, Rust struck me as quite a lot more challenging before non-lexical lifetimes and rust-analyzer, so it's possible that you're responding to outdated criticism.

Reply on news.ycombinator.com