If the only reason you didn't behave that way to begin with is that you lack the money and power to evade the consequences, then yes. You really are that person.
Yes, that's exactly my point — they're holding on to what is arguably a tiny kernel of truth, and blowing it way out of proportion. And, to be clear, "zealot" isn't meant as a compliment.
And yes, coreutils is a great example of what I mean. The GNU project was always meant to be the basis for a production grade operating system. I mean, GNU Hello is just a hello world program, and its source weighs in at 707kB zipped (or 3.6MB unzipped). The purpose is having a trivial application that can serve as reference for all the standard practices of the GNU Project. No amount of writing things in Rust can replace the engineering mentality that leads to GNU Hello existing. In comparison, as I understand it uutils was first and foremost an educational project that got coopted into being used in production. Things are very much not alike here.
I think we're in violent agreement, because when I said "all else being equal", I really meant all else.
If a language's mental model doesn't mesh well with yours, that's in and of itself an ever-flowing fountain of bugs, and a legitimate reason not to use it. This isn't a valid excuse to not give unfamiliar languages an earnest try, but does justify different people reaching different conclusions afterwards.
The single most important part of the mental model for programming in Excel is precisely that it takes people who tell themselves they could never be programmers, and tricks them into believing they aren't really programming, so they're "allowed" to do it by themselves. It's an incredibly empowering piece of tech. Rust and Zig and Haskell and all the other languages that excite me personally can never hold a candle to that.
> Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it.
Zealots are a problem in every community, sadly. Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead. The zealots just don’t understand (or acknowledge) how “all else being equal” does all the heavy lifting.
As somebody who’s fascinated by programming languages in general, I’m quite keen on Zig. I prefer Rust, and disagree with a bunch of things Zig does, but admire the language for trying.
The conversation amounts to “You should fuzz your code” “we’re already fuzzing the big external dependency, using their own fuzzing setup that they already use upstream”.
It’s not nothing, but clearly not what Andrew meant.
In the photography world, there's a similar story around the colour you get from straight-out-of-camera jpegs.
Unless you shoot Fuji (where their absolutely incredible film emulation engine is one of the big differentiators), most serious-ish photographers shoot raw rather than jpeg, and do their own processing after, so the sooc jpeg look is largely irrelevant.
I would argue the outcome of setting up a perverse incentive structure and failing to hire QA is pretty damn predictable, so that's entirely consistent with what I said :)
On a more serious note, I'm not saying "just make programmers liable for the code they write", and leave it at that. I'm saying that, when you sell a piece of software, someone needs to sign-off on that software being fit for purpose. It's that someone who's ultimately liable. Absent some explicit firebreak, that sign-off implicitly happens with the CTO or CEO.
Funny you used the word "developer", and I used the word "engineer", because that distinction is critical. A brick layer is not a civil engineer, and is not signing off on a construction project. Likewise, the developers banging out tickets don't have to be software engineers who sign off on a software project.
In the Horizon case, I'm thinking of people like Gareth Jenkins. He was the guy who designed the system, and also one of the expert witnesses you mentioned. He's the one who should be held to the standards I'm talking about.
Zig build scripts are arbitrary zig programs, so sandboxing those scripts is a Good Thing. Wasm might be overkill, but using something off-the-shelf that's specifically designed for sandboxing untrusted code is definitely the right approach.
The defining feature of engineering as a profession isn't how much we collectively know about it, it's the attitude we bring into day-to-day practice.
Take something like the Sony BMG rootkit scandal[0]. Anybody with an ounce of sense and even basic technical programming knowledge could tell the sort of security issues that that piece of software could lead to. Shipping that thing was the sort of recklessness that would get you stricken from any industry's professional body.
Or maybe something like the UK's Post Office scandal[1]. One of the issues there was that post offices sold foreign currency. People were accused of (and actually jailed for) fraud because their branch sold $100, there's £70 in the till, and the reconciliation process says that the exchange rate is $100:£80, so there's £10 missing. Horizon had no way to track that the exchange rate at the time of the transaction was $100:£70, they literally shipped a billing system that handles ForEx but doesn't understand exchange rates change over time. And then they lied about it and said the software was working correctly! This isn't an issue with "revolutionary new tech" that we don't fully understand, it's simply a fruit of having an accounting system designed with no actual accountants in the loop. If an accountant had made this exact same mistake, their licence would almost certainly be revoked, but it's somehow ok because computers are involved?
> If so, then maybe we can talk about getting bureaucrats involved to make up a bunch of rules and regulations to control everybody
We don't need "a bunch" of rules and regulations. We only need one: You're liable for damages resulting from reasonably predictable outcomes, as judged by a panel of your peers.
Kind of, but not really — Channels are FIFOs, and there's approximately zero work happening inside. Factorio belts can have insertions/removals at arbitrary points along the belt (including players grabbing stuff off the belt whenever they choose), and require simulating movement of items along the belt. They also come in much more complex topologies than Go channels ever do in practice.
That one will never cease to impress me. Belts are basically the “Turing complete” of parallelism — I expect that every single data dependency pattern imaginable can be expressed as belts.
It makes perfect sense — what separates Will from Ben and Matt is that they’re willing to acknowledge the difference exists. They’re willing to say “we have this, but we don’t have that”.
> I thought a wicket is what you call an out? Now it’s something else, too?
It's a metonym.
The actual wicket is the wooden things the bowler is trying to hit. Because hitting the wicket eliminates the batter, the word is also used colloquially to refer to an out.
Down by six is literally that — they were six runs (points) behind. Six is a "magic" number, because that's what you score for knocking the ball out of the park (so the cricket equivalent to hitting a home run).
Yup, batter runs towards the bowler (and the "inactive" batter runs the opposite direction).
In baseball terms, a cricket run is more or less equivalent to running a single base (the bowler is 22 yards away from the batter, which is more than the distance from the pitcher's mound to the home plate, but less than the distance from home to first base). Just like you can run multiple bases in baseball, you can do multiple runs in cricket. From a scoring point of view, you're effectively scoring how many bases you ran, so a baseball run is roughly equivalent to four cricket runs.
Scoring 100+ runs is called "a century", and it's pretty impressive, but, because you keep batting until the bowling team sends you out, you can just keep scoring all day long if you have the endurance for it. Baseball doesn't have a mechanism for a single batter to hit multiple back-to-back home runs.
A cricket pitch is a long strip. Bowler bowls from one end, batter strikes the bowl from the other. Scoring is done by running from one end of that strip to the other (the unit of scoring is literally called a run). Six legal bowls make an over.
There are two batters in play at each point in time, one at each end of the pitch, and they both must run towards the other end of the pitch (therefore swapping places) to score.
Bruce Edgar had scored 102 runs, was not out (in the same sense as baseball — meaning he was still in play), but, because they either didn’t manage to score any runs, or scored twos, he spent the whole over on the non-striking side of the pitch.
> The main problem is USB-C's bandwidth complexity - especially when paired with the Realtek RTL8159 Ethernet controller, which requires USB 3.2 Gen 2x2 (20 Gbps) to get the full rated 10 Gbps speeds
Jeff's statement wasn't that 10 Gb/s Ethernet requires 2x2. It's that that requirement comes from a very specific controller.