5 ms·

C/C++ don’t really have “benefits”, they have inertia. In a hypothetical world where both came into being at the same time as modern languages no one would use

by zionic 5y ago

C/C++ don’t really have “benefits”, they have inertia. In a hypothetical world where both came into being at the same time as modern languages no one would use them. Sadly, I’m to the point that I think a lot of people are going to have to die off before C/C++ are fully replaced if ever. It’s just too ingrained in the current status quo, and we all have to suffer for it.

kwertyoowiyop 5y ago
C/C++ will be around for at least a hundred years. Our descendants will be writing C/C++ code on Mars.
- zionic 5y ago
  I don’t know about that, I can see Rust having a certain aesthetic appeal to martians.
  - axelf4 5y ago
    Nah, they definitely use Zig.
nickelpro 5y ago
On any given platform, C tends to have the only lingua franka ABI. For that reason it will be around until the sun burns out.
- pjmlp 5y ago
  On Android, ChromeOS, IBM i, z/OS, ClearPath it isn't.
- pornel 5y ago
  The C ABI will outlive C, like the term "lingua franca" outlived the Franks. Pretty much every other language has support for the C ABI.
  - jstimpfle 5y ago
    One complication is that it's not just about ABIs but at least as much about APIs. And C headers often make some use of the preprocessor. Usage of the preprocessor often even is part of the API, i.e. APIs expose preprocessor macros for the API consumer. Zig has a built-in C compiler and supposedly you can just "include <header.h>" from within a Zig source file. Rust has a tool called bindgen. There are other tools, I haven't tried either of them, but the fact alone that I'm somewhat familiar with the Windows (and some other platforms') headers makes me not look forward to the friction of interfacing with some tried and true software platforms and libraries from within a different language. I know there has been some work going on at Windows on porting their APIs to a meta-language. Does anyone know how much progress was made on that front?
    - pornel 5y ago
      The Windows meta-API thing is done: https://lib.rs/windows https://lib.rs/windows We'll probably continue using C headers as a poor ABI definition format, even without writing programs in C. Sort-of like JSON used outside of JavaScript, or M4 known as autoconf syntax, rather than a standalone language. But C headers as an ABI definition format are overcomplicated and fragile (e.g. dependent on system headers, compiler-specific built-in defs, and arbitrary contraptions that make config.h), and not expressive enough at the same time (e.g. lacking thread-safety information, machine-readable memory management, explicit feature flags, versioning, etc.). So I think there's a motivation to come up with a better ABI and a better ABI definition format. For example, Swift has a stable ABI that C can't use, so there's already a chunk of macOS and iOS that has moved past C.
      - jstimpfle 5y ago
        Not disagreeing about the issues of header files and the difficulty of consuming them from other languages (which was my point). But regarding ABI definitions, I suspect that introducing "thread-safety information, machine-readable memory management, explicit feature flags" will make interopability at the binary level difficult or impossible, which is even worse.

by zionic 5y ago

kwertyoowiyop 5y ago

C/C++ will be around for at least a hundred years. Our descendants will be writing C/C++ code on Mars.

zionic 5y ago
I don’t know about that, I can see Rust having a certain aesthetic appeal to martians.
- axelf4 5y ago
  Nah, they definitely use Zig.

nickelpro 5y ago

On any given platform, C tends to have the only lingua franka ABI. For that reason it will be around until the sun burns out.

pjmlp 5y ago
On Android, ChromeOS, IBM i, z/OS, ClearPath it isn't.
pornel 5y ago
The C ABI will outlive C, like the term "lingua franca" outlived the Franks. Pretty much every other language has support for the C ABI.
- jstimpfle 5y ago
  One complication is that it's not just about ABIs but at least as much about APIs. And C headers often make some use of the preprocessor. Usage of the preprocessor often even is part of the API, i.e. APIs expose preprocessor macros for the API consumer. Zig has a built-in C compiler and supposedly you can just "include <header.h>" from within a Zig source file. Rust has a tool called bindgen. There are other tools, I haven't tried either of them, but the fact alone that I'm somewhat familiar with the Windows (and some other platforms') headers makes me not look forward to the friction of interfacing with some tried and true software platforms and libraries from within a different language. I know there has been some work going on at Windows on porting their APIs to a meta-language. Does anyone know how much progress was made on that front?
  - pornel 5y ago
    The Windows meta-API thing is done: https://lib.rs/windows https://lib.rs/windows We'll probably continue using C headers as a poor ABI definition format, even without writing programs in C. Sort-of like JSON used outside of JavaScript, or M4 known as autoconf syntax, rather than a standalone language. But C headers as an ABI definition format are overcomplicated and fragile (e.g. dependent on system headers, compiler-specific built-in defs, and arbitrary contraptions that make config.h), and not expressive enough at the same time (e.g. lacking thread-safety information, machine-readable memory management, explicit feature flags, versioning, etc.). So I think there's a motivation to come up with a better ABI and a better ABI definition format. For example, Swift has a stable ABI that C can't use, so there's already a chunk of macOS and iOS that has moved past C.
    - jstimpfle 5y ago
      Not disagreeing about the issues of header files and the difficulty of consuming them from other languages (which was my point). But regarding ABI definitions, I suspect that introducing "thread-safety information, machine-readable memory management, explicit feature flags" will make interopability at the binary level difficult or impossible, which is even worse.