> Every piece of code you write is security-sensitive.

No, not every application is CRUD, not every application is interactive and no, not every application serves users and communicate with outside world in a way allowing to be abused during its lifetime.

This doesn't mean it gives me the freedom to write reckless code all over, but the security model of an authentication module and a mathematical simulation is vastly different.

> there is no way that truly safe C++ can be written at any product-scale.

I agree to disagree here, because of my own experience.

Like every other job in the world has a concept of liability,that will eventually arrive on computing world at scale.

The assumptions you make are almost palpable at this point.

Simulation precision and accuracy already carries tons of liability.

Talking like I or we don’t care about consequences is disturbing, esp. with the experience you have.

Well your responses look like you don't care, as if you had any clue about my experience as well, unless the sightseeing from that high altitude cloud is giving mirages.

Any cybersecurity law that requires citzens votes for adoption, will certainly get my signature.

If running static analyzers, testing for memory leaks, running end to end tests which takes days, adding strong bounds checking, and failing fast and with great noise as soon as something does not look right is not caring, you’re right. I don’t care.

All this is done for a code which has no network access, no kernel level work, even doesn’t accept any input after parsing the input model and making sure that it’s well formed with no loose ends.

Imagine what I’d do if it does any kind of authentication or user affecting work.

Call me surprised. OK, fair enough.

During my PhD I wrote a lot of simulation code in Matlab. This code was only ever run by me on my personal machine for the purpose of generating plots for my thesis. How is that security-sensitive?

We all agree that security is important and a lot of code running in security-sensitive contexts is bad. That's very different from saying that all code is security-sensitive.

Matlab is memory-safe, though, which is the kind of safety issue we talk about.

> Matlab is memory-safe, though

Who sold you that notion?

Matlab is proprietary glue holding together modules written in Fortran, C, C++, Java that allows the adhoc inclusion of DLLS put together by graduate students on the fly.

In what universe is any of that "memory safe"?

AFAIK it used to be written/interpreted in Java (though it uses a JIT compiler nowadays, doesn’t it?), and in that sense the language itself is memory safe. Of course if you link to a dependency written in an unsafe language you can have memory issues, but that is not what people commonly mean by “a memory safe language”.

> Of course if you link to a dependency written in an unsafe language

Like the matrix handling, plotting, and other modules dragged in from the 1990s standard FORTRAN library era.

Don't get me wrong, I have placed a lot of trust in those kinds of numeric libraries since the 1980s - NIST and other national labs code and review to a high standard - but they weren't then and aren't now "memory safe" just very probably and mostly bug free.

Unless they were, say, rewritten in Java .. and that's a whole other big ball of issues .. translated code.

I'm happy to play along and agree that the JIT compiled 'Matlab language' parts of Matlab are memory safe - but to the best of my experience with past versions that's just the glue portions - the reason so many people use Matlab is for the chunks that get glued together.

Aren’t many of these Fortran libraries heavily used all throughout almost any kind of application, somewhere deep down their dependency tree?

Absolutely .. and generally written to a very high standard with a lot of checking, rechecking and running forwards and backwards across multiple architectures with extensive technical mailing lists.

They can still have bugs, memory issues, be called with parameters that cause resource blow outs and aren't "memory safe" in the sense that modern managed languages are.

Matlab is exactly as reliable as well written Fortran and C code can be.