Let's at least be clear what happened in the examples of the post. Julia has correctness checking, and it's turned on by default. The only way to turn this kind of stuff off in normal usage is locally, i.e. putting `@inbounds` and such on a block of code. That blog post is about some cases where in some libraries (not even standard libraries really, some statistics libraries), there were people who put `@inbounds` in code to explicitly turn off safeguards but did not do the due diligence to ensure that the code that was unsafed was actually correct.

Note a few things here. One, this is some user deciding to turn off the safeguards, not necessarily Julia being unsafe but instead Julia being flexible and some users abusing that without checking it well. Two, you can run Julia in a way where this feature is disabled: just running `julia --check-bounds=yes` and all `@inbounds` markings are ignored. So in theory this entire blog post could've just been "please run Julia via `julia --check-bounds=yes` and you get better error messages". Note this isn't something that's obscure: literally every time you run `]test` or use package CI it puts things into this mode, so it's used daily by almost all developers. Third, you say you do scientific computing but this post was about statistics libraries.

Look, it's not perfect. What I'm hoping for is that Julia's compiler soon improves its tracking of certain effects like size and uses that to emit code without bounds checking when it proves the code stays inbounds. If that's the case, then `@inbounds` wouldn't be necessary, and this would go away completely. But for now, we have a system when when you need to, you can opt out, and users can explicitly turn off all opt outs with just a single command line argument. I think that's at least a better solution than say MATLAB where indexing out of bounds resizes the array without an error, or indexing out of bounds in Python or R can just wrap around and give you a value without erroring. At least Julia chooses safety by default, and we need to bonk a few people on the head to stop turning off the defaults before checking correctness (in the name of "maor performance", which could soon be replaced by the compiler simply doing this as an optimization and thus further reducing the need for people to do it).

And another change that can be done to Julia here is that all of the features that can be unsafe, like `@inbounds` and `@fastmath`, can be moved to an Unsafe.jl standard library, so that packages have to explicitly import Unsafe.jl and you can check the Project.toml to see if a package uses it. That paired with command line overrides to disable any of these features would give very clear warnings and workarounds for users. What you'll find with this is that there is a very small set of packages using it. And unlike some other languages, Julia makes these unsafe triggers local, so hopefully we can further localize and cage any usage of this to be a very small surface area. To me, that seems like something that is at least solvable, in comparison to other language designs where such unsafe behavior is global to the whole language (I'm looking at you Python, https://moyix.blogspot.com/2022/09/someones-been-messing-wit... bites so hard every time I try something...)