[rowland66]

That seems completely irrelevant.

[adwn]

> That seems completely irrelevant.

Safety is irrelevant for a payment system?

[otabdeveloper4]

Are there any real examples of exploits of unsafe payment systems that could have been fixed by programming language features?

[adwn]

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]

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/ga...

Slides can be downloaded. I hope the talk recording will be available as well.

[otabdeveloper4]

> 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]

> 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]

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.