Because we batch, this naturally separates the control plane from the data plane, amortizing assertions against the (larger) buffers now flowing through the data plane.
We do also have some intensive online verification checks, and these are gated behind a comptime flag.
Finally, we compile Zig with ReleaseSafe and further have all Zig’s own assertions enabled. For example, checked arithmetic for bounds overflow, which is not something you see enabled by default in safe builds for most languages, but which is critically important for safety.
The reason why all this is so important, is because if your program does something wrong in production, with people’s money, you want to know about it immediately and shutdown safely.
In other words, production is where you most need the safety, not in development (although you obviously want them there too to find bugs faster). But again, it’s the bugs that make it to production that we’re trying to catch with assertions.
> I'm going to proceed with XYZ in N days. If any of you fucking idiots have a problem with that, then scrawl it down in crayon and flush it down the jacks, which is where you'll end up if you dare question my decisions in future.
English is not my first language and I have communication issues. Having said that you may be onto something unironically. Respectful conversations often pack more tensions than downright disrespectful approaches, such as the way "cabron" can be used affectionately in a group of Spanish friends.
In that case, the most likely mismatch between the language you provided and the responses you're getting is your use of the word "considering".
If you're using it to describe the state of mind you'll be in after you fail to receive a reply, that was a mistake. It is a common connective in English that explains the reason for something:
What this means is that the sentence "I will go ahead with changing X, considering you don't think it's important" is equivalent to "I've noticed that you don't think X is important, so I'm not looking for your input on my proposed change".
Learning a language well is a double-edged sword - if you look like you know what you're saying, and you make a mistake, people will assume you meant what you said. You can get away with really outrageous things if you come off as someone who can barely talk. But long after that point, there will still always be things that you never quite learned.
The issue with `considering you don't deem it to be important` is that the statement presumes a particular attitude for the recipient which may or may not be true.
Maybe they were sick for a couple days. Or were recently on vacation (and you haven't been notified yet). Or dealing with some higher priority emergency. Or just genuinely missed the email for some reason (accidentally sent to spam folder?)
Also even if it is true that the recipient thinks it is unimportant, it doesn't follow that the thing should be done. If somebody sends me an email asking me whether they should swallow bubblegum (or something on that level of trivial stupidity), I'd think they shouldn't -- but probably wouldn't bother to respond, or at least I wouldn't write a lengthy email explaining why not.
I'm not even joking, these days I often scroll through social media with a mild kind of twisted amusement watching people do and believe in stupid things -- while I can reply to each of them explaining why they're wrong, it's a well-known fallacy due to xkcd386. Coworkers are admittedly "closer" and thus I probably should warn them about potential hazards, but if it's a large org and I was just among a long list of cc-ed people... I might decide not to bother.
I think people need to appreciate that the number of developers interested in actually helping with free software maintenance is a subset of the number of developers. And when it comes to Python in particular, that subset is proportionally very small. That's just my anecdotal experience of similar projects in both ecosystems.
Python has been around for a long time and there were some attempts at creating a modern package manager for it. If it were feasible to create uv in Python, it would have probably happened by now.
There's a barrier of entry for the army of people who use Python but are not (and often have no interest in being) engineers/developers/programmers.
This is the modern equivalent of building key components in Visual C++ for use by Visual Basic people; it kept the unwashed masses away from things they could break.
I think that this is probably the only way you're ever going to fix the horrific experience of using Python in anger. Which is a good thing, Python's a great little language which is let down by being built on sand.
