11 ms·

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these features are not important to you, there are hundreds of slower, more complex and less portable languages to choose from, that provide other benefits instead, such as more convenience, more correctness and higher level abstractions.

WithinReason 5y ago
Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?
- raptorfactor 5y ago
  Having never used such a language, I'm curious, what's the debugging experience like? Can I source level step the application in the original language or do I have to debug the generated C?
  - rightbyte 5y ago
    You can put in line pragmas for e.g. gcc that will point you from "foo.gen.c" to "foo.fancylang". However it is not very useful unless the fancy language matches C's structs and native types and also does not mangle names.
  - TingPing 5y ago
    It is always a pain to debug transpiled C IME.
- rwmj 5y ago
  One of the criteria is "excellent debugging support" which you don't get with transpiled languages, since you'll be buried in generated code when you open the debugger.
  - pjmlp 5y ago
    Languages like Eiffel prove this isn't the case, it is a matter of proper debug tooling.
    - zabzonk 5y ago
      Of course, Eiffel is such a popular and widely used language, with a great toolset. /s
      - pjmlp 5y ago
        The amount of users doesn't change the fact of the tooling quality, but no wonder, UNIX folks tend to only take free beer, so what do they know about fine wine.
        zabzonk 5y ago
        I've read the Eiffel books, and tried to use the Eifell tools, on Windows - a horrid experience. I am not a "UNIX folk" and I can't imagine what comparing UNIX and Eifell has to do with anything. It is basically an unuseable programming language and toolset, promoted by an egomaniac with a grudge against C++. If you disagree, please provide a link to something medium sized and useful written in Eifel.
        pjmlp 5y ago
        Useful to whom? To you or the companies that keep Eiffel Software in business for 30 years?
        zabzonk 5y ago
        > the companies that keep Eiffel Software in business for 30 years? Such as? If you can't provide links to people using Eiffel succefuly, then maybe there are none.
        5y ago
- 10x-dev 5y ago
  Control over the code that actually runs. We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages. If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't control) then it better be a wise tradeoff.
  - WithinReason 5y ago
    The downside of reordering being performance? Or something else?
    - 10x-dev 5y ago
      Performance is usually the upside. The downside is subtle bugs that can happen due to side effects of the statements being reordered between sequence points.
      - WithinReason 5y ago
        AFAIK compilers don't reorder if it would change the result.
        Thiez 5y ago
        Compilers not allowed to violate the language spec when optimizing. But the spec may be fairly generous in its allowed interpretations, which may not match what a programmer may naively expect. C, with its many undefined behaviors and implementation defined behaviors, is especially dangerous.
- dig1 5y ago
  Depending on transpiler (compilers that will compile to C), you can get near representation in C (rarely) or something completely different (frequently). In Scheme/LISP world (where transpilers were popular for a while), even a simple expression like "(+ 1 1)" will rarely give you something like: "int a = 1 + 1;". I've seen these things would produce dozen of lines of various boxing/unboxing calls, type checks and GC protection marks. If the compiler is really aggressive, it will just put "2" as a constant. I think that the only benefit of "compiling to C" was reusing existing compilers, not tooling around it. Also, debugging that code is a nightmare unless you are intimate with transpiler internals.
  - sys_64738 5y ago
    A compiler that translates to another language used to be called a translator.
    - zabzonk 5y ago
      All compilers covert programs in one language (say C) into another, (say assembler or machine code), and they are called compilers. The whole transpiler thing is a bit bogus, but a C compiler has never IME been called a translator.
kaba0 5y ago
C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer to the metal than other system level programming languages, this myth should just die. Your code at -O3 gets mangled to oblivion, unless you are a compiler writer of the respective compiler, you will have no idea on the generated code. This is the exact same as with C++, Rust, etc, hell, C doesn’t have proper simd support, so in a way the former two is closer to the metal. But I do agree on portability and integrations - so C will not die, but I really have a hard time seeing why should I choose C over any of the listed languages, unless I target some obscure CPU architecture.
- 10x-dev 5y ago
  Are you going to mix all those languages into one project and somehow use their advantages but steer away from their disadvantages? Sure, other languages have caught up or have improved on some of the features where C shines. Let's remove portability and integration from the feature list, because that's strongly related to C's tenure. Which one of the languages you listed matches the rest of the feature set I brought up? * Small language * Fast compile times * Fast binaries * Small binaries * Great debugging experience * Close to the metal In my opinion, they all fail in at least one category, and that's expected - additional functionality can't come for free. You can only accept its cost.
  - foxfluff 5y ago
    And they fail in other categories too, e.g. C can be very terse whereas most modern so-called replacements tend towards verbose. For me that's a development exactly in the wrong direction; I'd rather have a more terse C.
  - xigoi 5y ago
    Zig? I personally haven't used it, but based on what I've heard about it, it fulfills these criteria.
mprovost 5y ago
C certainly has been battle tested but I wouldn't say that it passed with flying colours. Every one of the examples that you cite has had bugs/crashes/vulnerabilities that would have been avoided with newer languages.

WithinReason 5y ago

Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?

raptorfactor 5y ago
Having never used such a language, I'm curious, what's the debugging experience like? Can I source level step the application in the original language or do I have to debug the generated C?
- rightbyte 5y ago
  You can put in line pragmas for e.g. gcc that will point you from "foo.gen.c" to "foo.fancylang". However it is not very useful unless the fancy language matches C's structs and native types and also does not mangle names.
- TingPing 5y ago
  It is always a pain to debug transpiled C IME.
rwmj 5y ago
One of the criteria is "excellent debugging support" which you don't get with transpiled languages, since you'll be buried in generated code when you open the debugger.
- pjmlp 5y ago
  Languages like Eiffel prove this isn't the case, it is a matter of proper debug tooling.
  - zabzonk 5y ago
    Of course, Eiffel is such a popular and widely used language, with a great toolset. /s
    - pjmlp 5y ago
      The amount of users doesn't change the fact of the tooling quality, but no wonder, UNIX folks tend to only take free beer, so what do they know about fine wine.
      - zabzonk 5y ago
        I've read the Eiffel books, and tried to use the Eifell tools, on Windows - a horrid experience. I am not a "UNIX folk" and I can't imagine what comparing UNIX and Eifell has to do with anything. It is basically an unuseable programming language and toolset, promoted by an egomaniac with a grudge against C++. If you disagree, please provide a link to something medium sized and useful written in Eifel.
        pjmlp 5y ago
        Useful to whom? To you or the companies that keep Eiffel Software in business for 30 years?
        zabzonk 5y ago
        > the companies that keep Eiffel Software in business for 30 years? Such as? If you can't provide links to people using Eiffel succefuly, then maybe there are none.
        5y ago
10x-dev 5y ago
Control over the code that actually runs. We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages. If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't control) then it better be a wise tradeoff.
- WithinReason 5y ago
  The downside of reordering being performance? Or something else?
  - 10x-dev 5y ago
    Performance is usually the upside. The downside is subtle bugs that can happen due to side effects of the statements being reordered between sequence points.
    - WithinReason 5y ago
      AFAIK compilers don't reorder if it would change the result.
      - Thiez 5y ago
        Compilers not allowed to violate the language spec when optimizing. But the spec may be fairly generous in its allowed interpretations, which may not match what a programmer may naively expect. C, with its many undefined behaviors and implementation defined behaviors, is especially dangerous.
dig1 5y ago
Depending on transpiler (compilers that will compile to C), you can get near representation in C (rarely) or something completely different (frequently). In Scheme/LISP world (where transpilers were popular for a while), even a simple expression like "(+ 1 1)" will rarely give you something like: "int a = 1 + 1;". I've seen these things would produce dozen of lines of various boxing/unboxing calls, type checks and GC protection marks. If the compiler is really aggressive, it will just put "2" as a constant. I think that the only benefit of "compiling to C" was reusing existing compilers, not tooling around it. Also, debugging that code is a nightmare unless you are intimate with transpiler internals.
- sys_64738 5y ago
  A compiler that translates to another language used to be called a translator.
  - zabzonk 5y ago
    All compilers covert programs in one language (say C) into another, (say assembler or machine code), and they are called compilers. The whole transpiler thing is a bit bogus, but a C compiler has never IME been called a translator.

kaba0 5y ago

C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer to the metal than other system level programming languages, this myth should just die. Your code at -O3 gets mangled to oblivion, unless you are a compiler writer of the respective compiler, you will have no idea on the generated code. This is the exact same as with C++, Rust, etc, hell, C doesn’t have proper simd support, so in a way the former two is closer to the metal. But I do agree on portability and integrations - so C will not die, but I really have a hard time seeing why should I choose C over any of the listed languages, unless I target some obscure CPU architecture.

10x-dev 5y ago
Are you going to mix all those languages into one project and somehow use their advantages but steer away from their disadvantages? Sure, other languages have caught up or have improved on some of the features where C shines. Let's remove portability and integration from the feature list, because that's strongly related to C's tenure. Which one of the languages you listed matches the rest of the feature set I brought up? * Small language * Fast compile times * Fast binaries * Small binaries * Great debugging experience * Close to the metal In my opinion, they all fail in at least one category, and that's expected - additional functionality can't come for free. You can only accept its cost.
- foxfluff 5y ago
  And they fail in other categories too, e.g. C can be very terse whereas most modern so-called replacements tend towards verbose. For me that's a development exactly in the wrong direction; I'd rather have a more terse C.
- xigoi 5y ago
  Zig? I personally haven't used it, but based on what I've heard about it, it fulfills these criteria.

mprovost 5y ago

C certainly has been battle tested but I wouldn't say that it passed with flying colours. Every one of the examples that you cite has had bugs/crashes/vulnerabilities that would have been avoided with newer languages.