5 ms·

> 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 Th

> 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.

2h 4y ago
> its salt their salt
jeremychone 4y ago
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.
- imron 4y ago
  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.
ReflectedImage 4y ago
I'm not so sure that C++ gives an advantage. It's a different paradigm.
- imron 4y ago
  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.
  - ReflectedImage 4y ago
    Rust imposes a lot more constraints than just what is needed to make it safe. It imposes constraints to make it provably safe according to Rust's internal theorem prover. I'm not convinced Rust & C++ have as much in common as you think. Rust is really familar to OCaml or Haskell users.
    - kaba0 4y ago
      Rust is literally C++’s RAII made into a compiler-checked concept.
sshine 4y ago
I know the basics. 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.
- kaba0 4y ago
  > 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.
Thaxll 4y ago
I don't see how understanding pointers and memory layout help at all with borrowing concepts.
- aparsons 4y ago
  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).
- voidhorse 4y ago
  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.
- matthews2 4y ago
  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.
vsnf 4y ago
> 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.
- josephg 4y ago
  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!
  - zonotope 4y ago
    > About understanding how to control computers (which are fast electronic machines) Computer Systems Engineering > About inventing programming, from the ground up. (A weird sub-discipline of mathematics and category theory) Computer Science > Learning to make software in order to improves the lives of humans Software Engineering
    - 4y ago
FpUser 4y ago
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 ;)

2h 4y ago

> its salt their salt

jeremychone 4y ago

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.

imron 4y ago
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.

ReflectedImage 4y ago

I'm not so sure that C++ gives an advantage. It's a different paradigm.

imron 4y ago
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.
- ReflectedImage 4y ago
  Rust imposes a lot more constraints than just what is needed to make it safe. It imposes constraints to make it provably safe according to Rust's internal theorem prover. I'm not convinced Rust & C++ have as much in common as you think. Rust is really familar to OCaml or Haskell users.
  - kaba0 4y ago
    Rust is literally C++’s RAII made into a compiler-checked concept.

sshine 4y ago

I know the basics. 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.

kaba0 4y ago
> 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.

Thaxll 4y ago

I don't see how understanding pointers and memory layout help at all with borrowing concepts.

aparsons 4y ago
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).
voidhorse 4y ago
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.
matthews2 4y ago
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.

vsnf 4y ago

> 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.

josephg 4y ago
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!
- zonotope 4y ago
  > About understanding how to control computers (which are fast electronic machines) Computer Systems Engineering > About inventing programming, from the ground up. (A weird sub-discipline of mathematics and category theory) Computer Science > Learning to make software in order to improves the lives of humans Software Engineering
  - 4y ago

FpUser 4y ago

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 ;)