How many of those advanced concept in Rust such as borrow checker & lifetime could be avoided as a beginner? If utmost performance is not required (i.e., for mortals dealing with Java/Python/JS on a daily basis) would those lifetime and borrow checker concepts be a hinder to move quick?
I read this article https://corrode.dev/blog/prototyping/ and it seems to address almost all of my concerns when I started learning Rust. I think it could take a beginner a long way until they need to get down to the borrow checker/lifetime. I said I agree with the blog "mostly" because there are situations where you have to interact with 3rd party libraries or APIs dealing with those lifetime. The, you need to know about those concept. If you know a better way to handle this, please let me know.
The borrow checker and lifetimes aren't simply a matter of performance, they are a matter of correctness. Languages without them (go, java, etc) allow for bugs that they prevent - dataraces, ConcurrentModificationException, etc. The fact that you can only write through pointers that guarantee they have unique access is what lets the language statically guarantee the absence of a wide category of bugs, and what makes it so easy to reason about rust code as a human (experienced with rust). You can't have that without the borrow checker, and without that you lose what makes rust different (it would still be a fine language, but not a particularly special one).
You could simplify rust slightly by sacrificing performance. For example you could box everything by default (like java) and get rid of `Box` the type as a concept. You could even make everything a reference counted pointer (but only allow mutation when the compiler can guarantee that the reference count is 1). You could ditch the concept of unsized types. Things like that. Rust doesn't strive to be the simplest language that it could be - instead it prefers performance. None of this is really what people complain about with the language though.
I recently came to this realization in a large typescript codebase. It's really important to understand who owns data and who has the right to modify it. Having tools to manage this and make it explicit built into the language is so helpful for code correctness and is especially beneficial for maintaining code you didn't write yourself.
Couldn't the same guarantees be achieved with immutability? Of course this would be setting aside concerns with performance/resource usage, but the parent is describing an environment where these concerns are not primary.
Personally I find it much easier to grok immutable data, not just understand when concentrating on it, then ownership rules.
Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one.
What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take simplicity instead. Most other languages assume (rightly so) you’re too dumb to do it correctly and give you smart pointers by default; some assume you’re smart enough and are proven wrong all the time (this is assembly and C relatives; actually they say ‘we don’t want smart pointers and we want a simple compiler, sucks to be you’).
It very quickly becomes a special Rust-only software engineering problem. Rust has no partial borrows and this affects many designs where a lot of data needs to access fields of other data. Consequently, you see humongous large, flat structures in many Rust projects. And of-course, the famous "replace references with array indices" and just skip the borrow checking and lifetime rules by simply making your own custom pointer system - which is also common in many Rust projects and famously popularized by the "Object Soup is Made of Indices" Rust post here on HN.
No, Rust definitely does add some additional complexity on top of the inherent complexity of ownership. Despite what some people think, Rust's borrowing rules are actually extremely simple. So simple that they reject a lot of safe programs.
Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).
But I know there's extra language design complexity that this introduces, and extra codegen complexity (Rust makes certain aliasing promises to LLVM that it isn't allowed to break) so it will take time. But, there are proposals in the works.
I've tried to wrap up my philosophy on how a significant chunk of rust code can be written without lifetimes using shared and sharedmut primitives.
I've shipped three projects on it and they are pretty much as performant as they can be. I've never regretted skipping the lifetime work in application code.
That article on rapid Rust prototyping matches my experience with using Rust as the backend for a web and iOS app. I used clone() and Vec and String and other shortcuts from that article as much as possible since I was building a backend application versus an operating system. It enabled a lot more velocity and made it fun to add features. And it was still blazing fast.
If anyone is considering using Rust and is nervous about lifetimes and bare metal, check out that article and try its guidance. I learned these things on my own the hard way and would have loved to read this article 18 months ago. It's really quite good.
> How many of those advanced concept in Rust such as borrow checker & lifetime could be avoided as a beginner?
As a beginner, you can avoid references (&) and simply clone() everything when it gives you trouble. If you start off by writing simple Actix/Axum web services instead of manually multithreaded apps, the problem domain is inherently linear and you'll avoid lifetimes and the borrow checker almost entirely. This lets you feel productive while getting a feel for the rest of the language features.
Don't do this once you learn the ropes of the borrow checker, of course. Once you grok it, the borrow checker is almost second nature.
I don’t think the basic usage of references is hard to grok for a beginner. If you aren’t going to mutate data and only access it, then pass a reference. No need for over-complicated semantics when describing it to a new Rust user.
I think you will run into the borrow checker pretty soon, because you have to deal with it whenever you deal with references (which you will inevitably have to do if you are dealing with anything more complex than number types). But that aspect of the borrow checker is not that difficult. You could avoid it entirely by cloning everything but IMO it's not necessary and you would do better to invest a small amount of time in understanding why the borrow checker is complaining.
Lifetimes you can probably get further without having to deal with. Just avoid storing references in structs and you will avoid a lot of lifetime headaches. Cloning can again be helpful here.
An alternative to cloning everything, if you are dealing with simple data types, is to derive copy for your structs so you can pass them around without worrying about ownership. It's not always possible though.
Smart pointers are another workaround, as others have said. But my problem with (some) smart pointers is that they simply move the checks to runtime, meaning now your code has a much higher chance of panicking at runtime.
The places where you'll usually see lifetimes creep in where you may not expect are in closures (say your app is one big struct, you call a library function that takes a callback, you reference &self in the callback and get an error that the arg type must be 'static, or some other bound), or if you're spawning async tasks and using locks you may get weird Send/Sync and lifetime errors around await and spawn points.
They all make sense if you know why the program doesn't compile, but it may be surprising to newbies.
You can skip lifetimes in the beginning, and I think that's the sane thing to do, if you come from a GC languages.
Borrow checker, well, this actually includes lifetimes. But let's say "basic ownership and basic borrowing", there is no way around starting with that, and it should be a point to learning rust.
You can Arc<Mutex<T>> your way out of ownership/borrowing. At some point, you'll start to see your program as just data (and functional programming will make sense as the only way to program) moving around. I think it's an under-rated way to get started (I started that way) and at some point a bulb will light up and you'll start seeing programming as data moving around and you'll care about ownership/borrowing at the foundational/prototype level.
Yup, that’s definitely correct in terms of avoiding most of the complexity. The tips in that blog post can apply to third party libraries, but sometimes the complexity of the lifetime can leak past the API boundary in a way you can’t ignore (but often you can).
... just write Java/Python/JS, then? Or Kotlin, Typescript, Python+type annotations if you're feeling more modern.
There's nothing wrong with any of those languages (mostly) and not everything has to be written in Rust. IMHO the real value of Rust is as a systems programming language that's safer than C.
Wow this is super cool. Is this pretty reliable for more advanced scenarios? Simple ones I wouldn't need to see this on, but the more complex things I'd be very interested in perusing code to make certain things click.
It's too bad the lifetime of rustc is only about 3 months before breaking changes (new features, updates, etc) are introduced to the compiler and used by devs.
New features aren't usually considered breaking changes, only modifying existing ones so that old code doesn't work.
The rust compiler never strives to never introduce breaking changes (by the definition I just described). It doesn't quite succeed (because some things like correctness are considered more important), but it fails
a) Very rarely, not once every 3 months.
b) In very small ways, that only break a tiny portion of code.
c) In ways that are very easy to fix.
d) Usually the rustc-devs will go offer patches to the entire open source ecosystem before any such release.
I imagine that is a dev's perception (in shipping rust binaries to users) with their rolling OS and constantly updated rustc. But as a user trying to compile rust code written by rust devs what happens is that it won't compile because the compiler is 3 months out of date and rust devs immediately use new features. I had this happen personally often enough it put me off even trying out rust written applications. This is not things I've heard. It is things I've directly experienced.
rustc is a rolling only compiler and that's not great and it does break often (not be able to compile code) in distros that are not rolling. And no, curl|sh and/or rustup are not solutions. I think the only solution is waiting for rust to become popular enough that the proportion of bleeding edge using devs to normal devs goes down.
Readit News
I read this article https://corrode.dev/blog/prototyping/ and it seems to address almost all of my concerns when I started learning Rust. I think it could take a beginner a long way until they need to get down to the borrow checker/lifetime. I said I agree with the blog "mostly" because there are situations where you have to interact with 3rd party libraries or APIs dealing with those lifetime. The, you need to know about those concept. If you know a better way to handle this, please let me know.
You could simplify rust slightly by sacrificing performance. For example you could box everything by default (like java) and get rid of `Box` the type as a concept. You could even make everything a reference counted pointer (but only allow mutation when the compiler can guarantee that the reference count is 1). You could ditch the concept of unsized types. Things like that. Rust doesn't strive to be the simplest language that it could be - instead it prefers performance. None of this is really what people complain about with the language though.
Deleted Comment
Personally I find it much easier to grok immutable data, not just understand when concentrating on it, then ownership rules.
What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take simplicity instead. Most other languages assume (rightly so) you’re too dumb to do it correctly and give you smart pointers by default; some assume you’re smart enough and are proven wrong all the time (this is assembly and C relatives; actually they say ‘we don’t want smart pointers and we want a simple compiler, sucks to be you’).
Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).
But I know there's extra language design complexity that this introduces, and extra codegen complexity (Rust makes certain aliasing promises to LLVM that it isn't allowed to break) so it will take time. But, there are proposals in the works.
I've shipped three projects on it and they are pretty much as performant as they can be. I've never regretted skipping the lifetime work in application code.
https://github.com/mmastrac/keepcalm
I still dig into lifetimes for a lot of true low-level code but it doesn't need to exist at all at the high level
If anyone is considering using Rust and is nervous about lifetimes and bare metal, check out that article and try its guidance. I learned these things on my own the hard way and would have loved to read this article 18 months ago. It's really quite good.
As a beginner, you can avoid references (&) and simply clone() everything when it gives you trouble. If you start off by writing simple Actix/Axum web services instead of manually multithreaded apps, the problem domain is inherently linear and you'll avoid lifetimes and the borrow checker almost entirely. This lets you feel productive while getting a feel for the rest of the language features.
Don't do this once you learn the ropes of the borrow checker, of course. Once you grok it, the borrow checker is almost second nature.
Lifetimes you can probably get further without having to deal with. Just avoid storing references in structs and you will avoid a lot of lifetime headaches. Cloning can again be helpful here.
An alternative to cloning everything, if you are dealing with simple data types, is to derive copy for your structs so you can pass them around without worrying about ownership. It's not always possible though.
Smart pointers are another workaround, as others have said. But my problem with (some) smart pointers is that they simply move the checks to runtime, meaning now your code has a much higher chance of panicking at runtime.
They all make sense if you know why the program doesn't compile, but it may be surprising to newbies.
Borrow checker, well, this actually includes lifetimes. But let's say "basic ownership and basic borrowing", there is no way around starting with that, and it should be a point to learning rust.
Deleted Comment
There's nothing wrong with any of those languages (mostly) and not everything has to be written in Rust. IMHO the real value of Rust is as a systems programming language that's safer than C.
https://www.jetbrains.com/help/rust/rust-external-linters.ht...
The rust compiler never strives to never introduce breaking changes (by the definition I just described). It doesn't quite succeed (because some things like correctness are considered more important), but it fails
a) Very rarely, not once every 3 months.
b) In very small ways, that only break a tiny portion of code.
c) In ways that are very easy to fix.
d) Usually the rustc-devs will go offer patches to the entire open source ecosystem before any such release.
rustc is a rolling only compiler and that's not great and it does break often (not be able to compile code) in distros that are not rolling. And no, curl|sh and/or rustup are not solutions. I think the only solution is waiting for rust to become popular enough that the proportion of bleeding edge using devs to normal devs goes down.
Dead Comment