3 ms·

Upon some reflection, I could add to the list of reasons for the popularity of C: * Interop with every language. * Existing codebases. * Years of virtual

by kubb 5y ago

Upon some reflection, I could add to the list of reasons for the popularity of C: * Interop with every language. * Existing codebases. * Years of virtual platform excusivity in embedded systems, and OS. * Momentum (people like to get into things that are popular).

qsort 5y ago
I think the fundamental reason is that there aren't that many alternatives. Of course, if I were to write application software of any kind I wouldn't choose C, but for things like FFI/interop or embedded, anything that isn't C, C++ or Rust is a complete non-starter, and even C++ and Rust are often a stretch.
- kaba0 5y ago
  How is C++ a stretch? I don’t think there is any domain left where C++ would not be applicable but C is.
  - lelanthran 5y ago
    > How is C++ a stretch? I don’t think there is any domain left where C++ would not be applicable but C is. Reusable code. Your library written in C++ can't be called as easily from Python, PHP, Perl, C, Pascal, Rust, Go or any of the other languages people like to use. Just do a search for uses of libffi and you'll get a pretty good idea why C is still more popular than C++.
    - xyzzyz 5y ago
      That’s not true. C++ code can be called from foreign languages just as easily as C, you just have to provide C-like interface and mark it as extern “C”.
      - qsort 5y ago
        Sure, but that means I have to provide the interface myself. One of the main advantages of C++ over C is that you don't have to pass around pointers to structs, so you're stuck between using C++ as basically C, or duplicating every object the API needs to expose. Obviously you can make it work, and it probably makes a lot of sense for larger libraries where the advantages of working with C++ really pull their weight, but regardless, FFI is still one of the (admittedly fewer and fewer) niches where C shines.
        xyzzyz 5y ago
        > you're stuck between using C++ as basically C, or duplicating every object the API needs to expose Yes, you need to provide the C-like interface on the API boundary, but internally you can just use normal C++ for everything else. Sure, that C-like interface will not be as nice and comfortable as it would have been with C++ interface, but then again, neither it would be if you used C instead of C++. > FFI is still one of the (admittedly fewer and fewer) niches where C shines. No, it’s C linkage that shines, and C++ can use C linkage just fine.
      - deleted 5y ago
        [deleted]
      - lelanthran 5y ago
        > That’s not true. C++ code can be called from foreign languages just as easily as C, you just have to provide C-like interface and mark it as extern “C”. And ensure that you catch every exception and turn it into an error code?

by kubb 5y ago

qsort 5y ago

I think the fundamental reason is that there aren't that many alternatives. Of course, if I were to write application software of any kind I wouldn't choose C, but for things like FFI/interop or embedded, anything that isn't C, C++ or Rust is a complete non-starter, and even C++ and Rust are often a stretch.

kaba0 5y ago
How is C++ a stretch? I don’t think there is any domain left where C++ would not be applicable but C is.
- lelanthran 5y ago
  > How is C++ a stretch? I don’t think there is any domain left where C++ would not be applicable but C is. Reusable code. Your library written in C++ can't be called as easily from Python, PHP, Perl, C, Pascal, Rust, Go or any of the other languages people like to use. Just do a search for uses of libffi and you'll get a pretty good idea why C is still more popular than C++.
  - xyzzyz 5y ago
    That’s not true. C++ code can be called from foreign languages just as easily as C, you just have to provide C-like interface and mark it as extern “C”.
    - qsort 5y ago
      Sure, but that means I have to provide the interface myself. One of the main advantages of C++ over C is that you don't have to pass around pointers to structs, so you're stuck between using C++ as basically C, or duplicating every object the API needs to expose. Obviously you can make it work, and it probably makes a lot of sense for larger libraries where the advantages of working with C++ really pull their weight, but regardless, FFI is still one of the (admittedly fewer and fewer) niches where C shines.
      - xyzzyz 5y ago
        > you're stuck between using C++ as basically C, or duplicating every object the API needs to expose Yes, you need to provide the C-like interface on the API boundary, but internally you can just use normal C++ for everything else. Sure, that C-like interface will not be as nice and comfortable as it would have been with C++ interface, but then again, neither it would be if you used C instead of C++. > FFI is still one of the (admittedly fewer and fewer) niches where C shines. No, it’s C linkage that shines, and C++ can use C linkage just fine.
    - deleted 5y ago
      [deleted]
    - lelanthran 5y ago
      > That’s not true. C++ code can be called from foreign languages just as easily as C, you just have to provide C-like interface and mark it as extern “C”. And ensure that you catch every exception and turn it into an error code?