> I love systems which don't prevent foot guns, and go bang spectacularly when I foot gun myself.
Do I need to say anything more?
Do I need to say anything more?
No. Let me re-iterate what I mean.
Systems without guardrails are explicit, transparent and flexible. It's easy to understand how they behave. It might be a little harder to get things right, but when you get it right, there's nothing to second guess.
Systems without guardrails are low in overhead. It's possible to get raw performance.
Yes, I love these systems. I might spend a little more time and need a little more concentration when I develop stuff on these systems, but when it runs, it runs for good.
Trying to make systems foolproof by limiting them is not good. If that's good, we should all love iOS, right?
For a more specifically computer-systems example, perhaps we should consider security? - oh, wait...
Most security problems arise from memory management problems from my experience. This has nothing to do with POSIX. The problem is universal there, and we may delightfully argue that a stricter programming language like Rust can alleviate most problems, however tools like Valgrind can also find a lot of problems during a simple testing run.
If we return to aviation, flight safety and memory management, there are some standards AFAIK which ponder about determinism and memory management on these systems (and smaller "single use" systems). These systems neither know POSIX, nor has the capacity to do so (they spend all their power to catch and tag the object they're tasked with).
Again, the security, reliability and other footgun related stuff ends at the program we're designing and running, and not on POSIX itself.
This just does not hold up at all, in practice. It is not at all uncommon for footguns in software go undetected in testing, and lie in wait, like so many landmines, for someone to set them off - or for some blackhat to find them.
> Most security problems arise from memory management problems from my experience.
That does nothing to somehow compensate for, or otherwise render harmless, those that are not.
More generally, by describing various ways you can seek to avoid footguns, you are simply providing evidence that they are a problem, not a feature.
> when you get it right, there's nothing to second guess
Given the topic is "how to corrupt your db file," does that mean they didn't get it right yet? Or that the underlying platform prevents them from getting it right?
As a person who've developed sizeable projects with both, you hit the nail on the head (and yes, Java can do amazing things in the foot gun department, believe me). However, my favorite language duo is C/C++ at the end of the day.
> Given the topic is "how to corrupt your db file," does that mean they didn't get it right yet?
This means you (as the developer) has a misunderstanding between you and the system. The article contains a very large swath of problems from hard to understand implementations (e.g. locks), to hardware which doesn't listen you to bugs in SQLite itself.
So, in the article there are a lot of cross-platform bad practices which one's warned about. Shrinking this to "POSIX is bad!" is just wrong. This is what I'm trying to point out.