The amount of people on the internet seriously complaining that both Rust error handling sucks and that .unwrap(); is too verbose is just staggering.

I’ll be honest, when I was learning to program in Java I mostly just wrapped errors in an empty try catch to shut them up, with no regard for actually handling them.

I assume most other learners do that too.

Call me a weirdo but the more errors a compilers give me the happier (albeit a bit frustrated) I am.
That stuff generally surfaces in a way or another… and I prefer at compile time

That said I haven’t spent quality time with Rust yet… so not sure if there are a lot of nitpicks (ala go) or these are valgrind-level of “holy s*** I am so grateful to this tool”

You mean mutex? Arc allows synchronous read only access by multiple threads, so it's not a performance bottleneck. Locking a mutex would be one.

The borrow checker makes things a bit more complicated to get running, definitely takes some getting used to when you come from a non-memory safe language. But the compiler is really helpful throughout almost all mistakes, often directly providing an explanation and a suggested fix. One of my favorites programming experiences so far

The old school method of learning a programming language, database, framework or whatever was to read books and take classes, do a series of exercises that teach you how to use the features, and the errors you get if you don't do it right. Then you write code that way for like 10-15 years.

The Information Age method is to find some sample code, copypaste into an editor and hit Compile, then paste compile errors into google and fix them until there are no more. Then hit Run and copypaste/fix runtime errors until there are no more runtime errors. Old-schoolers used to call this hacking, but now it's called not having time to deeply learn the hot new thing because before you do you'll have to start over with the next hot new thing.

The thing with OOP, particularly how it's used in GCed languages, is that it's all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it's modified in asynchronous code.

Rust has quite the opposite mindset. It's all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don't need them.

OOP also has object ownership hierarchy structures. Which object owns which other object, is a question always worth answering.

...definitely takes some getting used to when you come from a non-memory safe language...

I actually think it's more like the opposite. The compiler takes the normal rules you apply to avoid issues with a non-memory safe language like C/C++ and enforces them explicitly where memory safe languages don't have those rules at all. I think lifetimes are much more confusing if you've never dealt with a user after free and usually let GC deal with it.

Also yes the compiler warnings and errors are amazing, the difference between rustc and gcc is night and day.

Arc is not free, and the extra atomic operations + heap allocations can become a bottleneck.

Oh, I did not know that. Well, it makes sense that it has a heap allocation, as it becomes more or less global. Though not sure why the atomic operations are needed when the value inside is immutable.

Hmm, not sure, if I've heard of it. I'm guessing, we're not talking about simply drawing a UML class diagram...? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?

The old school method of learning a programming language, database, framework or whatever was to read books and take classes, do a series of exercises that teach you how to use the features, and the errors you get if you don't do it right. Then you write code that way for like 10-15 years.

The Information Age method is to find some sample code, copypaste into an editor and hit Compile, then paste compile errors into google and fix them until there are no more. Then hit Run and copypaste/fix runtime errors until there are no more runtime errors. Old-schoolers used to call this hacking, but now it's called not having time to deeply learn the hot new thing because before you do you'll have to start over with the next hot new thing.

Yes, pretty much like UML diagrams. Who is responsible for allocating memory and freeing it.

Languages like Swift, Objective-C, C++ have features that mean you don’t need to do this by hand. But you have to tell the compiler if you want to keep and object around and who owns it.

See this article on Objective-C to see the different ways to manage memory this language supports.

Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn't needed, to Rust where well-defined ownership is enforced by the language.

So, I wasn't aware that ownership is even as concrete of a thing in other languages...

Oh you need this in garbage collected languages too, once you run into memory use issues. GC languages are notorious for being wasteful with memory, even when working correctly.

Not if you never get your application into production...

I wish this was as much of a joke as I'm pretending. It's so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.

For most of the development lifecycle of a GCed project, you're gonna ignore memory usage. And if you're lucky, it can be 'solved' by just plonking down a thiccer piece of hardware...

The amount of people on the internet seriously complaining that both Rust error handling sucks and that .unwrap(); is too verbose is just staggering.