5 ms·

C programmers are systems / embedded programmers. I made my living doing C when I worked on Samba + Illumos. Really, if it isn't systems or embedded, C is ver

by ilc 4y ago

C programmers are systems / embedded programmers. I made my living doing C when I worked on Samba + Illumos. Really, if it isn't systems or embedded, C is very rare, even for someone like me with 20+ years of it, I won't code in C unless it is really the "language of choice" for the problem. And that ain't often. That said... I do write some C time to time, still.

TillE 4y ago
Yes and "systems" includes drivers, which is mostly hardware drivers but can also be eg Windows antivirus or filesystem filters. Personally I find that kind of work very frustrating, and the limitations of C makes it worse.
- 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.
stephc_int13 4y ago
This is far from a majority, but a lot of folks are still using C or an orthodox variant of C++ in the gamedev industry. Many APIs, like Vulkan or OpenGL are using pure C.
- kllrnohj 4y ago
  All the current major game engines are C++. C hasn't been widely used since the Quake 3 days. While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp https://github.com/KhronosGroup/Vulkan-Hpp And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc... You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.
  - stephc_int13 4y ago
    Sure. bgfx and imgui are very close to C in practice. This is not very common practice but a few small to medium size studios are using C only. TheMachinery was pure C. My own engine is built in C with C/C++/Zig APIs.

by ilc 4y ago

TillE 4y ago

Yes and "systems" includes drivers, which is mostly hardware drivers but can also be eg Windows antivirus or filesystem filters. Personally I find that kind of work very frustrating, and the limitations of C makes it worse.

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.

stephc_int13 4y ago

This is far from a majority, but a lot of folks are still using C or an orthodox variant of C++ in the gamedev industry. Many APIs, like Vulkan or OpenGL are using pure C.

kllrnohj 4y ago
All the current major game engines are C++. C hasn't been widely used since the Quake 3 days. While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp https://github.com/KhronosGroup/Vulkan-Hpp And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc... You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.
- stephc_int13 4y ago
  Sure. bgfx and imgui are very close to C in practice. This is not very common practice but a few small to medium size studios are using C only. TheMachinery was pure C. My own engine is built in C with C/C++/Zig APIs.