C++ knowledge should make it easy to understand Rust. In a lot of ways, the Rust compiler is just enforcing all the stuff you need to do in C++ anyways in order to avoid undefined behaviour.

I think The Book is fine, that's what I used to learn. You can also learn quite a bit by just reading the standard library documentation, which is very nicely structured.

Do you have any sort of synthesis of the core ideas or principles or best practices that work for you?

I think it's hard to give some sort of master theorem because it really comes down to what you are doing.

That said, start by considering ownership. As you start, avoid creating types with non-static references inside of them i.e. keep to types that own their contents. Types with references requires you to use lifetimes and you'll be better off getting used to that later. And frankly, it's often not necessary. The vast majority of the types you'll ever make will fully own their contents.

Now when you make functions or methods, think of the three options you can use when taking parameters:

1. Take ownership, i.e. MyType or self for methods. Use this if your function needs to own the data, often because it needs to take that data and put it into another value or otherwise consume it. Honestly this is the least common option! It's quite rare that you need to consume data and not let it be available to anyone else after the function call.
2. Take a shared reference i.e. &MyType or &self for methods. Use this is your function only needs read access to the data. This is probably the most common case. For instance, say you need to parse some text into some structured type; you'd use &str because you just need to read the text, not modify it.
3. Take a unique reference, i.e. &mut MyType or &mut self. You'll need this if you want to refer to some data that is owned elsewhere but that you need temporary exclusive (unique) access to, so that you can modify it. This is often used in methods to be able to modify private fields of self for example. You need to think about the fact that no one else can have a reference to the data at the same time though. Often this is not a problem, but sometimes you need to be able to mutate stuff from multiple different places. For that, you can consider either passing ownership around, for instance via channels and sending messages or you could reach for Arc<Mutex<T>> to allow mutation through shared references with a tiny bit of runtime performance cost.

When you think in terms of ownership, the borrow checker becomes easy to understand. All it's doing is checking who owns what and who is borrowing what owned data from who and are they giving it back when they said they would?

I hope that helps but again, it's a very general question. If you give me a concrete case I could also give more concrete advice.

PS: Abso-fucking-lutely just clone and don't feel bad about it. Cloning is fine if you're not doing it in a hot loop or something. It's not a big deal. The only thing you need to consider is whether cloning is correct - i.e. is it okay for the original and the clone to diverge in the future and not be equal any more? Is it okay for there to be two of this value? If yes, then it's fine.

Is it possible to become as productive with rust as one is with higher level languages?

Definitely. Rust can be very high level, just as or at least very close to the level of languages like Python. Just as high level as Go or Java I would say.

Rust is quite a wide language, in the sense that it is able to do both low-level and high-level programming. More generally, I'd say the distinction between "high level" and "low level" is just a matter of how much abstraction you use and you can build very powerful abstractions in Rust, and people have done this in many crates.

For instance while using the axum web server framework, you might see code similar to this:

async fn new(db: State<PgPool>, value: Json<MyType>) -> StatusCode {
    ...
}

This function defines a HTTP endpoint that takes a JSON body that deserializes to MyType and internally accesses a PostgreSQL database (for example to save the value in the database) and returns an empty body with a given status code. This is a very "dense" definition in the sense that a lot of semantics is pressed into so few lines of code. This is all possible due to the abstractions built by the axum web framework, and you see similar things in many other crates.

I was kinda hoping to make rust be my go to language for general purpose stuff.

It is a great language for all kinds of stuff - I use it as my general purpose language all the time :)

I would encourage you to stick to it and see how the language feels once you try it a bit more in a real project, and not just in exercises. The book can be a little dry because it has to explain both the high level and low level features of Rust.

If you have more specific questions about what exactly makes it awkward, maybe I can provide more guidance.

I’ve been wanting to write rust for quite some time, but I can’t get over crates. The system just seems insecure to me.

You're not the only one with this concern but it is essentially how modern package management works, not just for Rust but all modern programming languages.

What happens in 10 years when the servers go down?

While I don't think that would happen, there are ways to avoid this. You can host your own registry and mirror the crates.io crates, if you want.

Is there any sort of mitigation for supply chain attacks?

Whenever you have dependencies, you obviously need to either trust them or vet them. If the package is popular enough and the author is reliable enough, then you can choose to trust it. It really depends on what kind of risk you're willing to take on.

As I understand it anyone can submit code; what’s stopping someone from putting malicious code into a crate I’ve been using?

In principal nothing. Again, if you have dependencies, you need to vet them. This isn't really a Rust problem, it's just a general problem with depending on other people's code. You would still have this problem even if you manually downloaded external pieces of code from other people instead of via cargo.

In practice, there is a team managing crates.io and I believe they do look for malware or malicious crates (like crates with names very similar to popular crates that attempt to trick people into downloading due to a typo in the name).

But yes, this isn't really a problem with Rust specifically. I will say that the popular crates in the Rust ecosystem are generally very high quality and I have a fair bit of trust for them myself. Unless you are a big company that needs to carefully vet your dependencies, I wouldn't worry too much.

I’m mainly interested in using Rust as my go to back end language for HTTP/TCP servers and developing JSON and HTML APIs. Can you tell me which frameworks and crates/packages would be good for me to be aware of?

Look into axum. It's built on top of tower and tower-http, which is a general server/client framework. Axum makes it super easy to make HTTP servers, using either raw HTML or JSON. It has in-built functionality for JSON and if you want to do HTML you can reach for stuff like maud or askama.

There's lot of crates around axum as well. You can try searching lib.rs which is a bit more nicely categorized than crates.io. For logging for example, look into tracing.

I’m also interested in creating some CLI and TUI applications, so any frameworks/crates/packages I should be aware of in that realm you might recommend would also be greatly appreciated!

For command-line arguments, use the derive functionality from clap. It lets you declare the arguments you want/need as a type and produces all the argument parsing logic for you.

For TUI, I haven't tried it myself but I've heard that ratatui is good.

I usually get issues with the borrow checker as soon as I move things around.

Once you get familiar with thinking in terms of the borrow checker (i.e. thinking in terms of how data can be safely accessed essentially), you'll be more at ease and you'll start building stuff from the start in ways that anticipate many of the issues you might run into. That's my experience at least.

You "just" need to consider how you structure and access the data in your program. If you've used languages with garbage collectors a lot before, you're not used to thinking like that because the garbage collector just accepts whatever structure you give it and says "well I guess I'll have to make it work somehow, someway (with a lot of effort)".

You'll find that once you structure your program in a way that the Rust compiler likes, it also becomes a lot easier to reason about it in general. A garbage collector won't "force" you to structure your program well in this way, which is why that kind of memory management often becomes messy when it scales to more than a few thousand lines of code.

Just having the right editor setup and such can also help a lot for productivity.

it’s complicated to get the lifetimes correct too

Lifetimes is an advanced topic that you mostly don't need when you're starting out. It can often be avoided by sacrificing some small performance, for instance by cloning data. But lifetimes are also a very cool feature, it just takes a bit to understand it well. Once you get it, it's not so bad though.

If you have any more specific questions about what you were trying to build or what errors you ran into, feel free to ask :)