4 ms·

"Microsoft and Chromium were telling this for years" The advantages of memory safe languages have been discussed to death in programming circles for many decad

"Microsoft and Chromium were telling this for years" The advantages of memory safe languages have been discussed to death in programming circles for many decades. This is absolutely nothing new, and it should surprise absolutely no one that both industry and government are behind the curve, as usual.

muffles 4y ago
What is the implication of this to embedded software platforms like Xilinx VITIS or TI's Code Composer Studio? Both tools are based on C/C++ so why would these platforms not have switched to C# or Rust earlier? Sorry for the simple question as Im a simple hardware guy but do you see a scenario where future platforms of these tools are based on Rust?
- nicoburns 4y ago
  I think embedded software will likely switch to Rust (or other non-C/C++ languages) eventually. But that transition will be behind the transition for PC/server software by probably 10 years, partly because these indeustries are just slower to change, partly because support for these kind of environments in languages like Rust isn't as mature as support for more "full OS" environments, partly because these environments are often dependent on proprietary compilers provided by vendors and getting these vendors to ship Rust compilers is going to be a slow uphill battle. In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.
  - qsort 4y ago
    Sic rebus stantibus, neither transition is realistic without enormous and painful investments. Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust. Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.
    - nicoburns 4y ago
      > neither transition is realistic without enormous and painful investments I don't disagree, and for that reason the transition will be slow, but I still think it will happen. The benefits are too great to ignore, or they eventually will be. Nobody's going to want to use insecure foundational libraries once secure ones are available. And they're already being written. > Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. For what it's worth, Rust is entirely viable (and arguably easier than C++) in this space right now. It's also using extern C under the hood, but there are libraries like "pyo3" and "jni" which will deal with the unsafety for you and provide you with higher-level bindings. In practice you don't lost much safety using this approach.
    - kaba0 4y ago
      Well, it could be written in Java, so Java-Java communication is trivial, and you could use something like protobuf to communicate between java-python. Or just some fixed binary layout. Or even GraalVM which is polyglot between the two languages and can even optimize across language boundaries.
  - bluGill 4y ago
    Depends, i know one company that spent billions swithicg to memory safe stuff, but after a few years an experienced team did a project in both the memory safe new stuff and in parallel the same in C. The C code was done in a week, the new stuff 3 months. They are back to C for everything and the people pushing memory safety are gone. The right tools mater. The memory safe stuff above was autosar, so not something often discussed here. Rust is getting interest from the above team but after the above burn they are slow to try new things.
    - pencilguin 4y ago
      We may presume the Modern C++ version would have been done even faster, then, and without memory faults.
      - bluGill 4y ago
        The team in question had decades of c experience, and was doing all new stuff (maybe half of all work?) In autosar. I was working with them on an unrelated C++ project and I can assure you the C++ they write was not very good since the only C++ stuff was things they didn't want to do.
        pencilguin 4y ago
        We may presume that, coming in C++, competent modern C++ developers could be found, unlike for immature languages. Building everything performance-critical with immature languages is not a viable alternative. But building with modern C++ is one.
        RealityVoid 4y ago
        I work with AUTOSAR. I am fairly confident that AUTOSAR itself is the problem and not representative of the productivity you would gain from memory safe stuff. I can also say that the AUTOSAR stacks themselves offer no memory guarantee and have seen way too many bugs in those stacks to have any sort of faith in them.
- rightbyte 4y ago
  I don't see how you mix memory safety with DSP programming. You gonna handle interrupts, DMA, cache etc automagically?
sitkack 4y ago
Are you discounting the broad impact having the NSA tell everyone to stop using C/C++? Almost nothing is new information if you dig deep enough. It wasn't new when the CTO of Azure said everyone should stop using C/C++. 5 years ago, there was not broad consensus by technical leaders that C/C++ was even a problem. You just needed the best programmers, throw in some *SAN to rinse all the bugs away and poof!, fast enterprise grade code! Who delivers a message is often times more important than the message itself. The entire message is (person, says, x), I said we should stop using C/C++ 20+ years ago, doesn't make me CTO of Azure or the NSA.
- pencilguin 4y ago
  There is no such language as "C/C++". Using the expression reveals tendentious bias. Those of us using modern C++ do not ship memory usage faults, and have not done for years. So, experience with C and pre-modern C++ does not generalize.
  - throw10920 4y ago
    Do popular compilers ship with an option that forbids the use of all memory-unsafe constructs? If not, then "modern C++" is still not memory-safe.
    - pencilguin 4y ago
      Where there is no need for any unsafe construct, code that therefore does not use them is safe. The same applies to, e.g., Rust: any Rust program may use unsafe blocks. That Rust programs may contain unsafe blocks does not make Rust implicitly unsafe. Even using unsafe blocks does not, by itself, make the program unsafe.
      - throw10920 4y ago
        Your dodging of my question leads me to believe that the answer is "no". Therefore, "modern C++" is still unsafe. > Even using unsafe blocks does not, by itself, make the program unsafe. This is false. "Unsafe" means that there is the potential to cause memory safety bugs. Unsafe blocks and C++ cause this, by definition. "Unsafe" does not mean that a memory safety bug actually exists. Moreover, I didn't mention anything about Rust in my comment.
acdha 4y ago
“Behind the curve” isn’t really the right term. It’s not like anyone was unaware that C has downsides but rather that lots of people said it’d cost too much to replace all of that old code. Things like this are what tell companies that they should stop slacking because it’ll become increasingly common as a buyer’s requirement.

muffles 4y ago

What is the implication of this to embedded software platforms like Xilinx VITIS or TI's Code Composer Studio? Both tools are based on C/C++ so why would these platforms not have switched to C# or Rust earlier? Sorry for the simple question as Im a simple hardware guy but do you see a scenario where future platforms of these tools are based on Rust?

nicoburns 4y ago
I think embedded software will likely switch to Rust (or other non-C/C++ languages) eventually. But that transition will be behind the transition for PC/server software by probably 10 years, partly because these indeustries are just slower to change, partly because support for these kind of environments in languages like Rust isn't as mature as support for more "full OS" environments, partly because these environments are often dependent on proprietary compilers provided by vendors and getting these vendors to ship Rust compilers is going to be a slow uphill battle. In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.
- qsort 4y ago
  Sic rebus stantibus, neither transition is realistic without enormous and painful investments. Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust. Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.
  - nicoburns 4y ago
    > neither transition is realistic without enormous and painful investments I don't disagree, and for that reason the transition will be slow, but I still think it will happen. The benefits are too great to ignore, or they eventually will be. Nobody's going to want to use insecure foundational libraries once secure ones are available. And they're already being written. > Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. For what it's worth, Rust is entirely viable (and arguably easier than C++) in this space right now. It's also using extern C under the hood, but there are libraries like "pyo3" and "jni" which will deal with the unsafety for you and provide you with higher-level bindings. In practice you don't lost much safety using this approach.
  - kaba0 4y ago
    Well, it could be written in Java, so Java-Java communication is trivial, and you could use something like protobuf to communicate between java-python. Or just some fixed binary layout. Or even GraalVM which is polyglot between the two languages and can even optimize across language boundaries.
- bluGill 4y ago
  Depends, i know one company that spent billions swithicg to memory safe stuff, but after a few years an experienced team did a project in both the memory safe new stuff and in parallel the same in C. The C code was done in a week, the new stuff 3 months. They are back to C for everything and the people pushing memory safety are gone. The right tools mater. The memory safe stuff above was autosar, so not something often discussed here. Rust is getting interest from the above team but after the above burn they are slow to try new things.
  - pencilguin 4y ago
    We may presume the Modern C++ version would have been done even faster, then, and without memory faults.
    - bluGill 4y ago
      The team in question had decades of c experience, and was doing all new stuff (maybe half of all work?) In autosar. I was working with them on an unrelated C++ project and I can assure you the C++ they write was not very good since the only C++ stuff was things they didn't want to do.
      - pencilguin 4y ago
        We may presume that, coming in C++, competent modern C++ developers could be found, unlike for immature languages. Building everything performance-critical with immature languages is not a viable alternative. But building with modern C++ is one.
      - RealityVoid 4y ago
        I work with AUTOSAR. I am fairly confident that AUTOSAR itself is the problem and not representative of the productivity you would gain from memory safe stuff. I can also say that the AUTOSAR stacks themselves offer no memory guarantee and have seen way too many bugs in those stacks to have any sort of faith in them.
rightbyte 4y ago
I don't see how you mix memory safety with DSP programming. You gonna handle interrupts, DMA, cache etc automagically?

sitkack 4y ago

Are you discounting the broad impact having the NSA tell everyone to stop using C/C++? Almost nothing is new information if you dig deep enough. It wasn't new when the CTO of Azure said everyone should stop using C/C++. 5 years ago, there was not broad consensus by technical leaders that C/C++ was even a problem. You just needed the best programmers, throw in some *SAN to rinse all the bugs away and poof!, fast enterprise grade code! Who delivers a message is often times more important than the message itself. The entire message is (person, says, x), I said we should stop using C/C++ 20+ years ago, doesn't make me CTO of Azure or the NSA.

pencilguin 4y ago
There is no such language as "C/C++". Using the expression reveals tendentious bias. Those of us using modern C++ do not ship memory usage faults, and have not done for years. So, experience with C and pre-modern C++ does not generalize.
- throw10920 4y ago
  Do popular compilers ship with an option that forbids the use of all memory-unsafe constructs? If not, then "modern C++" is still not memory-safe.
  - pencilguin 4y ago
    Where there is no need for any unsafe construct, code that therefore does not use them is safe. The same applies to, e.g., Rust: any Rust program may use unsafe blocks. That Rust programs may contain unsafe blocks does not make Rust implicitly unsafe. Even using unsafe blocks does not, by itself, make the program unsafe.
    - throw10920 4y ago
      Your dodging of my question leads me to believe that the answer is "no". Therefore, "modern C++" is still unsafe. > Even using unsafe blocks does not, by itself, make the program unsafe. This is false. "Unsafe" means that there is the potential to cause memory safety bugs. Unsafe blocks and C++ cause this, by definition. "Unsafe" does not mean that a memory safety bug actually exists. Moreover, I didn't mention anything about Rust in my comment.

acdha 4y ago

“Behind the curve” isn’t really the right term. It’s not like anyone was unaware that C has downsides but rather that lots of people said it’d cost too much to replace all of that old code. Things like this are what tell companies that they should stop slacking because it’ll become increasingly common as a buyer’s requirement.