That is a very interesting and thorough analysis – hopefully the Zig authors are humble enough to consider some of the points.
It is interesting the different thoughts on safety from “Blueberry Wren”:
First, and very much foremost, Zig is not memory safe. This is, in my opinion, the most egregious thing in this post, by a very large margin. Moreso, Zig does not make any attempt to be memory safe - it can catch some things at runtime, with specific allocators, but so can C these days. Indeed, there are some cases, like use-after-realloc, that
asancan catch and Zig cannot.A language in the modern day that does not make an attempt at memory safety is, in my opinion, not reasonable. It has been shown that in some areas, up to 70% of security bugs are due to memory safety issues (Source).
I subscribe to the idea that the user must be constrained. It is perhaps harsh to say, but for large and complex programs, I believe that there are very few programmers who will write memory-correct code nine times out of ten. When writing code with others, that goes down. I personally do not believe I fit into that category.
The fact that Zig allows the user to write faulty software is supported by various somewhat informal, but still useful, statistics. Notably, the following statistic disregard duplicates, and unreported errors. However, general trends are still of note.
Compared with Joran Dirk Greef’s thoughts (see the pledge article a few posts up):
What I learned is that if you could centralize resource allocation in time and space (the dimensions that prove tricky for humans writing software) then this could not only simplify memory management, to design away some of the need for a borrow checker in the first place, but, more importantly, also be a forcing function for propagating good design, to encourage teams to think through the explicit limits or physics of the software (you have no choice).
Finally, while the borrow checker could achieve local memory safety, TigerBeetle needed more correctness properties. TigerBeetle needed to be always correct, and across literally thousands of invariants. As matklad would say, this is a harder problem! I had also spent enough time in memory safe languages to know that local memory safety is no guarantee of local correctness, let alone distributed system correctness. Per systems thinking, I believe that total correctness is a design problem, not a language problem. Language is valuable. But no human language can guarantee the next Hemingway or Nabokov. For this you need philosophy. Even then it’s not a guarantee but a probability.
There are obviously multiple “good” ways to solve problems on computers, and it probably depends a lot on what type of problem you are solving. Go is still my “go-to” general purpose language - it is memory safe, simple, has great tooling, and is easy to deploy on anything. If I needed to be 20% faster, or 10% safer, then these other languages would make sense, but most problems I solve do not have this constraint. My constraint is that I often need to complete it 30% sooner 
.