• arendjr@programming.dev
      link
      fedilink
      arrow-up
      30
      arrow-down
      1
      ·
      3 days ago

      I would argue that because C is so hard to program in, even the claim to machine efficiency is arguable. Yes, if you have infinite time for implementation, then C is among the most efficient, but then the same applies to C++, Rust and Zig too, because with infinite time any artificial hurdle can be cleared by the programmer.

      In practice however, programmers have limited time. That means they need to use the tools of the language to save themselves time. Languages with higher levels of abstraction make it easier, not harder, to reach high performance, assuming the abstractions don’t provide too much overhead. C++, Rust and Zig all apply in this domain.

      An example is the situation where you need a hash map or B-Tree map to implement efficient lookups. The languages with higher abstraction give you reusable, high performance options. The C programmer will need to either roll his own, which may not be an option if time Is limited, or choose a lower-performance alternative.

        • witx@lemmy.sdf.org
          link
          fedilink
          arrow-up
          2
          ·
          1 day ago

          And how testable is that solution? Sure macros are helpful but testing and debugging them is a mess

          • RheumatoidArthritis@mander.xyz
            link
            fedilink
            arrow-up
            1
            ·
            10 hours ago

            You mean whether the library itself is testable? I have no idea, I didn’t write it, it’s stable and out there for years.

            Whether the program is testable? Why wouldn’t it be. I could debug it just fine. Of course it’s not as easy as Go or Python but let’s not pretend it’s some arcane dark art

            • witx@lemmy.sdf.org
              link
              fedilink
              arrow-up
              1
              ·
              9 hours ago

              Yes I mean mocking, faking, et. al. Not this particular library but macros in general

        • arendjr@programming.dev
          link
          fedilink
          arrow-up
          5
          ·
          3 days ago

          I’m not saying you can’t, but it’s a lot more work to use such solutions, to say nothing about their quality compared to std solutions in other languages.

          And it’s also just one example. If we bring multi-threading into it, we’re opening another can of worms where C doesn’t particularly shine.

          • KRAW@linux.community
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 days ago

            Not sure I understand your comment on multithreading. pthreads are not very hard to use, and you have stuff like OpenMP if you want some abstraction. What about C is not ideal for multithreading?

            • arendjr@programming.dev
              link
              fedilink
              arrow-up
              5
              ·
              3 days ago

              It’s that the compiler doesn’t help you with preventing race conditions. This makes some problems so hard to solve in C that C programmers simply stay away from attempting it, because they fear the complexity involved.

              It’s a variation of the same theme: Maybe a C programmer could do it too, given infinite time and skill. But in practice it’s often not feasible.