7 ms·

Why use C and keep reinventing things that C++ provides?

by inetknght 3y ago

pjmlp 3y ago
I keep having that discussion since the C vs C++ Usenet flamewars....
zffr 3y ago
There’s lots of software already written in C that needs to be updated and maintained
epistasis 3y ago
If one is ready to switch languages, then the clear winner is rust over C++, and I say that as someone who avoided diving into Rust for years because it seemed completely overhyped and with too much cryptic syntax. C still wins by far when writing libraries that will be used by lots of other people. Doesn't matter what language they are using, they will be able to add in a library written in C very easily. However, C++ or Rust libraries, even with appropriate bindings for the target language, users of the library will need to bring in an entirely new compiler tool chain that may or may not exist on the target architecture. But the C tool chain will exist for that architecture and be robust.
- humanrebar 3y ago
  Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".
  - insanitybit 3y ago
    > Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use them much less frequently since I don't find debuggers as useful for the types of bugs I have these days, and sanitizers are only useful if you have unsafe, and profilers are cool but usually I just write benchmarks using a crate and then iterate from there.
    - twic 3y ago
      The parent comment says "compiler tool chain", and i understand "tooling" here as meaning that. So, compiler, linker, assembler, etc. All the major C compilers are also C++ compilers, and none are (yet) Rust compilers, so out of the gate, C++ has similar availability to C.
      - bfrog 3y ago
        If you are going on proprietary tool chains... most of those are moving to llvm which rust is based on. In theory any proprietary toolchain based on llvm could provide rustc given incentives to do so. If you are speaking to missing a rust compiler built on gcc, that seems to be an ongoing project with some momentum. Realistically the most widely used architectures are now supported by rustc through llvm... x86, arm, riscv, and even to some extent xtensa now. Power, arc, mips, sparc, and some others aren't too far away if someone cared enough. If Linux can support Rust, I'd think that's a good sign most project can use Rust.
        humanrebar 3y ago
        That's just the compilation toolchain. For better or worse, existing C projects have their whole workflows sitting on top of bespoke tools with the assumption that there is a C toolchain. And Rust projects assume cargo, etc. You're more or less doing a parallel rewrite in Rust to adopt Rust in an existing C project. The Linux kernel already does extensive bespoke tooling and it's low level enough to skip cargo and such. It's rare to see that approach in Rust projects in the wild.
      - epistasis 3y ago
        And yet, even with that, Yann Collet credits Google's use of C++ for the compression library as a critical mistake that allowed him, an unknown, to gain traction with his own compression methods. Google later rewrote their library in C: https://overcast.fm/+LfVPHmBTo https://overcast.fm/+LfVPHmBTo Even if the tool chain exists, it must be adopted, unless you can rely on binaries being available for your end users, which will never be the case for a library which is just starting our. And adding another dependency to your build process, especially one as complex and with as many breaking version changes as C++, is a lot of work to take on.
  - junon 3y ago
    This is nonsense. Rust is based off of LLVM, which is what Clang is based off of. Name one modern, actually used, non-archaic system that LLVM doesn't run on. Beyond that, Cargo and all associated tooling run pretty much everywhere. So I'm not sure what outdated trope you're on about here.
- kllrnohj 3y ago
  Exporting a stable C ABI/API in no way requires writing the implementation in C. See Android's NDK for a rather widely deployed example. All the APIs are C, yet none of the implementations are C. Same thing works great in Rust, too. You can trivially export C from a Rust implementation.
  - epistasis 3y ago
    My comment acknowledged what you state, but then went on to point out that it requires adding a tool chain to compile Rust or C++, neither of which are trivia and which may not exist at all on the target architecture.
- coliveira 3y ago
  People using C will not change to your language-du-jour, please stop.
  - epistasis 3y ago
    You seem to be replying to the wrong comment, I am not suggesting that people switch away from C.
  - adwn 3y ago
    > People using C will not change to your language-du-jour, please stop. Two years ago, your argument would have implied that Rust would never be allowed into the Linux kernel, and yet here we are.
    - netule 3y ago
      I wonder if Linus it taking the time to teach himself Rust.
    - coliveira 3y ago
      There are all kinds of weird stuff in the kernel, many of them will just die.
      - mikebenfield 3y ago
        What other programming languages are used in Linux kernel code?
    - BearOso 3y ago
      Rust in the kernel is a whole different beast than what most people think--no standard library, no cargo or external crates, some memory safety features removed. It's kind of just an alternative syntax.
  - pjmlp 3y ago
    They better improve their error free coding skills when liability laws come for them.
- ActorNightly 3y ago
  Rust is by far not mature enough for serious development. Recent shenanigans with crablang are a strong sign of it going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.
  - duped 3y ago
    > Rust is by far not mature enough for serious development Except it's being used for serious development today > going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state. So one of the most widely used applications programming languages in the world?
    - ActorNightly 3y ago
      >Except it's being used for serious development today No, its being used for pet projects by people. Serious development = major companies using it in backends. >So one of the most widely used applications programming languages in the world? Because of CS programs, and legacy software written in java. Java has a community dedicated to pushing theoretical CS concepts into the language (much like Rust), while allowing things like a logging library to fetch code from anywhere on the internet and execute it, by default (which I would bet on would be the future of Rust given current trajectory)
      - c-cube 3y ago
        > No, its being used for pet projects by people. Serious development = major companies using it in backends. You mean companies like Dropbox, Cloudflare, Amazon, Microsoft...? Are they too small to be relevant?
        ActorNightly 3y ago
        Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons https://github.com/firecracker-microvm/firecracker/search?q=unsafe https://github.com/firecracker-microvm/firecracker/search?q=... The fact that 'unsafe' even exists in Rust means it's no better than C with some macros. Don't get me wrong, Rust has it's place, like all the other languages that came about for various reasons, but it's not going to gain wide adoption. Future of programming consists of 2 languages - something like C that has a small instruction set for adopting to new hardware, and something that is very high level, higher than Python with LLM in the background. Everything in the middle is fodder.
properclass 3y ago
the obvious answer is that one does not want some things that C++ entails, three examples: - name mangling - larger gap between source code and ISA - impedance mismatch when working with C APIs that being said, some do not want more macros either
- adwn 3y ago
  > name mangling Can be turned off on demand for relevant symbols. > larger gap between source code and ISA There's already a huge gap between C code and machine code (see: Undefined Behavior). C hasn't been a "portable assembler" for a very long time. > impedance mismatch when working with C APIs C++ has no problem working with C APIs.
ChrisRR 3y ago
For me the issue is that using C++ brings every single feature in with it. It's very easy to hire developers and they know the entirety of the C language, but using C++ has every feature you could ever want and multiple ways of achieving the same thing. It makes writing (and hiring) a low-level project in C++ a much more complex task. It may have benefits, it may not. But C++ is so huge that it's difficult to judge whether it would offer an advantage. And then there's the minefield of tooling in embedded development...
- hgsgm 3y ago
  Knowing every feature of C means they have to learn custom patterns on top of the C to make things work, and that almost always means horrific unhygienic macros.
tialaramex 3y ago
But this isn't something the C++ language provides, which is hilarious. C++ keeps C's crap array type as its native array type. You need to reach into the C++ standard library to get this awkward library type, std::array<type,N> and then finally you get an array type that remembers how big it is and has some basic features like swap.
- pjmlp 3y ago
  True, but it also adds lot of features that help to easily migrate to saner features without rewriting the world and throw away 30 years of tooling. Microsoft security team is on the record that just because they are adopting Rust, they won't shy away from C++.
  - tialaramex 3y ago
    I'm kind of on board with this, but the problem is that it's 30 years of rotten wood. Rust started from a more secure foundation and has put a lot of effort into stabilising even the trickier ground - whereas in C++ it's too often "Yeah, we don't think about it too hard, when there are strong winds I don't go up into the top floor, the creaking is very loud, I'd rather just never find out". Example, Rust 1.0 had std::mem::uninitialized::<T>() which gives a T but it's obviously uninitialized. It's marked "unsafe" of course, but is that enough? Turns out they later realised that no, it's strictly never OK to do this, so the unsafe label was insufficiently cautious. Today std::mem::uninitialized is deprecated, Rust never removes stuff from the standard library, but you should not use this library call. The type MaybeUninit<T> is the fix. Since MaybeUninit<T> might not be initialized, it's OK if it's not initialized, and since it might be T, it's OK for it to occupy the same amount of space as T. So, then we can initialize this memory, and tell the compiler it's initialized now, it's a T not a MaybeUninit<T>. Can you guess how that works? It's pretty clever, and C++ could do almost the same trick, but it never has and my guess is it never will. If you don't know and are wondering, check that type definition carefully - MaybeUninit<T> is a union For contrast, in his safety talk Bjarne Stroustrup just says as if it's obviously true, that it's safe to have uninitialized char arrays in C++. And his rationale sounds exactly like how std::mem::uninitialized happened - any possible value of a byte is a valid byte, so that's good enough, right? Nope, ask compiler engineers, there were plenty in the room when Bjarne said that, but he didn't ask them.
uecker 3y ago
These are dependent types which C++ does not have at all. The C support is fairly weak though... But most programming language people I know agree that dependent types are they way to guard against overflow with minimal overhead. So hope we can evolve C in this direction.
- inetknght 3y ago
  > These are dependent types which C++ does not have at all. As a C++ developer, that sounds strange. Can you point me to some documentation about "dependent types"?

Why use C and keep reinventing things that C++ provides?

pjmlp 3y ago

I keep having that discussion since the C vs C++ Usenet flamewars....

zffr 3y ago

There’s lots of software already written in C that needs to be updated and maintained

epistasis 3y ago

If one is ready to switch languages, then the clear winner is rust over C++, and I say that as someone who avoided diving into Rust for years because it seemed completely overhyped and with too much cryptic syntax. C still wins by far when writing libraries that will be used by lots of other people. Doesn't matter what language they are using, they will be able to add in a library written in C very easily. However, C++ or Rust libraries, even with appropriate bindings for the target language, users of the library will need to bring in an entirely new compiler tool chain that may or may not exist on the target architecture. But the C tool chain will exist for that architecture and be robust.

humanrebar 3y ago
Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".
- insanitybit 3y ago
  > Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use them much less frequently since I don't find debuggers as useful for the types of bugs I have these days, and sanitizers are only useful if you have unsafe, and profilers are cool but usually I just write benchmarks using a crate and then iterate from there.
  - twic 3y ago
    The parent comment says "compiler tool chain", and i understand "tooling" here as meaning that. So, compiler, linker, assembler, etc. All the major C compilers are also C++ compilers, and none are (yet) Rust compilers, so out of the gate, C++ has similar availability to C.
    - bfrog 3y ago
      If you are going on proprietary tool chains... most of those are moving to llvm which rust is based on. In theory any proprietary toolchain based on llvm could provide rustc given incentives to do so. If you are speaking to missing a rust compiler built on gcc, that seems to be an ongoing project with some momentum. Realistically the most widely used architectures are now supported by rustc through llvm... x86, arm, riscv, and even to some extent xtensa now. Power, arc, mips, sparc, and some others aren't too far away if someone cared enough. If Linux can support Rust, I'd think that's a good sign most project can use Rust.
      - humanrebar 3y ago
        That's just the compilation toolchain. For better or worse, existing C projects have their whole workflows sitting on top of bespoke tools with the assumption that there is a C toolchain. And Rust projects assume cargo, etc. You're more or less doing a parallel rewrite in Rust to adopt Rust in an existing C project. The Linux kernel already does extensive bespoke tooling and it's low level enough to skip cargo and such. It's rare to see that approach in Rust projects in the wild.
    - epistasis 3y ago
      And yet, even with that, Yann Collet credits Google's use of C++ for the compression library as a critical mistake that allowed him, an unknown, to gain traction with his own compression methods. Google later rewrote their library in C: https://overcast.fm/+LfVPHmBTo https://overcast.fm/+LfVPHmBTo Even if the tool chain exists, it must be adopted, unless you can rely on binaries being available for your end users, which will never be the case for a library which is just starting our. And adding another dependency to your build process, especially one as complex and with as many breaking version changes as C++, is a lot of work to take on.
- junon 3y ago
  This is nonsense. Rust is based off of LLVM, which is what Clang is based off of. Name one modern, actually used, non-archaic system that LLVM doesn't run on. Beyond that, Cargo and all associated tooling run pretty much everywhere. So I'm not sure what outdated trope you're on about here.
kllrnohj 3y ago
Exporting a stable C ABI/API in no way requires writing the implementation in C. See Android's NDK for a rather widely deployed example. All the APIs are C, yet none of the implementations are C. Same thing works great in Rust, too. You can trivially export C from a Rust implementation.
- epistasis 3y ago
  My comment acknowledged what you state, but then went on to point out that it requires adding a tool chain to compile Rust or C++, neither of which are trivia and which may not exist at all on the target architecture.
coliveira 3y ago
People using C will not change to your language-du-jour, please stop.
- epistasis 3y ago
  You seem to be replying to the wrong comment, I am not suggesting that people switch away from C.
- adwn 3y ago
  > People using C will not change to your language-du-jour, please stop. Two years ago, your argument would have implied that Rust would never be allowed into the Linux kernel, and yet here we are.
  - netule 3y ago
    I wonder if Linus it taking the time to teach himself Rust.
  - coliveira 3y ago
    There are all kinds of weird stuff in the kernel, many of them will just die.
    - mikebenfield 3y ago
      What other programming languages are used in Linux kernel code?
  - BearOso 3y ago
    Rust in the kernel is a whole different beast than what most people think--no standard library, no cargo or external crates, some memory safety features removed. It's kind of just an alternative syntax.
- pjmlp 3y ago
  They better improve their error free coding skills when liability laws come for them.
ActorNightly 3y ago
Rust is by far not mature enough for serious development. Recent shenanigans with crablang are a strong sign of it going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.
- duped 3y ago
  > Rust is by far not mature enough for serious development Except it's being used for serious development today > going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state. So one of the most widely used applications programming languages in the world?
  - ActorNightly 3y ago
    >Except it's being used for serious development today No, its being used for pet projects by people. Serious development = major companies using it in backends. >So one of the most widely used applications programming languages in the world? Because of CS programs, and legacy software written in java. Java has a community dedicated to pushing theoretical CS concepts into the language (much like Rust), while allowing things like a logging library to fetch code from anywhere on the internet and execute it, by default (which I would bet on would be the future of Rust given current trajectory)
    - c-cube 3y ago
      > No, its being used for pet projects by people. Serious development = major companies using it in backends. You mean companies like Dropbox, Cloudflare, Amazon, Microsoft...? Are they too small to be relevant?
      - ActorNightly 3y ago
        Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons https://github.com/firecracker-microvm/firecracker/search?q=unsafe https://github.com/firecracker-microvm/firecracker/search?q=... The fact that 'unsafe' even exists in Rust means it's no better than C with some macros. Don't get me wrong, Rust has it's place, like all the other languages that came about for various reasons, but it's not going to gain wide adoption. Future of programming consists of 2 languages - something like C that has a small instruction set for adopting to new hardware, and something that is very high level, higher than Python with LLM in the background. Everything in the middle is fodder.

properclass 3y ago

the obvious answer is that one does not want some things that C++ entails, three examples: - name mangling - larger gap between source code and ISA - impedance mismatch when working with C APIs that being said, some do not want more macros either

adwn 3y ago
> name mangling Can be turned off on demand for relevant symbols. > larger gap between source code and ISA There's already a huge gap between C code and machine code (see: Undefined Behavior). C hasn't been a "portable assembler" for a very long time. > impedance mismatch when working with C APIs C++ has no problem working with C APIs.

ChrisRR 3y ago

For me the issue is that using C++ brings every single feature in with it. It's very easy to hire developers and they know the entirety of the C language, but using C++ has every feature you could ever want and multiple ways of achieving the same thing. It makes writing (and hiring) a low-level project in C++ a much more complex task. It may have benefits, it may not. But C++ is so huge that it's difficult to judge whether it would offer an advantage. And then there's the minefield of tooling in embedded development...

hgsgm 3y ago
Knowing every feature of C means they have to learn custom patterns on top of the C to make things work, and that almost always means horrific unhygienic macros.

tialaramex 3y ago

But this isn't something the C++ language provides, which is hilarious. C++ keeps C's crap array type as its native array type. You need to reach into the C++ standard library to get this awkward library type, std::array<type,N> and then finally you get an array type that remembers how big it is and has some basic features like swap.

pjmlp 3y ago
True, but it also adds lot of features that help to easily migrate to saner features without rewriting the world and throw away 30 years of tooling. Microsoft security team is on the record that just because they are adopting Rust, they won't shy away from C++.
- tialaramex 3y ago
  I'm kind of on board with this, but the problem is that it's 30 years of rotten wood. Rust started from a more secure foundation and has put a lot of effort into stabilising even the trickier ground - whereas in C++ it's too often "Yeah, we don't think about it too hard, when there are strong winds I don't go up into the top floor, the creaking is very loud, I'd rather just never find out". Example, Rust 1.0 had std::mem::uninitialized::<T>() which gives a T but it's obviously uninitialized. It's marked "unsafe" of course, but is that enough? Turns out they later realised that no, it's strictly never OK to do this, so the unsafe label was insufficiently cautious. Today std::mem::uninitialized is deprecated, Rust never removes stuff from the standard library, but you should not use this library call. The type MaybeUninit<T> is the fix. Since MaybeUninit<T> might not be initialized, it's OK if it's not initialized, and since it might be T, it's OK for it to occupy the same amount of space as T. So, then we can initialize this memory, and tell the compiler it's initialized now, it's a T not a MaybeUninit<T>. Can you guess how that works? It's pretty clever, and C++ could do almost the same trick, but it never has and my guess is it never will. If you don't know and are wondering, check that type definition carefully - MaybeUninit<T> is a union For contrast, in his safety talk Bjarne Stroustrup just says as if it's obviously true, that it's safe to have uninitialized char arrays in C++. And his rationale sounds exactly like how std::mem::uninitialized happened - any possible value of a byte is a valid byte, so that's good enough, right? Nope, ask compiler engineers, there were plenty in the room when Bjarne said that, but he didn't ask them.

uecker 3y ago

These are dependent types which C++ does not have at all. The C support is fairly weak though... But most programming language people I know agree that dependent types are they way to guard against overflow with minimal overhead. So hope we can evolve C in this direction.

inetknght 3y ago
> These are dependent types which C++ does not have at all. As a C++ developer, that sounds strange. Can you point me to some documentation about "dependent types"?