3 ms·

> ... and the limitations of C makes it worse. That's somewhat ironic considering that C is one of the few languages which can do literally anything, from the

by sgbeal 4y ago

> ... and the limitations of C makes it worse. That's somewhat ironic considering that C is one of the few languages which can do literally anything, from the lowest-level direct memory access to the highest-level abstractions. It's the language many other languages are implemented in, so it can demonstrably do anything they can do.

lolinder 4y ago
The same could be said of writing x86 machine code directly in the binary format: it's the language every other language eventually executes in, so it can demonstrably do anything they can do. Obviously C is a much better programming language for human use than x86, but the mere fact that a high-level language can be implemented in a low-level language is not evidence that the low-level language has no limitations. The limitations live in meatspace, between keyboard and chair, but they're very real.
kllrnohj 4y ago
No it can't. There's loads of stuff C can't do, which is why inline assembly & compiler intrinsics are quite common in the space. Otherwise you're basically just saying C is Turing-complete. Which, yeah, so are most languages. That's not actually a special property.
- gateorade 4y ago
  Not exactly though, turing complete means the language can compute anything, not do anything. In the vast majority of popular programming languages, it is generally not possible to write bare-metal device drivers, for instance.
  - kllrnohj 4y ago
    It's not possible to do that in pure C, either, though. You need at least some assembly to speak to the hardware, which you then make C bindings for to do the rest in C. But any language with an FFI can pull the same stunt for the most part, to varying degrees of difficulty. But there's no shortage of toy kernels written in dozens of different languages - C is very much not required or unique here.
    - gateorade 4y ago
      I'm confused by the mixing of abstractions going on here. Technically it's not possible to do anything in any programming language without assembly. But barring that, it is absolutely possible to write bare-metal device drivers without any assembly, because most systems use memory-mapped IO and C can directly reference and dereference that memory. And then, if an FFI is required do to X, can you really say it's possible to do an X in your language? C/C++/unsafe Rust or another language that can directly reference memory still ends up being required in that end.
      - kllrnohj 4y ago
        memory-mapped IO is available from a ton of languages, and in C you still have to use an "FFI" as part of this to actually establish the memory map. Using only the C language, you cannot make a device driver. Full stop. You must use an FFI / inline assembly to establish critical pieces of it. And if you're allowing that for C, then you necessarily need to allow that for all languages. Thus, C isn't very unique here. C's lack of anything resembling safety makes it "good" at working with things like device drivers, sure. But it's not actually that unique of a property, shared by quite a number of AOT'd languages. C++, Rust, Go, D, Zig, etc... heck, even Haskell ( https://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has... all can be used in this role. C's prevalence in the kernel space is arguably more to do with legacy & inertia than actually being a good fit for it. See for example all the undefined behavior suddenly making kernel devs scream and wail endlessly.

by sgbeal 4y ago

lolinder 4y ago

The same could be said of writing x86 machine code directly in the binary format: it's the language every other language eventually executes in, so it can demonstrably do anything they can do. Obviously C is a much better programming language for human use than x86, but the mere fact that a high-level language can be implemented in a low-level language is not evidence that the low-level language has no limitations. The limitations live in meatspace, between keyboard and chair, but they're very real.

kllrnohj 4y ago

No it can't. There's loads of stuff C can't do, which is why inline assembly & compiler intrinsics are quite common in the space. Otherwise you're basically just saying C is Turing-complete. Which, yeah, so are most languages. That's not actually a special property.

gateorade 4y ago
Not exactly though, turing complete means the language can compute anything, not do anything. In the vast majority of popular programming languages, it is generally not possible to write bare-metal device drivers, for instance.
- kllrnohj 4y ago
  It's not possible to do that in pure C, either, though. You need at least some assembly to speak to the hardware, which you then make C bindings for to do the rest in C. But any language with an FFI can pull the same stunt for the most part, to varying degrees of difficulty. But there's no shortage of toy kernels written in dozens of different languages - C is very much not required or unique here.
  - gateorade 4y ago
    I'm confused by the mixing of abstractions going on here. Technically it's not possible to do anything in any programming language without assembly. But barring that, it is absolutely possible to write bare-metal device drivers without any assembly, because most systems use memory-mapped IO and C can directly reference and dereference that memory. And then, if an FFI is required do to X, can you really say it's possible to do an X in your language? C/C++/unsafe Rust or another language that can directly reference memory still ends up being required in that end.
    - kllrnohj 4y ago
      memory-mapped IO is available from a ton of languages, and in C you still have to use an "FFI" as part of this to actually establish the memory map. Using only the C language, you cannot make a device driver. Full stop. You must use an FFI / inline assembly to establish critical pieces of it. And if you're allowing that for C, then you necessarily need to allow that for all languages. Thus, C isn't very unique here. C's lack of anything resembling safety makes it "good" at working with things like device drivers, sure. But it's not actually that unique of a property, shared by quite a number of AOT'd languages. C++, Rust, Go, D, Zig, etc... heck, even Haskell ( https://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has... all can be used in this role. C's prevalence in the kernel space is arguably more to do with legacy & inertia than actually being a good fit for it. See for example all the undefined behavior suddenly making kernel devs scream and wail endlessly.