967
Evolution of C (programming.dev)
submitted 2 years ago* (last edited 2 years ago) by to c/programmer_humor@programming.dev
91 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 2 years ago (13 children)

Issue is, Rust is not a drop-in replacement for C. The memory safety features are just one part, and since Rust is also a "weakly" functional language, thus its prefered to write such code with it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] 7 points 2 years ago (7 children)

    Anything that is drop-in replacement for C (or C++ for that matter) is going to be awful because of the same compatibility burden, imo

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 2 points 2 years ago

    D is a mostly drop-in replacement (type renaming and such needed though), and it doesn't have that issue. D even has a mode called BetterC, where the D standard library and the garbage collector is left out.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago (5 children)

    What about Zig?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 2 years ago (3 children)

    Oh boy, Zig is just uglier C++ with memory safety, and it still has those awful header files...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] -1 points 2 years ago (2 children)

    IIRC it's garbage collected, so really it's just a version of Java.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (4 children)

    Yeah, it's not a small change. If there was a simpler way to make C memory-safe, it would have been done decades ago. It's just a different language too, which is fair given how much younger it is.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 years ago* (1 child)

    If there was a simpler way to make C memory-safe, it would have been done decades ago.

    We've had compile time sanitizers (-fsanitize=blah in gcc/clang) and runtime sanitizers (valgrind) for ages. I don't know how they stack up against rust's compile time sanitizers, but it's something.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years ago* (last edited 2 years ago)

    About how an Excel spreadsheet with no formulas stacks up against a corporate accounting suite. Valgrind is how you find the bleeding once you inevitably introduce a memory bug. I don't understand all the fsanitize options, but I'm guessing they aren't a blanket solution, exactly because memory bugs have still been inevitable.

    This thread is making me wonder how many people actually understand what Rust does. It rigorously prevents any form of memory error at all in normal code, and unsafe blocks, where needed, tend to be tiny. It makes C segmentation faults look just as goofy as JavaScript type errors.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago (1 child)

    D kind of did that (C pointers are still an option, alongside with the preferred dynamic arrays, which has the memory safety features), and once I've seen a C compiler fork that retroactively added D-style memory safety features, although they also very much insisted on the "const by default" mantra.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 years ago

    I think this is one of those things where there's no "kind of". Pointers were added for a reason, you're probably not going to implement a database very well without them. If you use them, at some scale you're inevitably going to have memory bugs. Technically, if you were to only use hardcoded printfs, C is memory safe too.

  • permalink
  • fedilink
  • source
  • parent