5 ms·

>We need to move forward to Rust That's the second time in two days I've come to read offensive ranting about a language + "let's move to Rust" as the proposed

>We need to move forward to Rust That's the second time in two days I've come to read offensive ranting about a language + "let's move to Rust" as the proposed silver bullet solution here on HN. If this is the way the Rust community tries to evangelize their language I'm inclined to keep myself as far away as possible from it. Now don't get me wrong: I think Rust is fine. But that "C/C++ is dumb and everyone who continues to use it is also dumb and/or ignorant" sentiment won't win you any friends. There are valid reasons why people keep using C++ and can't switch to any other language in the near future.

steveklabnik 11y ago
"C and C++ is dumb and everyone who continues to use it is also dumb and/or ignorant" certainly isn't the position of the Rust team nor the general Rust community at large.
- klodolph 11y ago
  It's not even the position expressed in the parent comment.
  - steveklabnik 11y ago
    It is how my original parent perceived it, and perceptions matter. I wouldn't work on Rust if I didn't think it was important and a step forward, but even technologies with flaws (read: all of them, Rust has flaws too) are worth using, depending on your situation. Trade-offs are the heart of engineering.
    - klodolph 11y ago
      Perceptions matter, but language choice is a very personal issue and I've noticed that people can get very defensive when they perceive attacks on their language of choice (such as C++) or support for a language they hate (such as PHP). We should continue to talk about language choice because it's important, and we should avoid getting into pissing matches when we do it. I'm convinced that in order to make this work, we have to be more generous in how we perceive other people's comments.
      - nickpsecurity 11y ago
        I agree. I have an example. I'm an opponent of both C and C++ who goes so far as to call them garbage. In some ways, I throw them in the same camp. However, C++ supporters consistently argued that it was a vast improvement over C even in safety and most C-like problems in came from "using C++ like C." It took a while but a few eventually supported that position with specific evidence (example below) that made me adopt their position. Not to mention same empirical studies I cite showed C++ apps having less defects than C apps. https://news.ycombinator.com/item?id=10208786 https://news.ycombinator.com/item?id=10208786 So, there's an example where I had to step back, assume other person has intelligent reasons, and let the person show them with good results coming out of it. I still have a use of "C/C++" in these discussions but now do it less often due to superior safety over C of modern C++ development. New standards mean I'll probably be hit with a similar conversation again lol.
devit 11y ago
It's because Rust is the first production language that is safe and strictly better than C (and that is likely to be strictly better than C++ as well once it gains some missing features). For decades, it has been known that C and C++ are bad languages due to their unsafety, and the use of C/C++ is probably the top cause of bugs and security holes in software; however, switching required giving up performance or features. Now that finally a solution to this problem has become available after so much time, it's natural that people are enthusiastic about it.
- nickpsecurity 11y ago
  That was Ada and a bunch of Wirth languages which both got regular updates going back decades. Most developers ignored all of them. Rust is a new one going mainstream. As usual, mainstream acts like everything else ever happened. An exception is other one, Go, which intentionally copies Wirth's languages in design. Usually stuff is ignored, though.
  - kibwen 11y ago
    > As usual, mainstream acts like everything else ever > happened. Not Rust. The reference has a long list of languages which have been influential (https://doc.rust-lang.org/reference.html#appendix:-influences https://doc.rust-lang.org/reference.html#appendix:-influence...) and the official book has a list of research papers which have helped to guide the design of the language (http://doc.rust-lang.org/book/academic-research.html http://doc.rust-lang.org/book/academic-research.html).
    - nickpsecurity 11y ago
      I meant the commenter as the example of mainstream audience that acts like other things didn't do it first. Wasn't sure what Rust's official position was. Thanks for link as I'll keep it in mind for future discussions. :) Note: Strange that they draw no inspiration from Ada despite it countering many issues by design. I figure at least its tactics if not syntax would be a nice start on a new language. Least they borrowed from and built on a lot of good ones, though.
klodolph 11y ago
I don't see how this is offensive. It is well established that most programmers will produce defects at a relatively high rate when writing C or C++. Rust "or something like it" does effectively eliminate certain categories of defects. Java evangelists have been claiming the same thing since the late 90s, and they were right... buffer overflows in Java programs have most commonly occurred in parts of the Java library written in C, and Java has given us productivity + quality gains in various fields (mostly server-side web applications). Nobody's saying that C/C++ or its users are dumb and/or ignorant. The cost of switching languages is high, and Rust is not very mature.
- ArkyBeagle 11y ago
  Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. If you have to write 'C', learn 'C'. I'd say the same of C++, but by the time you learn it, it's become something different :)
  - pcwalton 11y ago
    > Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. OK, but the fact remains that undefined behavior due to bounds checks is orders of magnitude less frequent in, say, Ruby than in C. I have a hard time seeing this as anything other than a good result.
    - ArkyBeagle 11y ago
      I can't argue with that at all. I'm just saying if you're stuck using 'C', it's worth learning the strategies and habits needed to prevent unsafe code. There are issues other than safety that influence these decisions. Rust & Lua are also closer to 'C' than is Ruby, so ....
  - klodolph 11y ago
    Array bounds errors are a common source of problems in C. Fixing these errors with behavioral changes is expensive. It increases the amount of training and increases the cognitive load on programmers, and yet errors will still slip by because we are imperfect. On the other hand, if I add bounds checking to my programming language, then I've just transformed serious vulnerabilities into simple runtime errors. Computers are easier to reprogram than brains are.
kibwen 11y ago
It's a mental leap to equate random commentators on HN with any community in particular. :P You're also mischaracterizing Animats' comments as "offensive ranting". That's John Nagle (this guy: https://en.wikipedia.org/wiki/Nagle's_algorithm https://en.wikipedia.org/wiki/Nagle's_algorithm) and he knows his way around C.
nickpsecurity 11y ago
"But that "C/C++ is dumb and everyone who continues to use it is also dumb and/or ignorant" sentiment won't win you any friends." Friends are a social, not technical, matter. Far as C, using it outside of necessity (eg legacy or critical libraries) is dumb for projects aiming for robustness. It's not even opinion so much as empirically-backed fact: every study the military and researchers did on C vs other programmers back in the day showed the C people had highest defect rate and among lowest productivity [often due to debugging]. Many were an investigation into Ada vs other languages w/ Ada cutting defects in half not being uncommon. Later Java studies showed same problems with C and benefits by ditching it albeit with much higher overhead. ;) The CVE's continue to reflect the same with Java and Ada being interesting as many of their apps flaws occurred when they leveraged a C library. Like Ada's style or not, it kept defects and overhead low by systematically [1] looking at where problems happened and implementing solutions to them at language/compiler level. Modula-2 did the same thing to a lesser degree. I believe PL/S, a systems variant of PL/1, also had design choices that boosted safety partly inherited from PL/1. Burrough's ALGOL (esp NEWP) did quite a bit in language to reduce risks. These were used in reliable software ranging from mainframe OS's to desktops to embedded. They also predate the C++ language which also attempted to solve C's issues albeit with great C compatibility. So, there are numerous languages whose coders can build robust software at a similar or better pace to C coders building buggy software. These languages, and their descendants, have been around for a while with tool support. The apps built with them are more reliable & had fewer coding vulnerabilities. Clearly, C is just badly designed in terms of robustness, productivity, and maintenance. No secret why: its lineage dumped most of the features of better languages to run on hardware [2] that couldn't support them with acceptable efficiency. Over time, we ditched that hardware for a series of others better suited to our needs. It runs so fast that the CPU is often idle 70-90+% of the time our apps are running. We should likewise ditch C and raw efficiency for something better, safer, and still efficient. Rust is a promising option among others. Note: One trick in the past where the GUI, a legacy library, etc absolutely needed C or C++ was to split the app. Ada, particularly, made cross-language design easier to support this use case. So, the critical part of the logic might be written in a safer langauge, less critical in C or C++, and a careful interface glue them together. This was done for Mondex Certificate Authority, IIRC. I did it myself in numerous designs for fault-isolation or security reasons. [1] http://www.adacore.com/knowledge/technical-papers/safe-secure/ http://www.adacore.com/knowledge/technical-papers/safe-secur... [2] https://en.wikipedia.org/wiki/PDP-11 https://en.wikipedia.org/wiki/PDP-11

steveklabnik 11y ago

"C and C++ is dumb and everyone who continues to use it is also dumb and/or ignorant" certainly isn't the position of the Rust team nor the general Rust community at large.

klodolph 11y ago
It's not even the position expressed in the parent comment.
- steveklabnik 11y ago
  It is how my original parent perceived it, and perceptions matter. I wouldn't work on Rust if I didn't think it was important and a step forward, but even technologies with flaws (read: all of them, Rust has flaws too) are worth using, depending on your situation. Trade-offs are the heart of engineering.
  - klodolph 11y ago
    Perceptions matter, but language choice is a very personal issue and I've noticed that people can get very defensive when they perceive attacks on their language of choice (such as C++) or support for a language they hate (such as PHP). We should continue to talk about language choice because it's important, and we should avoid getting into pissing matches when we do it. I'm convinced that in order to make this work, we have to be more generous in how we perceive other people's comments.
    - nickpsecurity 11y ago
      I agree. I have an example. I'm an opponent of both C and C++ who goes so far as to call them garbage. In some ways, I throw them in the same camp. However, C++ supporters consistently argued that it was a vast improvement over C even in safety and most C-like problems in came from "using C++ like C." It took a while but a few eventually supported that position with specific evidence (example below) that made me adopt their position. Not to mention same empirical studies I cite showed C++ apps having less defects than C apps. https://news.ycombinator.com/item?id=10208786 https://news.ycombinator.com/item?id=10208786 So, there's an example where I had to step back, assume other person has intelligent reasons, and let the person show them with good results coming out of it. I still have a use of "C/C++" in these discussions but now do it less often due to superior safety over C of modern C++ development. New standards mean I'll probably be hit with a similar conversation again lol.

devit 11y ago

It's because Rust is the first production language that is safe and strictly better than C (and that is likely to be strictly better than C++ as well once it gains some missing features). For decades, it has been known that C and C++ are bad languages due to their unsafety, and the use of C/C++ is probably the top cause of bugs and security holes in software; however, switching required giving up performance or features. Now that finally a solution to this problem has become available after so much time, it's natural that people are enthusiastic about it.

nickpsecurity 11y ago
That was Ada and a bunch of Wirth languages which both got regular updates going back decades. Most developers ignored all of them. Rust is a new one going mainstream. As usual, mainstream acts like everything else ever happened. An exception is other one, Go, which intentionally copies Wirth's languages in design. Usually stuff is ignored, though.
- kibwen 11y ago
  > As usual, mainstream acts like everything else ever > happened. Not Rust. The reference has a long list of languages which have been influential (https://doc.rust-lang.org/reference.html#appendix:-influences https://doc.rust-lang.org/reference.html#appendix:-influence...) and the official book has a list of research papers which have helped to guide the design of the language (http://doc.rust-lang.org/book/academic-research.html http://doc.rust-lang.org/book/academic-research.html).
  - nickpsecurity 11y ago
    I meant the commenter as the example of mainstream audience that acts like other things didn't do it first. Wasn't sure what Rust's official position was. Thanks for link as I'll keep it in mind for future discussions. :) Note: Strange that they draw no inspiration from Ada despite it countering many issues by design. I figure at least its tactics if not syntax would be a nice start on a new language. Least they borrowed from and built on a lot of good ones, though.

klodolph 11y ago

I don't see how this is offensive. It is well established that most programmers will produce defects at a relatively high rate when writing C or C++. Rust "or something like it" does effectively eliminate certain categories of defects. Java evangelists have been claiming the same thing since the late 90s, and they were right... buffer overflows in Java programs have most commonly occurred in parts of the Java library written in C, and Java has given us productivity + quality gains in various fields (mostly server-side web applications). Nobody's saying that C/C++ or its users are dumb and/or ignorant. The cost of switching languages is high, and Rust is not very mature.

ArkyBeagle 11y ago
Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. If you have to write 'C', learn 'C'. I'd say the same of C++, but by the time you learn it, it's become something different :)
- pcwalton 11y ago
  > Using a language to solve a practices problem is the same with any other attempt to use technology to correct behavior. It's not completely unjustified, but don't expect good results. OK, but the fact remains that undefined behavior due to bounds checks is orders of magnitude less frequent in, say, Ruby than in C. I have a hard time seeing this as anything other than a good result.
  - ArkyBeagle 11y ago
    I can't argue with that at all. I'm just saying if you're stuck using 'C', it's worth learning the strategies and habits needed to prevent unsafe code. There are issues other than safety that influence these decisions. Rust & Lua are also closer to 'C' than is Ruby, so ....
- klodolph 11y ago
  Array bounds errors are a common source of problems in C. Fixing these errors with behavioral changes is expensive. It increases the amount of training and increases the cognitive load on programmers, and yet errors will still slip by because we are imperfect. On the other hand, if I add bounds checking to my programming language, then I've just transformed serious vulnerabilities into simple runtime errors. Computers are easier to reprogram than brains are.

kibwen 11y ago

It's a mental leap to equate random commentators on HN with any community in particular. :P You're also mischaracterizing Animats' comments as "offensive ranting". That's John Nagle (this guy: https://en.wikipedia.org/wiki/Nagle's_algorithm https://en.wikipedia.org/wiki/Nagle's_algorithm) and he knows his way around C.

nickpsecurity 11y ago

"But that "C/C++ is dumb and everyone who continues to use it is also dumb and/or ignorant" sentiment won't win you any friends." Friends are a social, not technical, matter. Far as C, using it outside of necessity (eg legacy or critical libraries) is dumb for projects aiming for robustness. It's not even opinion so much as empirically-backed fact: every study the military and researchers did on C vs other programmers back in the day showed the C people had highest defect rate and among lowest productivity [often due to debugging]. Many were an investigation into Ada vs other languages w/ Ada cutting defects in half not being uncommon. Later Java studies showed same problems with C and benefits by ditching it albeit with much higher overhead. ;) The CVE's continue to reflect the same with Java and Ada being interesting as many of their apps flaws occurred when they leveraged a C library. Like Ada's style or not, it kept defects and overhead low by systematically [1] looking at where problems happened and implementing solutions to them at language/compiler level. Modula-2 did the same thing to a lesser degree. I believe PL/S, a systems variant of PL/1, also had design choices that boosted safety partly inherited from PL/1. Burrough's ALGOL (esp NEWP) did quite a bit in language to reduce risks. These were used in reliable software ranging from mainframe OS's to desktops to embedded. They also predate the C++ language which also attempted to solve C's issues albeit with great C compatibility. So, there are numerous languages whose coders can build robust software at a similar or better pace to C coders building buggy software. These languages, and their descendants, have been around for a while with tool support. The apps built with them are more reliable & had fewer coding vulnerabilities. Clearly, C is just badly designed in terms of robustness, productivity, and maintenance. No secret why: its lineage dumped most of the features of better languages to run on hardware [2] that couldn't support them with acceptable efficiency. Over time, we ditched that hardware for a series of others better suited to our needs. It runs so fast that the CPU is often idle 70-90+% of the time our apps are running. We should likewise ditch C and raw efficiency for something better, safer, and still efficient. Rust is a promising option among others. Note: One trick in the past where the GUI, a legacy library, etc absolutely needed C or C++ was to split the app. Ada, particularly, made cross-language design easier to support this use case. So, the critical part of the logic might be written in a safer langauge, less critical in C or C++, and a careful interface glue them together. This was done for Mondex Certificate Authority, IIRC. I did it myself in numerous designs for fault-isolation or security reasons. [1] http://www.adacore.com/knowledge/technical-papers/safe-secure/ http://www.adacore.com/knowledge/technical-papers/safe-secur... [2] https://en.wikipedia.org/wiki/PDP-11 https://en.wikipedia.org/wiki/PDP-11