I think previous experience programming in C++ can be helpful, in picking up Rust faster.

For me, in large part, the borrow checker is encoding in the compiler rules that you should be following in C++ anyway.

A few hours debugging dangling references or iterator invalidation will make you appreciate what the borrow checker is trying to prevent.

You also have experience knowing the difference between pass by reference, pass by const reference, copy, and move.

Also, if you want to keep your sanity, you will learn to take ownership seriously. Deciding what owns what and whether objects will be owned by the scope (on the stack), be owned by unique_ptr, or be shared with shared_ptr is a large part of designing a C++ program.

Again these all map very neatly onto Rust idioms, and as a benefit are enforced by the compiler.

Coming from a garbage collected language where you previously did not have to care about things like that, and now, not only being forced to care, but having the compiler yell at you for every mistake can be a pretty big learning curve.

However, I would say that not knowing C++ doesn't mean that you can't learn Rust, only that it may take a little longer because you have to learn new concepts with regards to memory management and ownership, and so give yourself some slack and do not be discouraged.

> For me, in large part, the borrow checker is encoding in the compiler rules that you should be following in C++ anyway.

My experience was sort of the inverse of yours: I knew a little C++ before learning Rust, and being educated by the borrow checker has really helped me writing C++.

I've seen that too: having experience with Rust made C++ feel easy.

I looked at C++ many years ago but never used it professionally. About 6-7 years ago, I learnt Rust and a few years later, I started working full time in a C++ team at Google. There are many things in the Google C++ Style Guide[1] that reminds me of Rust, from the ban on exceptions to the use of `std::optional` for optional inputs and outputs.

[1]: https://google.github.io/styleguide/cppguide.html

  > Also, if you want to keep your sanity, you will learn to take ownership seriously. Deciding
  > what owns what and whether objects will be owned by the scope (on the stack), be owned by unique_ptr, or
  > be shared with shared_ptr is a large part of designing a C++ program.

I would love if you could expand on this. I've much experience with higher level languages such as Python, but as I get into C++ I find these nuggets of advise invaluable.

I've found this Youtube video (and the whole channel) very good to help understanding Rust:

https://www.youtube.com/watch?v=TJTDTyNdJdY

Agree with the quote: that's the biggest challenge with Rust... I have been trying to pretend Rust is like Java and I think that was my big mistake.

When you design anything in Rust, even the most basic stuff, you will need to decide "what owns what", unless you clone everything on every usage. Try some very simple code that requires allocation and you will quickly notice that. I am now back at Rust and redesigning all my code to make "what owns what" the first question I ask when writing anything, and that is already being very helpful.

But of course: if you don't need the performance of Rust or the small footprint, it's just not worth it spending time on stuff like that can be completely and utterly ignored in any non-systems language.

Thank you.

What I find difficult is to switch my 2 decade C++ career into a rust job, despite learned Rust and finished some hobby projects touching ui, async and http server/client in Rust. Somehow most Rust job is about crypto currency.

I agree with the OP that the best way to learn it is to work through a real project, but I wouldn’t necessarily equate that with “picking it up and just getting stuff done”. At least, that’s not how it went for me, anyway! I hit all the real roadblocks along the way and it took a good few months before I felt actually comfortable. Until then, it felt like I kept running up against mismatches between how I wanted to solve a problem and how Rust wanted me to do it. It was more difficult to build stuff and I had to rewrite things many times. For background, I had worked with C/C++, Java, JS/TS, Ruby, and some others prior to Rust, and it was the first time in a while that learning a new language was pretty hard even after the syntax made sense.

The first time I ever experienced lane assist in a car was in a borrowed Honda Accord. Any time I drifted towards the lane line without signalling, an alarm would go off. This doesn't mean the Accord is hard to drive. It's not even hard to learn to drive. I already knew I was supposed to signal before making a lane change. It just made me concerned about how often I must have drifted over lines in other cars without lane assist. "I'm a great driver. I've driven fine for decades without lane assist. I don't need lane assist." I added lane assist to the list of features I wanted in my next car. You know, for my kid's sake (glances left and right).

I felt a lot like that with Rust.

I find that a lot of people just pick wrong kinds of projects to dig their teeth into Rust with. It is a systems programming language. If you don't know much about it and set out to build a website, things are inevitably going to go south.

One of my first projects involved linked lists. Oh boy was that the right wrong project to start with.

I've never written linked lists the same way in other languages since.

Rust made me better in languages that aren't Rust.

Yeah, that's familiar. I chose for myself a project in which the data structure was a tree that should be generated randomly, but under some constraints. Also I tried to write it using functional paradigms, using many closures. I hit so many walls doing that that when it sort of worked, finally, I never wanted to touch Rust again.

Hah, yes. I thought I'd get started with Rust going through building some basic data structures. Linked lists were near the top of my list so I didn't get very far with that first approach XD

If you really meant this, and you ever want to learn Rust, you could do worse than begin with Aria's "Learn Rust With Entirely Too Many Linked Lists"

https://rust-unofficial.github.io/too-many-lists/

You can skip her explanation of why the Linked List is a bad first data structure, and get straight to doing, but if you have no idea why a very experienced programmer would think this data structure is terrible (so terrible she tried but failed to have it removed from Rust's Standard Library before Rust 1.0) you should read her whole PSA too.

I didn't end my Rust learning with that. I did a bit of a deep dive into articles about linked lists in Rust out of curiosity before pivoting to more fruitful projects. My favourite "project" being last year's Advent of Code.

Actix and Axum are so easy. They're a drop in replacement for Golang or Flask.

I'd encourage people to start their Rust journey with little web services.

Have you tried asking? The Rust reddit was a major reason I stop hitting my head against the wall.

In the past, `&str` was just so huge block for me (now I wonder why!) and instead of getting stuck just ask about it. I think was a stream of a few question on reddit that unblock Rust for me after like 3 months of going nowhere.

Yes, I was on the Rust Discord for a while... without their help I wouldn't have even gone past the most basic things, so yeah, it did help... it was funny to see the huge stream of people asking the same questions over and over again :D.

After a short while, it gets really tiring... but like others are saying, now we have ChatGPT to ask and it never gets tired!

These days you can just ask ChatGPT

Pick up Actix or Axum and clone() and unwrap() all day for your first month. Write some little web servers for fun. Sqlx is great for sql, and you can do some heavy hitting stuff like media streaming and transcoding as you get deeper into it. It's got good torch bindings for ML too.

Before long you'll be running the compiler in your head and rapidly churning out code.

A beginner should use expect instead of unwrap.

It makes you faster because you still don't have to handle errors but allows you to add context.

I suspect this is about experience.

I had experience with PHP, JavaScript, and Python, but when at first coding in Go it would take me as much as 10x as long. But with more practice it's now only about 2x as long as in other languages. Keep practicing ;)

I think my experience is actually the problem. I don't have enough patience anymore to spend lots of time trying to understand errors where I have zero idea why it's complaining, when I know the same thing in another language works totally fine the first time I try (and without bugs, it's mostly lifetime issues or the lovely borrow checker, which don't even exist in other languages). But I do keep trying Rust, because the alternatives as I see it, C and Zig, have their own problems that are bigger (C's build tools and lack of package management, very weak type checking and unavoidable UB, and Zig's overall lack of maturity and consequently tooling).

By the way, I can write code very easily in Java/Kotlin/Groovy/Dart/JS/TS/Go/Lisp.

> I don't have enough patience anymore to spend lots of time trying to understand errors where I have zero idea why it's complaining

I consider those bugs. Please file tickets for that. The errors should provide enough context for an uncaffeinated developer to understand what went wrong.

ChatGPT has really helped me get over the impatience hurdle. I let it do all the tedious stuff like looking up error messages.

Yea, that's a common complaint coming from other safe languages where the safety is accomplished by runtime features (such as garbage collection) instead of compile–time rules.

I think that most programs should be written in easier languages than Rust, since most of the time the engineering cost of creating a system is higher than the cost of running it. You can rewrite it in Rust once your system is large enough that eliminating the garbage collector will save you a few million dollars a year. By then you’ll have a complete understanding of the requirements, and you won’t have to experiment to get it right. Use a language like Lisp, which is designed for easy and fast experimentation, to write the first version of your software.

>most of the time the engineering cost of creating a system is higher than the cost of running it.

And most of the time the cost of _maintaining_ the system is higher than the cost of creating it. This is where Rust truly excels, it makes it much harder to write any hard to find bugs.

Yes, I include maintenance in the cost of running the system. And I agree with you that a well–written Rust program usually has quite low maintenance costs.

In principle you should be able to approach zero maintenance costs with any language, but writing your system in Rust generally means you have abandoned complexities like garbage collection. Garbage collection speeds up development by an order of magnitude or more, but at the cost of having to monitor the performance of the GC, tune it as loads change and computers get more and more memory but don’t get any faster at accessing it, etc, etc.

Exceptions are another thing that speeds up development at the cost of maintenance down the road. You have to log the exceptions that are happening and monitor them to make sure that they are rare otherwise they’ll silently become more common over time as your program gets more complex. Meanwhile Rust’s explicit error handling really makes you think at every step about exactly what odd conditions your program might encounter. If you use Rust’s type system correctly, you can encode very specific information about exactly which errors are possible or impossible at every point in your system. It’s more work up front but it saves a huge amount of time down the road.

> You can rewrite it in Rust once your system is large enough that eliminating the garbage collector will save you a few million dollars a year.

Never gonna happen.

Why do you say that? We’ve all read articles from Cloudflare and Microsoft and others about rewriting services in Rust once it becomes obvious how much money they can save, so we know that it does happen. I’ve seen it happen at much smaller companies as well.

It would probably take several years to do a full rewrite of a complicated system, and there'd be subtle differences all over the place.

Then you don’t have good enough documentation or tests, and you probably tried to rewrite too much. You should rewrite that portion of your code where the performance is most critical, because that’s where you will save the most money.

Have you even worked with a big complicated legacy system whose authors have all quit?

Yes. A good example would be Firefox. Mozilla is gradually replacing core components of Firefox with replacements written in Rust. It is not cheap to do this without causing regressions, but they have a great test suite and they know that it will save money in the long run. It increases performance, decreases memory usage, and most importantly it greatly reduces the defect rate. They’ll probably never bother to replace _all_ of the C++ code with Rust, because a lot of it works well or isn’t security–critical. They’ve been doing this since Rust 1.0, with measurable improvements in every release of the last few years.