Login
You're viewing the f.duriansoftware.com public feed.
  • Sep 12, 2026, 5:35 AM

    It’s wonderful that an interpreted[1], dynamically dispatched[2], effect-based[3], language like C can see such broad interest, but tragically its opinionated[4] batteries-included[5] runtime, poor performance[6], and overly high level[7] design make it unsuitable for low level programming.

    1: microcoded instructions
    2: dynamic linking
    3: page fault handler
    4: the stack
    5: malloc
    6: char* aliases everything
    7: reading off the end of a buffer is UB even if it’s still a readable address

    💬 7🔄 43⭐ 83

Replies

  • 💬 0🔄 0⭐ 1
  • 💬 0🔄 2⭐ 2
  • Sep 12, 2026, 7:23 AM

    @Catfish_Man I guess you'd prefer IBM 370 asm, a stackless ISA.

    Strangely, one of the first things I see anyone add to their toolkit is macros to implement a call stack.

    💬 0🔄 1⭐ 2
  • Sep 12, 2026, 7:47 AM

    @Catfish_Man

    1. Rosetta on Mx platforms
    2. Polymorphism only via function pointers
    3. Weak symbols allows runtime overriding of even basic I/O capability
    4. Zero-sized types are illegal
    5. Standard library includes signal handlers?!
    6. Pointers must assume aliases, etc.
    7. VLAs

    💬 1🔄 0⭐ 1
  • 💬 0🔄 0⭐ 0
  • Sep 12, 2026, 12:15 PM

    @Catfish_Man it's a pity because its powerful type system[8] allows encoding consistent safety principles[9] directly into programs at the expression level, ensuring that a program that compiles[a] is a program that will behave according to its specification[b]

    8: void
    9: YOLO
    a: -fpermissive
    b: UB

    💬 0🔄 6⭐ 12
  • Sep 12, 2026, 4:04 PM

    @catfish_man On microcode, my understanding is that ARM microarchitectures, including those for the AArch64 ISA, still don't rely on microcode for the majority of common instructions, though some of them might for a handful of instructions. I buy that the other points can all be problems in some low-level contexts.

    💬 1🔄 0⭐ 0
  • Sep 12, 2026, 4:21 PM

    @matt even x86 generally doesn’t microcode important stuff these days, too slow (arguably rep mov is in a weird way I guess?).

    💬 1🔄 0⭐ 0
  • Sep 12, 2026, 4:27 PM

    @catfish_man So then, the whole microcode point seems invalid. I get that the original post might have just been satirizing criticisms of other languages and/or unquestioning C zealotry.

    💬 2🔄 0⭐ 0
  • Sep 12, 2026, 4:46 PM

    @matt they’re *all* invalid, intentionally. They’re also all, technically, sorta valid. If I wanted to be serious about odd or now-dubious runtime functionality I might have chosen signal handling or wide string functions. If I wanted to be serious about perf problems I might have chosen NUL-terminated strings. If I was serious about effects I would have said setjmp/longjmp. In general, I would have mentioned safety/security, at all.

    But I was just being playful.

    💬 1🔄 0⭐ 0
  • Sep 12, 2026, 5:10 PM

    @catfish_man I'm relieved that my current favorite language, Rust, doesn't have the actual serious problems (except where necessary for C/platform compatibility, e.g. CString for null-terminated C strings and wide strings for Win32).

    💬 0🔄 0⭐ 0
  • Sep 12, 2026, 9:51 PM

    @matt @Catfish_Man You two might have misunderstood something, all modern cores use microcode, and all instructions are converted to microcode. That doesn't make them slow. What is slow is when the CPU doesn't have a unit that correspond to a specific instruction, and the CPU therefore instead run a lengthy series of microinstructions in order to implement that instruction. This hasn't got anything to do with the ISA, the ISA does not specify anything about the microcode.

    💬 0🔄 0⭐ 1
  • Sep 12, 2026, 10:07 PM

    @NohatCoder @matt I’m just using a more specific definition of microcode than you (eg excluding cracked instructions).

    But beyond that, most common instructions are single uop these days.

    I never said anything about ISA, other than using it as a shorthand to refer to groups of current uarchs.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0