5 ms·

That seems completely irrelevant.

• adwn 6y ago
  > That seems completely irrelevant. Safety is irrelevant for a payment system?
  • otabdeveloper4 6y ago
    Are there any real examples of exploits of unsafe payment systems that could have been fixed by programming language features?
    • adwn 6y ago
      That's the wrong question to ask. The right questions are: 1) Are there any real examples of software exploits that could have been fixed by programming language features? 2) Is there an incentive to exploit software bugs in a payment system? To which the answers are 1) almost too many to count, and 2) yes, definitely.
      • dbrgn 6y ago
        Here's a recent USENIX talk on the topic of memory unsafety and the choice of programming languages: https://www.usenix.org/conference/enigma2021/presentation/gaynor https://www.usenix.org/conference/enigma2021/presentation/ga... Slides can be downloaded. I hope the talk recording will be available as well.
        • otabdeveloper4 6y ago
          > memory unsafety Memory unsafety is just one class of safety bugs, and a relatively unimportant one. As far as payment processors go, I'd be much more worried about concurrency bugs.
          • adwn 6y ago
            > Memory unsafety is just one class of safety bugs, and a relatively unimportant one. Wrong. Memory unsafety, in its various forms, is the primary source of exploits in software written in C. > I'd be much more worried about concurrency bugs Another thing which is hard to do in C, and so much easier in some more modern programming languages (particularly in Rust).
    • bokohut 6y ago
      There are those of us with extensive experience in payments with plenty of stories that would touch exactly on this, so yes, but these stories are not public information.