4 ms·

It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating s

by wtracy 12y ago

It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!

sixbrx 12y ago
Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.
- wtracy 12y ago
  Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.
kibwen 12y ago
I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.
- mwcampbell 12y ago
  I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.
  - Pacabel 12y ago
    What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening. There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist. C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations. It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.
  - kibwen 12y ago
    We have to be realistic. C is never going away. C++ is never going away. When has any entrenched programming language ever gone away? As someone who has been paid to write code in RPG (https://en.wikipedia.org/wiki/IBM_RPG#Example_code https://en.wikipedia.org/wiki/IBM_RPG#Example_code), I can confirm: never ever, ever ever. The best that we can do is to offer an alternative. The reason why I put so much effort into Rust is because people who need to write the software in this space have literally no alternative that is not unsafe. Even if they cared about safety, they're screwed! Say that they need to write a library that can be written once and called from any language. That means, effectively, that they need to write that library in a language that 1) can expose a C-compatible interface, and 2) can run without a runtime. Which means, practically, that their choices of programming language are either 1) C or 2) C++. Despite Heartbleed, nobody's rushing to rewrite OpenSSL in ML. And I sure hope nobody's rushing to rewrite it in Rust either (we have no idea yet how Rust would fare for crypto, and we need time to figure that out). But once Rust is ready, you will at least have a choice. Memory safety will no longer be something that you leave on the table out of necessity. I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. And yeah, I'm a programmer too, and I dislike many of the languages that I am forced to use every day. But Rust isn't about making programmers happy (although it seems to do that entirely by accident); it's about making users safer. Fewer vulnerabilities, fewer angles of attack for the baddies to exploit. And hey, if it makes software crash less, I guess that's cool too.
    - pjmlp 12y ago
      > We have to be realistic. C is never going away. C++ is never going away. Not in the coming years, but it eventually will become a legacy language like RPG is, confined to old boxes running on long term maintenance contracts. All is needed are a few mainstream OS where those languages are no longer part of the standard SDK. Like for example Microsoft just did with C as of Windows 8. Even their latest C99 compatibility changes were only done as they are required by C++11/14, nothing else. > I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. This was already possible with Lisp, Smaltalk, Mesa/Cedar, Modula-2, back when C was created, but then AT&T had better relationship with universities than Xerox PARC and ETHZ did.

by wtracy 12y ago

sixbrx 12y ago

Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.

wtracy 12y ago
Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.

kibwen 12y ago

I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.

mwcampbell 12y ago
I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.
- Pacabel 12y ago
  What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening. There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist. C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations. It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.
- kibwen 12y ago
  We have to be realistic. C is never going away. C++ is never going away. When has any entrenched programming language ever gone away? As someone who has been paid to write code in RPG (https://en.wikipedia.org/wiki/IBM_RPG#Example_code https://en.wikipedia.org/wiki/IBM_RPG#Example_code), I can confirm: never ever, ever ever. The best that we can do is to offer an alternative. The reason why I put so much effort into Rust is because people who need to write the software in this space have literally no alternative that is not unsafe. Even if they cared about safety, they're screwed! Say that they need to write a library that can be written once and called from any language. That means, effectively, that they need to write that library in a language that 1) can expose a C-compatible interface, and 2) can run without a runtime. Which means, practically, that their choices of programming language are either 1) C or 2) C++. Despite Heartbleed, nobody's rushing to rewrite OpenSSL in ML. And I sure hope nobody's rushing to rewrite it in Rust either (we have no idea yet how Rust would fare for crypto, and we need time to figure that out). But once Rust is ready, you will at least have a choice. Memory safety will no longer be something that you leave on the table out of necessity. I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. And yeah, I'm a programmer too, and I dislike many of the languages that I am forced to use every day. But Rust isn't about making programmers happy (although it seems to do that entirely by accident); it's about making users safer. Fewer vulnerabilities, fewer angles of attack for the baddies to exploit. And hey, if it makes software crash less, I guess that's cool too.
  - pjmlp 12y ago
    > We have to be realistic. C is never going away. C++ is never going away. Not in the coming years, but it eventually will become a legacy language like RPG is, confined to old boxes running on long term maintenance contracts. All is needed are a few mainstream OS where those languages are no longer part of the standard SDK. Like for example Microsoft just did with C as of Windows 8. Even their latest C99 compatibility changes were only done as they are required by C++11/14, nothing else. > I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. This was already possible with Lisp, Smaltalk, Mesa/Cedar, Modula-2, back when C was created, but then AT&T had better relationship with universities than Xerox PARC and ETHZ did.