3 ms·

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

• 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
          I would argue that if you have an MMU, you aren't really "embedded" anymore. An RPi isn't "embedded". However, you may still be doing systems programming.
          • kazinator 2y ago
            Embedded means that something that is not itself computer contains one, running some dedicated control application. If a Raspberry Pi is built into a toaster, where it controls the temperature and toasting duration according to the user-selected selected darkness level, it's embedded. If the toaster has a screen, and you can install and uninstall apps on the Pi, then it doesn't look so embedded any more.
• 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.