3 ms·

When is this madness of using unsafe languages for applications that interact with outside systems going to end?

• tdhz77 6y ago
  All languages are unsafe. We find bugs of “safe” languages sometimes 30 years after the exploit was introduced. Just because we don’t know doesn’t make them safe.
  • burundi_coffee 6y ago
    I think it still makes a difference if languages are created with safety in mind.
    • mnd999 6y ago
      It certainly does help but as the parent says it’s not a silver bullet. The lazy unhelpful comment above adds very little to the discussion when the software in question is (in some cases decades) older than those languages.
  • nynx 6y ago
    While that's true, the likelihood of a bug like this existing in an application written in a language like python, go, or rust (heck, even C++) is orders of magnitude less than the likelihood of it being in software written in C.
    • glnz 6y ago
      Why does Python have a safe reputation around here? Everything is constantly rewritten by corporate sponsored developers and it is usually easy to find invalid accesses.
      • nynx 6y ago
        Personally, I dislike python. However, it's indisputably safer than C.
  • geofft 6y ago
    Sometimes kids get badly injured climbing on a tiny playground structure, but we don't say "All climbing is unsafe" and stick toddlers halfway up El Capitan.
  • Ar-Curunir 6y ago
    All languages are unsafe the same way all diseases are fatal.
  • pjmlp 6y ago
    Indeed, however given that 70% of exploits are caused by memory corruption bugs, like in this case, the IT world would be much safer if we only had to deal with the remaing 30%.
• toast0 6y ago
  You would need a dedicated team (starting with a dedicated person), willing to rewrite so much existing C code in a less unsafe language. And they would need to be willing to spend a lot of time on making sure the new implementation was just the same as the old version, and can compile and run on all the same platforms and what not. I don't think it would be easy to get funding for that, so your dedicated team is going to have to be independently wealthy, or not spend a lot of time on it. If rust is your selected less unsafe language, as I understand it, it doesn't have as full platform support as gcc or clang, so that's a challenge (which gets easier over time as non-x86 and non-arm die out). Other languages have other challenges, but I don't think there's a clear winner here, which is part of the issue. The new utilities will be judged on functionality (should be exactly the same), and cpu/memory/binary size which should all be the same or less. It's hard to guarantee that. Not a whole lot of people want to develop with that framework. You don't see a whole lot of Show HN: I made a replica of X, with no changes to functionality. Everyone always wants to change things. Anyway: be the change you want to see and all that. Pick a small package, reimplement it in rust (or whatever), and see if you can get it in distributions or convince the upstream to switch to your implementation. Then tell us how it went, and repeat with another package, etc.
  • tptacek 6y ago
    How about we just start with xterm and go from there?
    • toast0 6y ago
      Not me thanks. Terminals are a lot of weird code (even with a fixed width charcter set)
• ris 6y ago
  We're patiently awaiting your rust-rewrite of xterm. When can we expect the first release?