Rust was ~70% of my last job, and the other Rust engineers there were very competent -- large volumes of high-quality, high-impact code. In my rust community interactions at the time, also interactions with my colleagues, I definitely noticed some unsavory trends. An example pattern is:
me> This [API | language feature | whatever] seems harder to use than it should be.
them> No, it's actually not.
me> Here's irrefutable proof.
them> Well at least you have memory safety.
me> But...you can have memory safety without this thing being a dumpster fire. Wouldn't that be better?
them> <no concessions, Rust is perfect>
After a few conversations like that, I've literally had those same otherwise high-caliber engineers spend days wrestling with the "easy" thing we were quibbling about. I'm sure it's not intentional, but it comes across as religious gaslighting.
And maybe I just interacted with the wrong people at the wrong point in Rust's lifecycle and the community is mostly very positive. I see enough people with experiences like mine though that I'm not willing to believe it's a truly miniscule fraction of the language's discourse.
Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.
Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.
Every time I've rewritten a major project I've made it smaller and faster while fixing all the major bugs and most of the minor ones. My current team has had similar experiences. I'd be curious to see what a Zig -> Zig rewrite of the same magnitude would have done for quality.
Not just beeping. I had a rental Nissan recently violently pull me straight off the road when it couldn't read the lines very well in a thick fog. Apparently you can disable that deep in some settings menu through some magic button presses divorced from the main settings menus, but it was frightening. For most manufacturers, almost none of this tech is good enough to even make optional and non-default, much less legislatively mandated, and that supposes I trust you not to sell my daily mood or whatever bullshit to data brokers.
I remember an engineer I talked to recently saying that OSM didn't have sufficiently up-to-date data for their routing use case -- new roads, closed roads, traffic data, etc. Is that the case?
That makes sense to me. There's a causal link between ambient air CO2 levels and cognitive changes, but the air in front of your face, which you breathe, doesn't play a role...
A lack of direct study might make "in front of your face" numbers harder to interpret in absolutes, but relatively speaking I do think that's the number which matters more. Whole-room analysis is just a proxy for the air in front of your face.
Sure, it's changing, and I use AI a ton. The second I ask it (where "it" is a smattering of all the SOTA models and harnesses) to do something as simple as design a server capable of doing <moderately simple task> when any concurrent data structures are involved and the single-server load is in the 100k QPS range, even with extremely thorough plans of how concurrency needs to be managed, it doesn't matter how little code is actually needed or how easy it would be for my juniors to bang out the problem, especially with a little AI boost, AI just can't keep up by itself yet. It can sometimes spit out something close, but only with major correctness issues.
I'm not trying to be argumentative; You posed an idea, and it looked wrong in an important way, so I added my observations. I'd love if you could share the model/harness/workflow you use that makes you so confident in this tooling, because I don't want to be left behind.
And who can't code its way out of a wet paper bag on hard problems. It's more productive for the day-to-day BS, which is convenient because it creates more day-to-day BS you need to handle, but that isn't the reason I hire a staff engineer.
Whatever we're moving toward, I currently can't let any SOTA model + harness operate on more than ~10k changed SLOC at once, and even then only with very careful prompting I thoroughly understand, only on the simplest of problems, and only if I pause it at key points to correct some sort of nonsense thinking and put in a significant cleanup pass and am still willing to tolerate some bullshit. Tooling is impressive for sure, but it's not magic.
You could even just have straight proportional voting if you wanted, and that's be better than the current system. You got 3 votes? Great, you have a 3/100M chance to win.
And that mistruth appears in delightfully insidious ways, like seemingly well-meaning comments opening up about "half" the job being lying when the point is to shift the Overton window away from the actual numbers, whatever they might be.
(obviously not serious, but it's fun to probe what we can actually reason about when every message might be adversarial)
It shows up easily at a macro level of you look at total "innovations" for a society (and have a good way to measure that -- currently still in an "I know it when I see it" stage). It won't usually show up in individual researchers. A few will absolutely be insanely productive with real innovations, but unless you're proposing only hiring that small cast of individuals then you're back to the problem of distinguishing good scientific ideas and methods which just didn't pan out from other forms of actual laziness and fraud given that in both cases you see no meaningful output from the researcher in question.
Batching order, as you mentioned, matters a lot, and for any heavily optimized kernels it will change from one machine to the next. You also have the choice of backend numerical library from, e.g., different OS versions. There are floating-point bugs from time to time, especially in GPUs. Many operations (like transcendentals) are usually given a couple bits of wiggle room in the result. Another program executing could have changed the floating-point rounding mode on one device. More aggressive ML optimizers might automatically apply various forms of reduced precision to the requested high-level operation. If you have enough optimizations enabled, you might non-deterministically get compiled instructions like fmadd so that any one build of your library is deterministic (excluding other ideas mentioned above) but different machines with different builds (because of a staged rollout, different architectures, engineering mistakes, etc) can have different outputs. And so on.
Many good students don't produce such artifacts. That's one of the big problems in academia -- a smart person with good ideas can inadvertently pursue a less promising path and not produce ground-breaking research, so how do you tease that apart from somebody scamming the system? The current approach is to measure unrelated bullshit like citation metrics. I'd hate to see those sorts of perverse incentives pushed down into the student body as well.
I'm all for handwritten tests, but it's more complicated than that. If you're actually writing for 2hr+ and haven't studied appropriate technique or bought some sort of crutch like a pencil holder then the repetitive motion will absolutely cause cramps for a fraction of the class regardless of being 20ish and healthy, and they might not find that out until they're forced to write for 2hr. The muscles manipulating a pencil (with poor technique) are much smaller than those manipulating a post hole digger, so that comparison isn't fair.
If you're doing a good job, you have to do that anyway, or at least have enough of a spidey sense for broken code to know when to investigate and add an extra test case.
Something like 30% of the time at $WORK, interviewers report the candidate as having solved the problem when a closer inspection reveals UB, memory corruption, and other bullshit. The test cases pass, and I think that's part of the problem. You can't tune out and avoid deeply understanding the submission.
My initial implementation used [9][9]u9 (which desugars to [9][9]u16 with some zero bits) and was a fair bit slower. If I had to guess, it's because the shift/extract/align you're describing isn't actually a part of the core solving algorithm, and when you have box constraints, knights-move constraints, etc, you're usually not doing anything which fits in a single u16.
me> This [API | language feature | whatever] seems harder to use than it should be.
them> No, it's actually not.
me> Here's irrefutable proof.
them> Well at least you have memory safety.
me> But...you can have memory safety without this thing being a dumpster fire. Wouldn't that be better?
them> <no concessions, Rust is perfect>
After a few conversations like that, I've literally had those same otherwise high-caliber engineers spend days wrestling with the "easy" thing we were quibbling about. I'm sure it's not intentional, but it comes across as religious gaslighting.
And maybe I just interacted with the wrong people at the wrong point in Rust's lifecycle and the community is mostly very positive. I see enough people with experiences like mine though that I'm not willing to believe it's a truly miniscule fraction of the language's discourse.