> As said earlier, C++ developers have an advantage on understanding Rust because they have a mental model of what the memory looks like, pointers and so on
The immeasurable success of Rust certainly lies in its clear communication and forcing developers to learn about the basics of hardware.
I can't help but to feel validated in thinking that every developer worth its salt should know about these basics anyway. But I have to admit that not everybody comes with a CS background.
Something doesn't sit quite right with me to describe the "basics of hardware" as being something that comes with a "CS background".
I come from a formal CS background, and we spent more time dealing with finite state automatons, programming language theory, and other aspects of abstract computation. Getting down and dirty with data sizes, system components, and bit fiddling was an available, but optional path. We all spent one or two courses dealing with the practical nature of computers, but it was largely drowned out by theory, at least in my program.
I have a funny relationship with this. I also come from a formal CS background too. The old joke is that there are two lies in Computer Science: firstly its not science, and secondly it isn't really about computers.
But the reality is, I still can't tell you what Computer Science actually is. Is it:
- About understanding how to control computers (which are fast electronic machines)
- About inventing programming, from the ground up. (A weird sub-discipline of mathematics and category theory)
or
- Learning to make software in order to improves the lives of humans
We sort of need to learn all three aspects. Haskell programs run slower than C++ programs because haskell isn't written in harmony with the physical CPU cores we've made. Making fast programs is pointless if our software doesn't solve user needs. And solving user needs are impossible if we can't express ourselves clearly to the computer - which programming language theorists are obsessed with.
I think the basics of hardware is part of CS, but maybe a CS undergraduate degree doesn't give anyone enough time to really go broad in the field. I dunno!
But manually managing memory lifetimes you only learn from a lot of exposure to C/asm.
In my first 3 months of Rust, I spent an equal amount of time with the type-checker and the borrow-checker. A year in and I don’t really have a separate phase of resolving borrow-check errors before I can compile.
People with more C exposure tend to think that way already.
> But manually managing memory lifetimes you only learn from a lot of exposure to C/asm
Why C? It is not any lower than Rust, one might even argue that Rust is lower-level than C due to it having control over SIMD and the like without non-portable compiler extensions.
Agree. The problem is that languages like Java, C#, ... are making it so easy not to worry about memory that we (at least I) tend to forget the basics after a decade or so. And the basics have mostly stayed the same.
You still end up worrying about memory eventually, and the solution will often be to purchase more memory - which can be a fine tradeoff to make at times.
I'd learned "basics of hardware" by programming old CPUs and MCUs in assembly and machine codes. No I did not have CS background. Masters in Physics instead.
Memory management in C was too high level at that time ;)
They don't. They're fairly orthogonal concepts. You can have a concept of lifetimes without memory management (for example, the object changes state while you have a reference to it).
It provides historical context. Someone coming from a gc langage that has never even had to learn what memory even is wrt to a program will not understand why a borrow checker is even a thing.
You can get very far writing software without even being aware that your language is even doing something called garbage collection for you, or without even having a basic concept of memory being tied to values, sizes, etc. If you lack this context a borrow checker just seems like a pointless nuisance.
If you are writing C or C++ and aren't thinking about ownership and lifetimes, you have either statically allocated everything or you are doing it wrong.
If you’re a safe c++ programmer who never writes code that has memory errors, you need to be tracking ownership and lifetimes.
Once you get your head around the borrow checker, Rust takes a lot of that cognitive load off you, by tracking things for you at compile time and dinging you on it if you get something wrong.
Personally, I'd recommend learning C to learn about the basics of memory management in higher level languages in general. It is simpler than Rust and is very transparent, making it easier to grok the concepts before moving on to something like the borrow checker, further more, it will actually make the motivations for the borrow checker and what it does to help clear. Same goes for other memory management solutions, gc, reference counting, etc. So much of what we do is still bound to a deeply entrenched model that C established.
Ultimately we are all still just writing nicer versions of C. The fundamental model of pretty much all high level languages remains the same. You can still explain and think about the vast majority of memory related goings-on in a program as using the basic abstraction of the pointer and contiguous arrays of bytes. Even languages that have different paradigms, be they functional, logical, or object oriented can be described in terms of pointers--one easy way to understand pretty much every other programming language paradigm is basically just to ask "how would I implement this using pointers?". It's a shared history and approach to computing we have yet to move on from.
I started learning some Rust, just begging of this yeae, and I am starting to think learning C might be the shortest path to fully understand the motivation of ownership model.
But at the same time, I don't want to invest so much time into learning a language which I probably am not going to use.
I am probably being disrespectful. I understand a lot of people use C, including Linux kernel devs, but I cannot imagine developing new apps with an old language such as C.
Not wanting to invest time makes sense, but I think you'll definitely get return on investment by learning C. It's doesn't end with rust. Learning C's approach to memory will give you a much better understanding of pretty much all object oriented and imperative languages and give you a better understanding about how memory might be used under the hood in higher level languages in general.
It won't take you too long either! Compared to modern languages, C is very small and very simple and likely won't take as long as learning any other popular language in use today. You can learn all of C in the amount of time it takes most people to learn just the basics of a borrow checker. If you only focus on the aspects related to memory (stack, heap, sizing, arrays, pointers) it would likely only take half a day, if that.
I second this 100%. In the first semester of my CS degree we were only programming in C and it helped so much to understand the basics of memory. Heap, Stack, Pointers are crucial mental models which help you in nearly all programming languages.
If you are responsible for your own memory, it makes you more aware of issues such as indirection and cyclic dependencies.
This is the path I took, and recommend. The borrow checker and Rust's restrictions are easier to understand once you have experienced doing it manually. And the basics of C89 don't take that long to learn!
Today I had a moment with TypeScript where I got an error because a class property wasn’t definitely initialized in the constructor.
I thought, “I wish there was a way to prove to the compiler that it will be there when I access it, rather than having to tell it to trust me.”
And that’s when lifetimes in Rust really clicked for me. I know it’s not exactly the same thing but the value of describing the valid lifetime of a thing at compile time began making a lot more sense.
> As a rule of thumb, if you don’t want the function to consume the data (to free it), don’t ask for ownership.
As a Rust beginner, that's a handy thing to remember! Thinking of variable passing in terms of least privilege seems much better than just trying to use the simplest syntax (changing ownership by passing the variable rather than a pointer to it) all the time.
> Ideally, you don’t want to make a self-referential struct in Rust. Instead you should leverage other types to accomplish the same thing; for example Rc<T> can be used for things like linked-lists or trees. Also, have a look for libraries that might do this work for you, as these are very easy to do wrong.
LOL, sure borrow-checked reference counted pointers that can't equal null to mark the beginning or end of a chain are exactly what I am looking for when I want to build a linked list or tree. Why are you like this, Rust?
Readit News
The immeasurable success of Rust certainly lies in its clear communication and forcing developers to learn about the basics of hardware.
I can't help but to feel validated in thinking that every developer worth its salt should know about these basics anyway. But I have to admit that not everybody comes with a CS background.
Something doesn't sit quite right with me to describe the "basics of hardware" as being something that comes with a "CS background".
I come from a formal CS background, and we spent more time dealing with finite state automatons, programming language theory, and other aspects of abstract computation. Getting down and dirty with data sizes, system components, and bit fiddling was an available, but optional path. We all spent one or two courses dealing with the practical nature of computers, but it was largely drowned out by theory, at least in my program.
But the reality is, I still can't tell you what Computer Science actually is. Is it:
- About understanding how to control computers (which are fast electronic machines)
- About inventing programming, from the ground up. (A weird sub-discipline of mathematics and category theory)
or
- Learning to make software in order to improves the lives of humans
We sort of need to learn all three aspects. Haskell programs run slower than C++ programs because haskell isn't written in harmony with the physical CPU cores we've made. Making fast programs is pointless if our software doesn't solve user needs. And solving user needs are impossible if we can't express ourselves clearly to the computer - which programming language theorists are obsessed with.
I think the basics of hardware is part of CS, but maybe a CS undergraduate degree doesn't give anyone enough time to really go broad in the field. I dunno!
But manually managing memory lifetimes you only learn from a lot of exposure to C/asm.
In my first 3 months of Rust, I spent an equal amount of time with the type-checker and the borrow-checker. A year in and I don’t really have a separate phase of resolving borrow-check errors before I can compile.
People with more C exposure tend to think that way already.
Why C? It is not any lower than Rust, one might even argue that Rust is lower-level than C due to it having control over SIMD and the like without non-portable compiler extensions.
Memory management in C was too high level at that time ;)
You can get very far writing software without even being aware that your language is even doing something called garbage collection for you, or without even having a basic concept of memory being tied to values, sizes, etc. If you lack this context a borrow checker just seems like a pointless nuisance.
Once you get your head around the borrow checker, Rust takes a lot of that cognitive load off you, by tracking things for you at compile time and dinging you on it if you get something wrong.
their salt
Ultimately we are all still just writing nicer versions of C. The fundamental model of pretty much all high level languages remains the same. You can still explain and think about the vast majority of memory related goings-on in a program as using the basic abstraction of the pointer and contiguous arrays of bytes. Even languages that have different paradigms, be they functional, logical, or object oriented can be described in terms of pointers--one easy way to understand pretty much every other programming language paradigm is basically just to ask "how would I implement this using pointers?". It's a shared history and approach to computing we have yet to move on from.
But at the same time, I don't want to invest so much time into learning a language which I probably am not going to use.
I am probably being disrespectful. I understand a lot of people use C, including Linux kernel devs, but I cannot imagine developing new apps with an old language such as C.
It won't take you too long either! Compared to modern languages, C is very small and very simple and likely won't take as long as learning any other popular language in use today. You can learn all of C in the amount of time it takes most people to learn just the basics of a borrow checker. If you only focus on the aspects related to memory (stack, heap, sizing, arrays, pointers) it would likely only take half a day, if that.
If you are responsible for your own memory, it makes you more aware of issues such as indirection and cyclic dependencies.
I thought, “I wish there was a way to prove to the compiler that it will be there when I access it, rather than having to tell it to trust me.”
And that’s when lifetimes in Rust really clicked for me. I know it’s not exactly the same thing but the value of describing the valid lifetime of a thing at compile time began making a lot more sense.
As a Rust beginner, that's a handy thing to remember! Thinking of variable passing in terms of least privilege seems much better than just trying to use the simplest syntax (changing ownership by passing the variable rather than a pointer to it) all the time.
LOL, sure borrow-checked reference counted pointers that can't equal null to mark the beginning or end of a chain are exactly what I am looking for when I want to build a linked list or tree. Why are you like this, Rust?
I understand what the claims advantages of Rust are, but I can't understand those cult-like passions.
Deleted Comment