3 ms·

Not exactly though, turing complete means the language can compute anything, not do anything. In the vast majority of popular programming languages, it is gene

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.

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.