5 ms·

I don't see C anywhere near being "deprecated" in general. Usage of Rust/Zig/ATS/whatever is a rounding error by comparison to C/C++, even for new projects. Ane

I don't see C anywhere near being "deprecated" in general. Usage of Rust/Zig/ATS/whatever is a rounding error by comparison to C/C++, even for new projects. Anecdotally, I've been interviewing with a few startups building ambitious infrastructure-level projects, and none of them are using Rust. C/C++ is still the only game in town outside the HN bubble.

big_chungus 7y ago
This is true, largely because no one outside the HN bubble knows Rust/Zig/ATS/whatever. Most companies and people want to get stuff done, and a new language can get in the way of that. It'll take a while for those newer languages to pick up main-stream traction, and by a while I mean a few years of pushy college grads who used it in CS 101, 202, or 303.
- jupp0r 7y ago
  Don’t be so sure about that. I don’t know any C++ dev who hasn’t heard (good things) about Rust. It’s definitely well known in the systems programming community at this point. That’s different from using it in production though.
  - alfalfasprout 7y ago
    And that's precisely the point. You don't use C++ because it's the best thing since sliced bread. You use it because you want to easily use decades of optimized libraries and get a result that's highly performant without spending a long time creating wrappers in Rust (that may not even be easy to do w/ libraries that rely on a lot of templating).
    - vardump 7y ago
      A lot of C++ projects (not all!) have relatively few dependencies. I think this "decades of optimized libraries" is a bit hyperbole. Besides, libraries that were optimized for HW 20-30 years ago don't age all that well and are far from optimal these days. They also tend to still have a ton of bugs. Now, I'm not saying there aren't cases where you really need to build on legacy library base. Merely that it's a bit rare case.
      - tsimionescu 7y ago
        Libraries that are 20-30 years old and that people still use today are generally in continuous development over that time period, often with the same team (in a ship-of-Theseus sense). That means that they have been optimized for today's hardware for about 20 years worth of todays. Now there are cases where libraries have ossified and there is room for a new library to come and eat their cake (look at ripgrep for an example), but there are also a lot of cases where they are going to be very hard to beat (a lot of boost is in this area, I believe, and there are many other examples in specialized domains).
        jupp0r 7y ago
        boost fills more of a role that standard libraries play in other languages (think go).
    - pjmlp 7y ago
      And tooling. Mixed language development experience in Java and .NET IDEs, UI frameworks, game engines and GPGPU shaders.
tptacek 7y ago
If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises aren't compatible, because I am talking about things like Java and Python. In the 1990s and early 2000s, we were still building application code in C/C++.
- senderista 7y ago
  Hmm, I had in mind the phrase “insecure systems languages”, but I don’t want to get into a boring debate about what “systems languages” or “systems programming” mean...
  - tptacek 7y ago
    It's at least as much my fault as yours, since I said "systems language" as a shorthand for C/C++, not to describe the problem domain, and it's true that the modern zero-cost-abstraction memory-safe languages that can displace the last of the C/C++ code are very new. We'll be out of the era of C/C++ when a mainstream browser is written in one of them.
    - pixelpoet 7y ago
      As I understand it, Firefox now has substantial parts written in Rust, Mozilla's own language. Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.
      - Cyph0n 7y ago
        From a security standpoint, it really depends on your threat model. But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs. Given the above, writing your code using a memory safe language is still a huge net benefit.
        vardump 7y ago
        > But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs. Not quite sure what you mean. For an application developer, yeah, you don't need to worry. In general... If I had a dime just for all various types of kernel memory read/write vulnerabilities due to kernel bugs and bad drivers, I'd have a lot of dimes.
pjmlp 7y ago
C is deprecated on Windows, where the focus is now C++ and .NET, old style C code has been made compatibile with C89's C++ subset. Even the new Universal C runtime is written in C++ using extern "C". On Android, C is reserved for the Linux kernel and "legacy drivers" (pre-Treble), everything else is C++ and Java/Kotlin. On Apple OSes, C is left for the UNIX style compatibility layer, everything else is a mix of Objective-C, Swift and C++. By the way it is either C or C++, not C/C++.
- DagAgren 7y ago
  VS now ships clang, so that should improve support for C considerably. Objective-C is C, with extensions. Swift interoperates with C, not C++.
  - pjmlp 7y ago
    It ships clang, because that is Microsoft's answer to C support on Windows, for those that still want to use C. Visual C++ focus is naturally C++. C with extensions, by definition, is not C, rather something else. Swift interoperates with Objective-C, thus C interoperability comes for free. IO Kit, DriverKit, Metal Shaders, LLVM make all use of C++.

big_chungus 7y ago

This is true, largely because no one outside the HN bubble knows Rust/Zig/ATS/whatever. Most companies and people want to get stuff done, and a new language can get in the way of that. It'll take a while for those newer languages to pick up main-stream traction, and by a while I mean a few years of pushy college grads who used it in CS 101, 202, or 303.

jupp0r 7y ago
Don’t be so sure about that. I don’t know any C++ dev who hasn’t heard (good things) about Rust. It’s definitely well known in the systems programming community at this point. That’s different from using it in production though.
- alfalfasprout 7y ago
  And that's precisely the point. You don't use C++ because it's the best thing since sliced bread. You use it because you want to easily use decades of optimized libraries and get a result that's highly performant without spending a long time creating wrappers in Rust (that may not even be easy to do w/ libraries that rely on a lot of templating).
  - vardump 7y ago
    A lot of C++ projects (not all!) have relatively few dependencies. I think this "decades of optimized libraries" is a bit hyperbole. Besides, libraries that were optimized for HW 20-30 years ago don't age all that well and are far from optimal these days. They also tend to still have a ton of bugs. Now, I'm not saying there aren't cases where you really need to build on legacy library base. Merely that it's a bit rare case.
    - tsimionescu 7y ago
      Libraries that are 20-30 years old and that people still use today are generally in continuous development over that time period, often with the same team (in a ship-of-Theseus sense). That means that they have been optimized for today's hardware for about 20 years worth of todays. Now there are cases where libraries have ossified and there is room for a new library to come and eat their cake (look at ripgrep for an example), but there are also a lot of cases where they are going to be very hard to beat (a lot of boost is in this area, I believe, and there are many other examples in specialized domains).
      - jupp0r 7y ago
        boost fills more of a role that standard libraries play in other languages (think go).
  - pjmlp 7y ago
    And tooling. Mixed language development experience in Java and .NET IDEs, UI frameworks, game engines and GPGPU shaders.

tptacek 7y ago

If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises aren't compatible, because I am talking about things like Java and Python. In the 1990s and early 2000s, we were still building application code in C/C++.

senderista 7y ago
Hmm, I had in mind the phrase “insecure systems languages”, but I don’t want to get into a boring debate about what “systems languages” or “systems programming” mean...
- tptacek 7y ago
  It's at least as much my fault as yours, since I said "systems language" as a shorthand for C/C++, not to describe the problem domain, and it's true that the modern zero-cost-abstraction memory-safe languages that can displace the last of the C/C++ code are very new. We'll be out of the era of C/C++ when a mainstream browser is written in one of them.
  - pixelpoet 7y ago
    As I understand it, Firefox now has substantial parts written in Rust, Mozilla's own language. Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.
    - Cyph0n 7y ago
      From a security standpoint, it really depends on your threat model. But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs. Given the above, writing your code using a memory safe language is still a huge net benefit.
      - vardump 7y ago
        > But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs. Not quite sure what you mean. For an application developer, yeah, you don't need to worry. In general... If I had a dime just for all various types of kernel memory read/write vulnerabilities due to kernel bugs and bad drivers, I'd have a lot of dimes.

pjmlp 7y ago

C is deprecated on Windows, where the focus is now C++ and .NET, old style C code has been made compatibile with C89's C++ subset. Even the new Universal C runtime is written in C++ using extern "C". On Android, C is reserved for the Linux kernel and "legacy drivers" (pre-Treble), everything else is C++ and Java/Kotlin. On Apple OSes, C is left for the UNIX style compatibility layer, everything else is a mix of Objective-C, Swift and C++. By the way it is either C or C++, not C/C++.

DagAgren 7y ago
VS now ships clang, so that should improve support for C considerably. Objective-C is C, with extensions. Swift interoperates with C, not C++.
- pjmlp 7y ago
  It ships clang, because that is Microsoft's answer to C support on Windows, for those that still want to use C. Visual C++ focus is naturally C++. C with extensions, by definition, is not C, rather something else. Swift interoperates with Objective-C, thus C interoperability comes for free. IO Kit, DriverKit, Metal Shaders, LLVM make all use of C++.