8 ms·

> No, software written in C is and will continue to be replaced by software written in modern memory safe languages; the trend is strong and growing, to the poi

> No, software written in C is and will continue to be replaced by software written in modern memory safe languages; the trend is strong and growing, to the point where we tend to look askance at (1) new software written in C and (2) popular software written in C that doesn't need to be written in C. When will we get an ANSI standard for one of these new fangled languages? Go is captive to Google, and Rust is more akin to C++ than C -- neither have an actual standard with competing compilers. Until that changes, I think plenty of new software will be written in C, especially freestanding and embedded software.

AnimalMuppet 7y ago
> Rust is more akin to C++ than C -- neither have an actual standard with competing compilers. C++ doesn't have an actual standard? Are you sure about that?
- merlincorey 7y ago
  Rust and Go is what I was referring to in that case -- sorry for the confusion. Yes both C and C++ have standards, and I consider that to be a good thing, though apparently tptacek says I shouldn't care.
  - AnimalMuppet 7y ago
    Ah, I see. My error.
tptacek 7y ago
Rust will displace C in embedded applications, and Mozilla will gradually POC out its displacement in browser software as well. Swift is and will continue to displace C/ObjC in client application software on Apple platforms. Java is displacing C on other mobile platforms. Go is already displacing C in serverside software. And, of course, languages like Python have overwhelmingly replaced most of what C used to be used for in conventional CRUD applications. C is on the way out. It's not gone, but it's going. There will not be a revitalization of the language. It'll be good to know, because some things (OS kernels and device drivers) will continue to be written in C for the foreseeable future. But that's a very small niche relative to the industry as a whole. Nobody cares, and nobody should care, about ANSI standards.
- nsajko 7y ago
  Why would you use Rust on embedded hardware? Seems like C is a better match for embedded considering it has no borrow checker to complicate things, and the borrow checker is less useful when you do not have a heap.
  - tptacek 7y ago
    Because Rust is memory-safe and C isn't. I agree that C is easier to write on embedded platforms and kind of enjoy writing that kind of code myself. But shipping a product requires more than just writing the code; it also entails all the verification work you have to do after the code is working to keep the product in the market, and the verification burdens on embedded software are only going to increase as people generally get more clueful about security. Memory-safe languages will (if they aren't already) be a less expensive way to get a product to market.
    - gmueckl 7y ago
      Protip: look at the tooling requirements for safety critical software (aviation, automotive, industrial, medical...). Nobody is going to allow you to use tools that are not certified for these use cases. Certification of compilers, static checkers etc. Is a huge undertaking that only a few commercial vendors perform on their offerings. Open source is out because nobody even attempts yo run them through that process. What you are left with is highly priced toolchains for Ada, C or C++. The cheapest offerings I know start at high four figures per developer. Validating a new toolchain would likely be to the tune of high 6 up to 7 figures. Don't hold your breath.
      - tptacek 7y ago
        I've done professional validation work in automotive, industrial (and utilities), and medical (I'm a low-level C vulnerability researcher and have been since 1995), and believe you are simply wrong. There are, no doubt, a number of niche systems that require specific toolchains. There are, in our fallen world, systems that require Ada or even particular variants of C. If you want to tell me that aviation flight control systems are such a niche, I will believe you --- I've never had to assess one. But it is not the case that industrial computing or medical device software are locked into memory-unsafe languages due to industry-wide certificational requirements; in fact, that's something I know not to be true from specific experience. And virtually all of the embedded systems I've had to assess over the years would have benefited, commercially, from a memory-safe implementation language.
nsajko 7y ago
Go has a battle-tested specification and multiple implementations.
- arcticbull 7y ago
  There's llgo [1] too, which in my opinion is how Go should have been developed in the first place, instead of on the decrepit plan 9 toolchain, but hey, at least we have it haha. [1] https://github.com/llvm-mirror/llgo https://github.com/llvm-mirror/llgo

AnimalMuppet 7y ago

> Rust is more akin to C++ than C -- neither have an actual standard with competing compilers. C++ doesn't have an actual standard? Are you sure about that?

merlincorey 7y ago
Rust and Go is what I was referring to in that case -- sorry for the confusion. Yes both C and C++ have standards, and I consider that to be a good thing, though apparently tptacek says I shouldn't care.
- AnimalMuppet 7y ago
  Ah, I see. My error.

tptacek 7y ago

Rust will displace C in embedded applications, and Mozilla will gradually POC out its displacement in browser software as well. Swift is and will continue to displace C/ObjC in client application software on Apple platforms. Java is displacing C on other mobile platforms. Go is already displacing C in serverside software. And, of course, languages like Python have overwhelmingly replaced most of what C used to be used for in conventional CRUD applications. C is on the way out. It's not gone, but it's going. There will not be a revitalization of the language. It'll be good to know, because some things (OS kernels and device drivers) will continue to be written in C for the foreseeable future. But that's a very small niche relative to the industry as a whole. Nobody cares, and nobody should care, about ANSI standards.

nsajko 7y ago
Why would you use Rust on embedded hardware? Seems like C is a better match for embedded considering it has no borrow checker to complicate things, and the borrow checker is less useful when you do not have a heap.
- tptacek 7y ago
  Because Rust is memory-safe and C isn't. I agree that C is easier to write on embedded platforms and kind of enjoy writing that kind of code myself. But shipping a product requires more than just writing the code; it also entails all the verification work you have to do after the code is working to keep the product in the market, and the verification burdens on embedded software are only going to increase as people generally get more clueful about security. Memory-safe languages will (if they aren't already) be a less expensive way to get a product to market.
  - gmueckl 7y ago
    Protip: look at the tooling requirements for safety critical software (aviation, automotive, industrial, medical...). Nobody is going to allow you to use tools that are not certified for these use cases. Certification of compilers, static checkers etc. Is a huge undertaking that only a few commercial vendors perform on their offerings. Open source is out because nobody even attempts yo run them through that process. What you are left with is highly priced toolchains for Ada, C or C++. The cheapest offerings I know start at high four figures per developer. Validating a new toolchain would likely be to the tune of high 6 up to 7 figures. Don't hold your breath.
    - tptacek 7y ago
      I've done professional validation work in automotive, industrial (and utilities), and medical (I'm a low-level C vulnerability researcher and have been since 1995), and believe you are simply wrong. There are, no doubt, a number of niche systems that require specific toolchains. There are, in our fallen world, systems that require Ada or even particular variants of C. If you want to tell me that aviation flight control systems are such a niche, I will believe you --- I've never had to assess one. But it is not the case that industrial computing or medical device software are locked into memory-unsafe languages due to industry-wide certificational requirements; in fact, that's something I know not to be true from specific experience. And virtually all of the embedded systems I've had to assess over the years would have benefited, commercially, from a memory-safe implementation language.

nsajko 7y ago

Go has a battle-tested specification and multiple implementations.

arcticbull 7y ago
There's llgo [1] too, which in my opinion is how Go should have been developed in the first place, instead of on the decrepit plan 9 toolchain, but hey, at least we have it haha. [1] https://github.com/llvm-mirror/llgo https://github.com/llvm-mirror/llgo