6 ms·

Thought that ThePrimeTime in his video https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 hit the nai

Thought that ThePrimeTime in his video https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 hit the nail on the head re: Rust versus C. Max level C programmers, have designed their programming style around control down to the absolute bit. C derives control from absolute control over behavior. Max level Rust programmers have complete mastery of types. Rust derives control from types. Seems somewhat philosophically incompatible.

01HNNWZ0MV43FF 2y ago
IDK, I thought well-written c and c++ had the same notions of ownership and lifetimes, just not enforced by the compiler
- bsder 2y ago
  C and C++ are very different. I think Casey Muratori hits the nail on the head here: https://youtu.be/xt1KNDmOYqA https://youtu.be/xt1KNDmOYqA In short, RAII and smart pointers and borrow checker are all signs of "individual element thinking" and that way lies madness. You smear out lifetime and ownership so badly that it practically by definition becomes a problem. Your goal is to think about this stuff in groups to make thinking about allocation way, way easier. Programming is all about abstracting to the next layer. I'm not sure he has quite gotten to the heart of the issue, yet. However, a bunch of smart people (Casey Muratori, Jonathan Blow, Andrew Kelley, etc.) are all dancing around something that Rust and C++ don't seem to fit the bill on. Hopefully they can crystallize it out so that everybody can see it.
  - dboreham 2y ago
    Oh interesting. I was expecting to see nonsense in that video (probably triggered by the first line -- C and C++ are basically the same thing, in that you can, and folks did forever, implement all the C++ fancy stuff in C -- just because something isn't in the core language, doesn't mean it wasn't done). But actually it's suggesting how I've been wanting memory to be managed for a couple decades (and have achieved long ago in C projects). Basically some sort of "domain-orientated arena allocator". A simple example is in a network server -- you receive a request from a client, do a bunch of stuff to service that request, and now you're done. Please blow away the memory used to service the request, thanks, all at once. Of course it's not quite that simple because there will be some "chaff" objects thrown off in processing the request that we need to keep around for a while later (e.g. for logging to drain). I suppose the reference to Jonathan Blow should have been a clue that this would be something worthwhile.
    - bsder 2y ago
      > C and C++ are basically the same thing I disagree here. For example, try writing something that does reference counting in C vs C++. In C++, it's practically trivial. In C, it's a nightmare of bugs. RAII support being directly in the language is huge in this case.
    - saagarjha 2y ago
      Casey writes games. Of course to him everything ought to be an arena allocator. This is not actually the best way to write all software.
      - bsder 2y ago
        That's a bit glib. Games almost always have significant networking component nowadays. And Andrew Kelley writes compilers. And arenas still appear to be superior. Games and compilers seem to do better with custom allocators. Embedded almost always static allocates. GPU workloads generally don't have "heap-like" allocations either. We have an increasing amount of evidence that "malloc-like" or "heap-like" allocations on an individual level seem to be a net negative. My gut feel, as someone with a grey beard, is that we're looking at a breakpoint like we did with garbage collection. Garbage collection absolutely suuuuucks until you get big enough memory that you can overallocate by about a factor of 2 at which point garbage collection flies. I think we're at a similar point in "systems programming". It's now okay to overallocate, overcopy, and especially overcalculate things due to current CPU architectures. Chasing pointers is now mega-bad so vtables and the like are becoming a performance bottleneck.
        kazinator 2y ago
        Embedded almost always static allocates is outdated, like integer is almost always faster than floating point. Some embedded nowadays has hundreds of megs of RAM, with its application using mmap, out of an overcommitted virtual memory.
        bsder 2y ago
  - steveklabnik 2y ago
    Rust can do these things. It is maybe true that culturally many Rust programmers do not. There’s both good and bad reasons for this.
    - whiterknight 2y ago
      The point is that many of the problems rust aims to solve become much less relevant. For example, if your program only does 10 Malloc and frees, you can probably track down the memory bugs.
      - steveklabnik 2y ago
        I agree that these techniques help you write better code, but enforcing something is better than not. Obviously it’s a spectrum, so I wouldn’t say doing that is bad, but it does not really mean Rust is irrelevant. And Rust brings more to the table than just the borrow checker.
        whiterknight 2y ago
        Sure, it just invalidates the impending doom, ban C programming narrative.
        steveklabnik 2y ago
        I’m not sure I would characterize it this way, but it doesn’t satisfy the criteria of “memory safety by default,” which is what more and more organizations are desiring. Time will tell.
  - hgs3 2y ago
    > RAII and smart pointers and borrow checker are all signs of "individual element thinking" I'd call it object-oriented thinking. To me Rust and modern C++ are attempting to "OO-ify" systems programming and I think you get push back from folks who view their resources more holistically.
    - FridgeSeal 2y ago
      I wouldn’t really describe a lot of Rist codebases I’ve seen as “OO-ify’d”. I’d say it’s got a more functional flavour if anything. In my experience “de-programming” OOP-programmers is one of the first things teams I’ve been have had to do so that said OOP devs have a better time and write more idiomatic code.
  - noobermin 2y ago
    I took my time to watch part of this. I don't entirely agree, however. I'm not really a large systems programmer (I'm a scientist, actually). I really do like the group oriented thinking, but it does seem like there is space for "individual element thinking" at times. This sounds a lot like the philosophical notions of reductionist thinking vs. holistic thinking which is something I think about a lot when it comes to science and physics in general. The way of thinking I've come to value most at this point in my life for understanding the world that might sound a bit silly applied to this is a synthesis (so called hegelian dielectic), which is this case for me means that reductionist thinking and holistic thinking are not really opposites but are simply modes of mental modeling, and can be apply in different ways and different times to your code. Sometimes, it is valuable to have simple, self-contained types which is reductionist or individual element thinking. However, nests of pointers are always much more complicated and unnecessary than programming at the system level for a group of related objects. Which you use depends on the context, and I don't really like identifying them as opposing forces more than different modes that can be drawn from at different times. That said, most of the time, I find myself utilizing group oriented thinking in my codes and I avoid atomistic, reductionist thinking whenever analyzing a problem at a first pass, but reductionist reasoning does help at times, it just depends on the problem and the context. It is also true, unfortunately, that in science teaching at least we teach students to be reductionist first, and then that reductionist thinking clouds their understanding and it is something young scientists need to break out of at some point, and some never do break out of it. May be in that way it's similar to what this person refers to here (n vs n+1) I just didn't also get stuck thinking reductionism is always bad and avoided it as a rule but I draw from both sides, so to speak.
- AlotOfReading 2y ago
  No, C++ and especially C have much looser notions around ownership and lifetimes. They still require the basic idea of temporaral safety at all times, but differ greatly in how that's achieved in practice. For example, you'd typically share an Arc<RwLock<T>> between threads in rust, even if it doesn't strictly need them for whatever reason. I can't say I've ever seen someone manually implement Arc in C, and RwLock might be ensured half a dozen ways spanning the entire gamut from no protection for things like file handles all the way up to full mutexes.
  - saagarjha 2y ago
    There are dozens of Arc implementations in the kernel. Atomic reference counting is an important way to manage lifetimes and is used extensively in things like making sure that shared resources (files, pages, …) are managed correctly.
  - asveikau 2y ago
    The rust notion of lifetimes is one of the most c++ things I've ever seen. I've always assumed it grew out of the same culture that produced c++ smart pointers and RAII. > I can't say I've ever seen someone manually implement Arc in C In C++, shared_ptr in the standard. But this was common even before the c++11 standard introduced that. I've rolled my own before, more than once. Microsoft ATL had CComPtr. It wasn't surprising to me either that rust came from Mozilla, which made heavy use of COM, an object model that is very heavily based on reference counting.
    - AlotOfReading 2y ago
      I might not have made it clear enough, but I was speaking specifically about plain ol C rather than dialects like kernel C or other languages like C++. Anyway, what do you prefer to lifetimes? They go back to at least the 60s with lisps and algol and possibly earlier. I wouldn't be surprised to find that idea predates electromechanical computers entirely.
      - asveikau 2y ago
samsartor 2y ago
It is a good video, but I'm not at all convinced that a philosophical "authoritarian" vs "anarchy" difference between Rust and C actually exists. C programmers work through all sorts of constraints and rules on how to correctly use a system, same as anyone else. Heck, there are hundreds of pages of kernel documentation explaining how developers are expected to use the various locking subsystems. Does that make C authoritarian? I don't think so... that's just a fact of programming. The details matter. IMO the only real cultural difference in Rust is that you are expected to explain those constraints through the language of the type system, not just in English. That's a lot of work up front but it also gives you way more automation down the line (eg checking that you used a mutex correctly via rustc rather than through emails to Linus Torvalds). Some people definitely take it too far, and blow up their code with endless incomprehensible traits. But the islands aren't incompatible, it just takes work and skill to bridge them.
- geodel 2y ago
  > Does that make C authoritarian? ... Well, he called Rust authoritarian and C anarchy. As with all analogies if I don't stretch too far it does make lot of sense to me.
  - samsartor 2y ago
    Sure! I'm just disagreeing that "C is anarchy because anyone at any point can do anything". You can't do anything, Linus will eventually yell at you in an email. To me, the only philosophical difference is that Rust wants to automate Linus
    - bmicraft 2y ago
      That would also explain why Linus is on board with it, A thousand rust compiler instances is way more efficient than one Linus instance yelling at people, plus eventually he won't be there anymore.
raggi 2y ago
This is less true in "how the language works", and more true in "code I have read in these languages follow these patterns". The latter I agree with, the prior less so. Rust is more type heavy sure, but there are plenty of type shenanigans in rich enough C ecosystems, the kernel has plenty of vtable structures which have varying level of richness and type complexity in their own C expression. Ever worked with the addr types in the BSD sockets API - super messy types that can be a real pain for FFI for example, heavier typing exists in C - not "higher order" and so on, and yes you _can_ do that in rust, but do you want to debug it in kernel use cases, maybe not. Rust kernel code may look different in the end from a lot of other Rust code in a similar way to some C code in the kernel being quite different from other C code elsewhere.
asveikau 2y ago
Good C code will select a rigid set of patterns, carefully chosen to maximize safety, and stick to them. It makes a lot of the bug prone patterns stand out. This is somewhat like what a higher level compiler can produce, but more manual. It's reliance on code smell instead of a type checker.
pjmlp 2y ago
"C derives control from absolute control over behavior." Many C devs like to think C is like Assembly, then they discover it is an high level systems programming language like every other.

01HNNWZ0MV43FF 2y ago

IDK, I thought well-written c and c++ had the same notions of ownership and lifetimes, just not enforced by the compiler

bsder 2y ago
C and C++ are very different. I think Casey Muratori hits the nail on the head here: https://youtu.be/xt1KNDmOYqA https://youtu.be/xt1KNDmOYqA In short, RAII and smart pointers and borrow checker are all signs of "individual element thinking" and that way lies madness. You smear out lifetime and ownership so badly that it practically by definition becomes a problem. Your goal is to think about this stuff in groups to make thinking about allocation way, way easier. Programming is all about abstracting to the next layer. I'm not sure he has quite gotten to the heart of the issue, yet. However, a bunch of smart people (Casey Muratori, Jonathan Blow, Andrew Kelley, etc.) are all dancing around something that Rust and C++ don't seem to fit the bill on. Hopefully they can crystallize it out so that everybody can see it.
- dboreham 2y ago
  Oh interesting. I was expecting to see nonsense in that video (probably triggered by the first line -- C and C++ are basically the same thing, in that you can, and folks did forever, implement all the C++ fancy stuff in C -- just because something isn't in the core language, doesn't mean it wasn't done). But actually it's suggesting how I've been wanting memory to be managed for a couple decades (and have achieved long ago in C projects). Basically some sort of "domain-orientated arena allocator". A simple example is in a network server -- you receive a request from a client, do a bunch of stuff to service that request, and now you're done. Please blow away the memory used to service the request, thanks, all at once. Of course it's not quite that simple because there will be some "chaff" objects thrown off in processing the request that we need to keep around for a while later (e.g. for logging to drain). I suppose the reference to Jonathan Blow should have been a clue that this would be something worthwhile.
  - bsder 2y ago
    > C and C++ are basically the same thing I disagree here. For example, try writing something that does reference counting in C vs C++. In C++, it's practically trivial. In C, it's a nightmare of bugs. RAII support being directly in the language is huge in this case.
  - saagarjha 2y ago
    Casey writes games. Of course to him everything ought to be an arena allocator. This is not actually the best way to write all software.
    - bsder 2y ago
      That's a bit glib. Games almost always have significant networking component nowadays. And Andrew Kelley writes compilers. And arenas still appear to be superior. Games and compilers seem to do better with custom allocators. Embedded almost always static allocates. GPU workloads generally don't have "heap-like" allocations either. We have an increasing amount of evidence that "malloc-like" or "heap-like" allocations on an individual level seem to be a net negative. My gut feel, as someone with a grey beard, is that we're looking at a breakpoint like we did with garbage collection. Garbage collection absolutely suuuuucks until you get big enough memory that you can overallocate by about a factor of 2 at which point garbage collection flies. I think we're at a similar point in "systems programming". It's now okay to overallocate, overcopy, and especially overcalculate things due to current CPU architectures. Chasing pointers is now mega-bad so vtables and the like are becoming a performance bottleneck.
      - kazinator 2y ago
        Embedded almost always static allocates is outdated, like integer is almost always faster than floating point. Some embedded nowadays has hundreds of megs of RAM, with its application using mmap, out of an overcommitted virtual memory.
        bsder 2y ago
- steveklabnik 2y ago
  Rust can do these things. It is maybe true that culturally many Rust programmers do not. There’s both good and bad reasons for this.
  - whiterknight 2y ago
    The point is that many of the problems rust aims to solve become much less relevant. For example, if your program only does 10 Malloc and frees, you can probably track down the memory bugs.
    - steveklabnik 2y ago
      I agree that these techniques help you write better code, but enforcing something is better than not. Obviously it’s a spectrum, so I wouldn’t say doing that is bad, but it does not really mean Rust is irrelevant. And Rust brings more to the table than just the borrow checker.
      - whiterknight 2y ago
        Sure, it just invalidates the impending doom, ban C programming narrative.
        steveklabnik 2y ago
        I’m not sure I would characterize it this way, but it doesn’t satisfy the criteria of “memory safety by default,” which is what more and more organizations are desiring. Time will tell.
- hgs3 2y ago
  > RAII and smart pointers and borrow checker are all signs of "individual element thinking" I'd call it object-oriented thinking. To me Rust and modern C++ are attempting to "OO-ify" systems programming and I think you get push back from folks who view their resources more holistically.
  - FridgeSeal 2y ago
    I wouldn’t really describe a lot of Rist codebases I’ve seen as “OO-ify’d”. I’d say it’s got a more functional flavour if anything. In my experience “de-programming” OOP-programmers is one of the first things teams I’ve been have had to do so that said OOP devs have a better time and write more idiomatic code.
- noobermin 2y ago
  I took my time to watch part of this. I don't entirely agree, however. I'm not really a large systems programmer (I'm a scientist, actually). I really do like the group oriented thinking, but it does seem like there is space for "individual element thinking" at times. This sounds a lot like the philosophical notions of reductionist thinking vs. holistic thinking which is something I think about a lot when it comes to science and physics in general. The way of thinking I've come to value most at this point in my life for understanding the world that might sound a bit silly applied to this is a synthesis (so called hegelian dielectic), which is this case for me means that reductionist thinking and holistic thinking are not really opposites but are simply modes of mental modeling, and can be apply in different ways and different times to your code. Sometimes, it is valuable to have simple, self-contained types which is reductionist or individual element thinking. However, nests of pointers are always much more complicated and unnecessary than programming at the system level for a group of related objects. Which you use depends on the context, and I don't really like identifying them as opposing forces more than different modes that can be drawn from at different times. That said, most of the time, I find myself utilizing group oriented thinking in my codes and I avoid atomistic, reductionist thinking whenever analyzing a problem at a first pass, but reductionist reasoning does help at times, it just depends on the problem and the context. It is also true, unfortunately, that in science teaching at least we teach students to be reductionist first, and then that reductionist thinking clouds their understanding and it is something young scientists need to break out of at some point, and some never do break out of it. May be in that way it's similar to what this person refers to here (n vs n+1) I just didn't also get stuck thinking reductionism is always bad and avoided it as a rule but I draw from both sides, so to speak.
AlotOfReading 2y ago
No, C++ and especially C have much looser notions around ownership and lifetimes. They still require the basic idea of temporaral safety at all times, but differ greatly in how that's achieved in practice. For example, you'd typically share an Arc<RwLock<T>> between threads in rust, even if it doesn't strictly need them for whatever reason. I can't say I've ever seen someone manually implement Arc in C, and RwLock might be ensured half a dozen ways spanning the entire gamut from no protection for things like file handles all the way up to full mutexes.
- saagarjha 2y ago
  There are dozens of Arc implementations in the kernel. Atomic reference counting is an important way to manage lifetimes and is used extensively in things like making sure that shared resources (files, pages, …) are managed correctly.
- asveikau 2y ago
  The rust notion of lifetimes is one of the most c++ things I've ever seen. I've always assumed it grew out of the same culture that produced c++ smart pointers and RAII. > I can't say I've ever seen someone manually implement Arc in C In C++, shared_ptr in the standard. But this was common even before the c++11 standard introduced that. I've rolled my own before, more than once. Microsoft ATL had CComPtr. It wasn't surprising to me either that rust came from Mozilla, which made heavy use of COM, an object model that is very heavily based on reference counting.
  - AlotOfReading 2y ago
    I might not have made it clear enough, but I was speaking specifically about plain ol C rather than dialects like kernel C or other languages like C++. Anyway, what do you prefer to lifetimes? They go back to at least the 60s with lisps and algol and possibly earlier. I wouldn't be surprised to find that idea predates electromechanical computers entirely.
    - asveikau 2y ago

samsartor 2y ago

It is a good video, but I'm not at all convinced that a philosophical "authoritarian" vs "anarchy" difference between Rust and C actually exists. C programmers work through all sorts of constraints and rules on how to correctly use a system, same as anyone else. Heck, there are hundreds of pages of kernel documentation explaining how developers are expected to use the various locking subsystems. Does that make C authoritarian? I don't think so... that's just a fact of programming. The details matter. IMO the only real cultural difference in Rust is that you are expected to explain those constraints through the language of the type system, not just in English. That's a lot of work up front but it also gives you way more automation down the line (eg checking that you used a mutex correctly via rustc rather than through emails to Linus Torvalds). Some people definitely take it too far, and blow up their code with endless incomprehensible traits. But the islands aren't incompatible, it just takes work and skill to bridge them.

geodel 2y ago
> Does that make C authoritarian? ... Well, he called Rust authoritarian and C anarchy. As with all analogies if I don't stretch too far it does make lot of sense to me.
- samsartor 2y ago
  Sure! I'm just disagreeing that "C is anarchy because anyone at any point can do anything". You can't do anything, Linus will eventually yell at you in an email. To me, the only philosophical difference is that Rust wants to automate Linus
  - bmicraft 2y ago
    That would also explain why Linus is on board with it, A thousand rust compiler instances is way more efficient than one Linus instance yelling at people, plus eventually he won't be there anymore.

raggi 2y ago

This is less true in "how the language works", and more true in "code I have read in these languages follow these patterns". The latter I agree with, the prior less so. Rust is more type heavy sure, but there are plenty of type shenanigans in rich enough C ecosystems, the kernel has plenty of vtable structures which have varying level of richness and type complexity in their own C expression. Ever worked with the addr types in the BSD sockets API - super messy types that can be a real pain for FFI for example, heavier typing exists in C - not "higher order" and so on, and yes you _can_ do that in rust, but do you want to debug it in kernel use cases, maybe not. Rust kernel code may look different in the end from a lot of other Rust code in a similar way to some C code in the kernel being quite different from other C code elsewhere.

asveikau 2y ago

Good C code will select a rigid set of patterns, carefully chosen to maximize safety, and stick to them. It makes a lot of the bug prone patterns stand out. This is somewhat like what a higher level compiler can produce, but more manual. It's reliance on code smell instead of a type checker.

pjmlp 2y ago

"C derives control from absolute control over behavior." Many C devs like to think C is like Assembly, then they discover it is an high level systems programming language like every other.