I went from writing almost 100% Go to an environment where I write 60/40 Rust/Go.
The worst thing we can have on any HN thread is a debate about the virtues of Rust vs. Go. They are different languages with somewhat different long-term goals and very definitely different short-term goals, and these threads are never interesting in anything but a sort of sporting event spectator way.
I will just say that while there are a lot of things I like more about Rust than about Go, generics in Rust come at a cognitive cost. They're infectious; they don't get used the way people say they need them for Go ("I need to be able to sort arbitrary things and have sets of arbitrary types"); they're as fundamental to Rust as interfaces are to Go. It adds a lot of additional indirection.
Correct. As someone not doing Rust full time I do get tripped up on Rust's pervasive generics. Things like, "should I take a T argument here, or a U: Into<T>, or U: AsRef<T>" etc. Just seems like there's a lot of open world choices in the language which make it hard to get going quickly as a beginner
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.
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.
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)
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.
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'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.
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.
I would say that in the case of Rust, generics are on the list of those "few other bonuses". There are other things in Rust that are more attractive and innovative. Rust is as complex as C++ (which is not a compliment) but saner and safer, without undefined behavior. Though, at the rate they add new features, I can see it becoming rapidly a kitchen sink.
Rust is a reasonably complex language, but—having programmed professionally in both—I don't think it's nearly as complex as C++. Rust features for the most part are orthogonal to each other, whereas C++ features tend to have weird interactions with each other that are really hard to track and understand. (The one place where Rust starts to get messier in terms of feature interactions is async Rust, but luckily you can program Rust just fine while ignoring the async features.)
Consider initialization: C++ has dozens of different ways of initializing objects that in turn interact in complicated ways with move semantics and references and so forth. Rust's initialization story by contrast is straightforward: you just make the thing you want to make using struct or enum literals and maybe wrap those initializers in functions if you want.
I agree I just have to assume people comparing Rust to c++ never really used c++ professionally for any length of time. Rust is incredible simple coming from c++ there is normally only 2 or 3 ways to do something vs 5 + 4 more via templates. It takes longer to learn the symbols for lifetimes then to get a grasp of what you need to do to keep the borrow checker happy.
It's very slow for the initial revision, as it has to compile all its dependencies. From there, if you add in full async/await support with a web server framework, you're looking at ~6sec iteration time. If you bring in LLVM's LLD instead of GNU or MSVC, you can bring that down to ~3-4sec. They're working on adding support for their own LLVM competitor, Cranelift, that should further reduce those times. It's only intended for debug/development builds, though, so you'll still need longer compile times for release.
While the compile times are a bit slower, one of the advantages of the strict type system is you don't need to compile to an executable quite as often.
Most of the time your IDE's messages (or "cargo check" output) is sufficient to find all the things the compiler will complain about.
I usually find that once I've fixed all of those, I compile it once and it just works.
The worst thing we can have on any HN thread is a debate about the virtues of Rust vs. Go. They are different languages with somewhat different long-term goals and very definitely different short-term goals, and these threads are never interesting in anything but a sort of sporting event spectator way.
I will just say that while there are a lot of things I like more about Rust than about Go, generics in Rust come at a cognitive cost. They're infectious; they don't get used the way people say they need them for Go ("I need to be able to sort arbitrary things and have sets of arbitrary types"); they're as fundamental to Rust as interfaces are to Go. It adds a lot of additional indirection.