5 ms·

Complication without benefit.

jhatemyjob 5y ago
Rust's popularity is pure mimesis. C is fine, but it's not the hot new tech, you can't get a cool job writing C because it's "unsafe", so now we have Rust. And Swift.
- woodruffw 5y ago
  I don't think this is what you should take away from this post. Rust makes me very productive as a programmer, and reduces the "long tail" of debugging that I do when I write C and C++ (which I have for over a decade). (And, for what it's worth, there are plenty of "cool jobs" writing C/C++. I have one!)
- pdimitar 5y ago
  Very curious to hear your take on OpenSSL's Heartbleed bug and would you avoid it if you were the maintainer.
  - infamouscow 5y ago
    Other classes of bugs will take the place of memory safety bugs. For example, I don't think the recent Log4j exploit is a memory safety bug, but could be wrong.
    - zbentley 5y ago
      Without weighing in on Rust specifically, that's a fallacy, though I'm unsure of the formal name of it: "any solution that doesn't solve all problems is equivalent to the status quo". Nobody is claiming all bugs will go away. But the claim that new classes of bugs will manifest specifically to take the place of memory safety bugs is extraordinary and needs justification. It's a bit like going into the wilderness and packing survival gear: the argument "you don't need a warm jacket, because if you get lost the starvation will kill you even if the frostbite doesn't" doesn't hold up.
      - jhatemyjob 5y ago
        When you use simple metaphors to describe complicated politics in software development, that's when you lost the argument
    - pdimitar 5y ago
      Until that day we should make sure to eliminate the class of bugs that's #1 in all security problems -- namely buffer [over|under]flows. I'd be happy to hear this statistic has shifted towards the next #1 problem. But we're not there yet.
    - woodruffw 5y ago
      The problem is behavioral scope: bugs will always exist, but there is no particular reason for a buffer overflow to allow someone to run arbitrary code on my computer. It should, at the absolute worst, cause an uncontrolled program termination.
  - rastignack 5y ago
    Very curious to hear your suggestion on a native rust library with openssl’s functionality. Hint: there is none.
    - pdimitar 5y ago
      Not on topic though, not sure why you're bringing it up. The topic was: "C is fine". No, it really isn't.
      - rastignack 5y ago
        You picked as an example a library without any safe alternative in rust. Used by a whole lot of rust projects dealing with tls. It’s ironic.
        pdimitar 5y ago
        You call a "gradual migration path strategy" ironic? You do you, I suppose.
        rastignack 5y ago
        I call it a slow development pace caused by usability issues.
- pjmlp 5y ago
  C is not fine, otherwise we wouldn't be getting all hardware vendors adopting hardware memory tagging as the ultimate mitigation solution. However that doesn't mean Rust is the only answer, there are plenty of memory safe languages to chose from.
- adamnemecek 5y ago
  Do you think that the reason say Amazon is writing firecracker in Rust is because they just use whatever language is popular in HN and not because it's a good choice?
  - ncmncm 5y ago
    Yes? Firecracker could be equally well done in many languages. It happened that the people assigned it at the time wanted production Rust experience, and were senior enough to be allowed to, despite the predictable risk of staffing difficulty after some other language steals away Rust's hipster cred. (Which one will, in time, as sure as seasons turn.) It is a common experience for systems written in the a fad language to end up being re-implemented in a language easier to hire for. E.g. I see remarks on HN about this being a principal driver of Erlang hiring, lately.
    - adamnemecek 5y ago
      Which other languages besides C/C++ were viable?
      - ncmncm 5y ago
        C/C++ is not a language. I expect Firecracker could be done about as well in Rust, C++, Haskell, Java, Ada, or Typescript; or even in Common Lisp, C, or Assembly language.
        adamnemecek 5y ago
        Could or it would be a good idea?
        ncmncm 5y ago
        Meaning, was it a good idea to have implemented Firecracker at all? Every choice taken has consequences. Different choices have different consequences. Avoiding a choice has consequences. Linux is (still) coded all in C. It is a terrible choice, but it works well enough to keep a billion phones and a billion websites operating. Language isn't fate.

Rust's popularity is pure mimesis. C is fine, but it's not the hot new tech, you can't get a cool job writing C because it's "unsafe", so now we have Rust. And Swift.

woodruffw 5y ago
I don't think this is what you should take away from this post. Rust makes me very productive as a programmer, and reduces the "long tail" of debugging that I do when I write C and C++ (which I have for over a decade). (And, for what it's worth, there are plenty of "cool jobs" writing C/C++. I have one!)
pdimitar 5y ago
Very curious to hear your take on OpenSSL's Heartbleed bug and would you avoid it if you were the maintainer.
- infamouscow 5y ago
  Other classes of bugs will take the place of memory safety bugs. For example, I don't think the recent Log4j exploit is a memory safety bug, but could be wrong.
  - zbentley 5y ago
    Without weighing in on Rust specifically, that's a fallacy, though I'm unsure of the formal name of it: "any solution that doesn't solve all problems is equivalent to the status quo". Nobody is claiming all bugs will go away. But the claim that new classes of bugs will manifest specifically to take the place of memory safety bugs is extraordinary and needs justification. It's a bit like going into the wilderness and packing survival gear: the argument "you don't need a warm jacket, because if you get lost the starvation will kill you even if the frostbite doesn't" doesn't hold up.
    - jhatemyjob 5y ago
      When you use simple metaphors to describe complicated politics in software development, that's when you lost the argument
  - pdimitar 5y ago
    Until that day we should make sure to eliminate the class of bugs that's #1 in all security problems -- namely buffer [over|under]flows. I'd be happy to hear this statistic has shifted towards the next #1 problem. But we're not there yet.
  - woodruffw 5y ago
    The problem is behavioral scope: bugs will always exist, but there is no particular reason for a buffer overflow to allow someone to run arbitrary code on my computer. It should, at the absolute worst, cause an uncontrolled program termination.
- rastignack 5y ago
  Very curious to hear your suggestion on a native rust library with openssl’s functionality. Hint: there is none.
  - pdimitar 5y ago
    Not on topic though, not sure why you're bringing it up. The topic was: "C is fine". No, it really isn't.
    - rastignack 5y ago
      You picked as an example a library without any safe alternative in rust. Used by a whole lot of rust projects dealing with tls. It’s ironic.
      - pdimitar 5y ago
        You call a "gradual migration path strategy" ironic? You do you, I suppose.
        rastignack 5y ago
        I call it a slow development pace caused by usability issues.
pjmlp 5y ago
C is not fine, otherwise we wouldn't be getting all hardware vendors adopting hardware memory tagging as the ultimate mitigation solution. However that doesn't mean Rust is the only answer, there are plenty of memory safe languages to chose from.
adamnemecek 5y ago
Do you think that the reason say Amazon is writing firecracker in Rust is because they just use whatever language is popular in HN and not because it's a good choice?
- ncmncm 5y ago
  Yes? Firecracker could be equally well done in many languages. It happened that the people assigned it at the time wanted production Rust experience, and were senior enough to be allowed to, despite the predictable risk of staffing difficulty after some other language steals away Rust's hipster cred. (Which one will, in time, as sure as seasons turn.) It is a common experience for systems written in the a fad language to end up being re-implemented in a language easier to hire for. E.g. I see remarks on HN about this being a principal driver of Erlang hiring, lately.
  - adamnemecek 5y ago
    Which other languages besides C/C++ were viable?
    - ncmncm 5y ago
      C/C++ is not a language. I expect Firecracker could be done about as well in Rust, C++, Haskell, Java, Ada, or Typescript; or even in Common Lisp, C, or Assembly language.
      - adamnemecek 5y ago
        Could or it would be a good idea?
        ncmncm 5y ago
        Meaning, was it a good idea to have implemented Firecracker at all? Every choice taken has consequences. Different choices have different consequences. Avoiding a choice has consequences. Linux is (still) coded all in C. It is a terrible choice, but it works well enough to keep a billion phones and a billion websites operating. Language isn't fate.