551–560 of 560 posts
Earlier quoted context omitted.
There is nothing that prevents you from recovering from a bad data file load in Rust. The programmer who wrote that code chose to crash.
That's exactly my point. There should be no such thing as choosing to crash if you want reliable software. Choosing to crash is idiomatic in Rust but not in managed languages in which exceptions are the standard way to handle errors.
Earlier quoted context omitted.
I am not a C# guy, but I wrote a lot of Java back in the day, and I can authoritatively tell you that it has so-called "checked exceptions" that the compiler forces you to handle. However, it also has "runtime exceptions" that you are not forced to handle, and they can happen any where and any time. Conceptually, it is the same as error versus panic in Rust. One such runtime exception is the notorious `java.lang.Null…
In practice, programs written in managed languages don't crash in the sense of aborting the entire process. Exceptions are usually caught at the top level (both checked and unchecked) and then logged, usually aborting the whole unit of work. For trapping a bad data load it's as simple as: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file; continuing with old data", e); } Thi…
In the Rust case you just don’t call unwrap() if you want to swallow errors like that.
It’s also false that catching all exceptions is how you end up with reliable software. In highly available architectures (e.g. many containers managed by kubernetes), if you end up in a state where you can’t complete work at all, it’s better to exit the process immediately to quickly get removed from load balancing groups, etc.
General top level exceptions handlers are a huge code smell because catching exceptions you (by definition) didn’t expect is a great way to have corrupted data.
Earlier quoted context omitted.
I think conventionally the verb is "to steelman" with the intended contrast being to a strawman, an intentionally weak argument by analogy to how straw isn't strong but steel is. I understood what you meant by "strongman" but I think that "steelman" is better here. There is indeed a good reason regulators aren't just obliged to institute all recommendations - that would be a lot of new rules. The only accident report…
> it's very difficult to correctly estimate what it will actually cost to change something once you decided it's required - based on current reality where it is not. Mass production and clever cost reductions resulting from the normal commercial pressures tend to drive down costs Difficult, but not impossible. What are calculable and do NOT scale down is cost for compliance documentation and processes. Changing from…
The TSA makes no sense as a safety intervention, it's theatre, it's supposed to look like we're trying hard to solve the problem, not be an attempt to solve the problem, and if there was an accident investigation for 9/11 I can't think why, that's not an accident.
As to your specific claim about enforcement, actually we don't even know whether we'd increase paperwork overhead in many cases. Rationalization driven by new regulation can actually reduce this instead.
For a non-regulatory (at least in the sense that there's no government regulators involved) example consider Let's Encrypt's ACME which was discussed here recently. ACME complies with the "Ten Blessed Methods". But prior to Let's Encrypt the most common processes weren't stricter, or more robust, they were much worse and much more labour intensive. Some of them were prohibited more or less immediately when the "Ten Blessed Methods" were required because they're just obviously unacceptable.
The Proof of Control records from ACME are much better than what had been the usual practice prior yet Let's Encrypt is $0 at point of use and even if we count the actual cost (borne by donations rather than subscribers) it's much cheaper than the prior commercial operators had been for much more value delivered.
Earlier quoted context omitted.
Can't say that when it is a time critical service such as hospitals, banks, financial institutions or air-traffic control services.
Only a fool would build an architecture for critical air-traffic with Cloudflare as a SPoF.
Having no backup / contingency plan even if any third party system goes down on a time critical service means that you want to risk another disaster around the corner.
In those industries, accepting to wait for them for a "day or two" is not only unacceptable, it isn't even an option.
Earlier quoted context omitted.
Probably fired a lot of their best people in the past few years and replaced it with AI. They have a de-facto monopoly, so we'll just accept it and wait patiently until they fix the problem. You know, business as usual in the grift economy.
This didn't happen at all. You're just completely making shit up.
Earlier quoted context omitted.
In practice, programs written in managed languages don't crash in the sense of aborting the entire process. Exceptions are usually caught at the top level (both checked and unchecked) and then logged, usually aborting the whole unit of work. For trapping a bad data load it's as simple as: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file; continuing with old data", e); } Thi…
Look at how much additional boilerplate it took in your example to ignore the error. In the Rust case you just don’t call unwrap() if you want to swallow errors like that. It’s also false that catching all exceptions is how you end up with reliable software. In highly available architectures (e.g. many containers managed by kubernetes), if you end up in a state where you can’t complete work at all, it’s better to exi…
> General top level exceptions handlers are a huge code smell
And yet millions of programs have such things and they work fine. My experience has been that they tend to be more reliable than other programs. E.g. IntelliJ hardly ever tears down the entire process when something goes wrong, it fails gracefully and reports back to HQ whereas other IDEs I've used hard crash quite regularly. Much more disruptive.
Earlier quoted context omitted.
How often do you hear of Akamai going down and they host a LOT more enterprise/high value sites than Cloudflare. There's a reason Cloudflare has been really struggling to get into the traditional enterprise space and it isn't price.
A quick google turned up an Akamai outage in July that took Linode down and two in 2021. At that scale nobody's going to come up smelling like roses. I mostly dealt with Amazon crap at megacorp, but nobody that had to deal with our Akamai stuff had anything kind to say about them as a vendor. At first blush it's getting harder to "defend" use of Cloudflare, but I'll wait until we get some idea of what actually broke.…
Earlier quoted context omitted.
> it's very difficult to correctly estimate what it will actually cost to change something once you decided it's required - based on current reality where it is not. Mass production and clever cost reductions resulting from the normal commercial pressures tend to drive down costs Difficult, but not impossible. What are calculable and do NOT scale down is cost for compliance documentation and processes. Changing from…
I mean, I'm pretty sure there was a long period where you could walk up 5 minutes before, and fly on a plane where you're not allowed to smoke. It's completely unrelated. The TSA makes no sense as a safety intervention, it's theatre, it's supposed to look like we're trying hard to solve the problem, not be an attempt to solve the problem, and if there was an accident investigation for 9/11 I can't think why, that's n…
You provided an example of where arguing against regulation was ill-conceived in hindsight. I offered an obvious example of the opposite (everyone against plane hijacking -> regulation -> air travel is made worse for everyone without much improvement for the primary issue).
> Rationalization driven by new regulation can actually reduce [paperwork] instead.
Ha! Anything is possible, I suppose.
I'd point out that the TBM were not ratified by committee (much less a government) and were rammed through by unilateral Mozilla fiat.
Earlier quoted context omitted.
I mean, I'm pretty sure there was a long period where you could walk up 5 minutes before, and fly on a plane where you're not allowed to smoke. It's completely unrelated. The TSA makes no sense as a safety intervention, it's theatre, it's supposed to look like we're trying hard to solve the problem, not be an attempt to solve the problem, and if there was an accident investigation for 9/11 I can't think why, that's n…
Smoking and TSA are unrelated. You provided an example of where arguing against regulation was ill-conceived in hindsight. I offered an obvious example of the opposite (everyone against plane hijacking -> regulation -> air travel is made worse for everyone without much improvement for the primary issue). > Rationalization driven by new regulation can actually reduce [paperwork] instead. Ha! Anything is possible, I su…
They (I would say deliberately) stalled the process to actually make those rules binding on the CAs and that is where Mozilla used their fiat powers to just require this anyway, knowing that all the other trust stores would come for the ride and actually nobody at CA/B offered a legitimate reason not to do this, they just (again I would say deliberately) allowed it to get procedurally bogged down so that nothing would happen for a period of time.