hansvm

IME SMT is approximately useless if your code is any good and you have one obvious source of load (the foreground game, a trading engine, etc). I just reduce thread count to at most the number of physical cores if my software is the dominant workload. How did developers typically work around that xbox deficiency?

Absolutely. That's why I stopped validating passwords and emails. Nobody votes with their wallets anyway, so I don't have to worry about losing customers, and regulations only go after the evil hacker testing whether 1234 might work as a password, not me for choosing not to check its hash against my database. Law-abiding citizens would never try to impersonate one another, so I'm sure fraud on my platform is low.

They have a HN history going back nearly a decade (pre-LLM) with comments mostly not looking like trolling to me. My first guess would be that they've just been exposed to a bad implementation of Pair Programming and TDD (or even a "good" implementation in an environment where it's not a good fit), and that's where they developed those opinions.

TDD especially has a lot of critics. Some of that's justified. Some of it is just a difference in thought methodologies (e.g., a fraction of developers "think" through a problem by writing code, and the "tests" mandated by TDD physically can't meaningfully appear till after some implementation has happened). If a rando developer thinks negatively of it, that's not news to me. If they haven't tried it much and misattribute the exact cause of those negative opinions to be able to form a nice story-centric through-line, that's also not surprising. I'd be much more inclined to believe they're a developer who you disagree with than a deliberate troll. Who knows.

Maybe. That hometown I referenced has 3k people in the city (not farmers) and 12k people in the county outside the city (mostly farmers in varying capacities). It's the only place I've lived where it's common for people to cut, mill, and dry their own lumber for economic reasons, or (ignoring parts of Alaska I've lived in) for hunting to be an economically rational thing to do. There are literally zero vehicle fires. A home or business per year or two burns down, but at the 1/100 vehicle fire rate we expect 3 fires per week, and there are zero in the last decade. It's a hot, dry climate made up of mostly farmers with extremely shoddy equipment.

Anecdotes aren't everything. If there are 1/1k fires annually then those have to come from somewhere, so your "location dependent" idea makes a lot of sense. I'm passionately curious now as to where those fires actually happen though. It's not just farmers with bad equipment in bad scenarios.

What's your method for implementing rigorous testing while using AI?

I'm interested in that rant (at $WORK we adopted hash() for almost everything, and I'm curious to hear other perspectives).

That's the normal legalese loophole. They don't sell or rent your data, but they share it free-of-charge with 10k of their favourite corporate friends who, in a completely unrelated transaction, have sent Tesla money for some reason or another.

I see, we can solve the problem of excess verbosity by duplicating our API surface ;)

Jokes aside, that's not the worst idea (you often see the stdlib do something in a similar vein with managed vs unmanaged data structures), but I bet it doesn't survive contact with real-world programmers well enough to actually provide the portability that normal Zig code has. For transitive "style" impositions, it only takes a low rate of non-compliance for the perceived benefit to disappear.

If that's a goal you have (and IME most code is lightning fast to write, with all the heavy lifting going to impedence mismatches like the one being described, so I tend to be happy to write a bit of extra boilerplate (I like Zig, but it's an absurdly verbose language) if it means the hairier integration points will go more smoothly, and I therefore do have that goal) then the allocator API empirically works, the other solutions I've seen work much less, and I'd want to have a pretty good idea of why a contender would sate my needs instead.

If that's not a goal you have, you do you man. I can shovel out sealed Scala classes or unmaintainable numpy with the best of them as the situation demands. Nobody's created "the best" language yet. We're just casually discussing tradeoffs.

The fires/mile ratio seems like a good idea (skewed a bit by relative driving habits of professional vs typical drivers). It turns out those numbers are all pretty readily available. All miles from all sources (including semis) tally to 3.3T/yr. All car fires from all sources (including crashes, so in the context of semis spontaneously combusting these numbers will make the 1/100 rate look even better than it should be, though separate sources indicate that most car fires aren't from collisions, so that's perhaps a small effect) total to 210k/yr. You then find that, smoothing out all underlying subgroups and data, there's a fire every 15.5M miles.

Applied to residential apartments, there's an average miles per year of 14k or so (should be less here than average based on anecdata, high fuel prices discouraging driving, and everything being close even if you do drive and usually close enough to be walkable, but let's assume 14k/yr is a reasonable baseline), giving us a fire every 1100 vehicles, not every 100.

1/1k is more plausible to me (still "feels" high, but it doesn't trigger the baseline absurdity checks I have in the back of my mind). 1/100 suggests that every year in uni one of my classmates should've had their car burn down. 1/100 suggests that every year my hometown newspaper should report 30 cars burning down -- one every week or two (and given that the newspaper covers the entire county it should actually be 3/week). It's a pretty high rate. The typical person knows hundreds of people well enough that a car fire would often crop up in conversation eventually, and I don't think the typical person knows anyone whose car caught fire. Elaborating on that, I don't think the typical person doesn't know somebody whose car caught fire _ever_, much less in the last year.

That gets into an idea I've been pretty adamant about. People say that capitalism is the worst system except for all the others, but its actual property is that it's inevitable. Money (power) can be used to gain more power. If even a few people choose to do so, if not countered intentionally by some outside force, wealth and power will accumulate.

Whether you see that as good or bad or something which needs to be checked and controlled is a separate discussion, but it's an obvious and expected result.

For some other unscientific findings, that'd suggest 5 vehicle fires per year just from residents of my apartment complex. I've seen 1 in 8 years, and that was arson.

They're orthogonal concepts. Zig hasn't done this, but you could absolutely combine injected allocators and automatic destructors in the same language if you wanted.

The bigger design point is who's responsible for knowing where the object lives. Zig has a balance of power more in favour of the caller than the callee, a point I tend to agree with since it's quite easy for a caller to know exactly what they want done and quite hard for a callee to know what all possible callers might want done. That principle is applied pretty liberally through the rest of the language.

Allocators help solve the problem of "this code I want to use is almost good enough; how do I actually use it?"

I distinctly remember one of my first "real" jobs, somebody had written a C# library for GraphQL. It had some sort of bug or lack of functionality I had to fix. The author had fallen hook, line, and sinker for sealed classes and all that nonsense, so the shortest path to using the rest of their code was to fork the library and re-write the thousand offending lines and all references thereto. Luckily it wasn't a deep dependency.

Contrast that with similar issues in typical Python. The library likely accepts my favourite duck-typed solution, if it doesn't then I can likely work around it with an appropriate choice of dunder methods in the code I have interacting with the library, and if it still doesn't yield then I can just rewrite (monkey-patch) the offending code at runtime.

Not that either of those scenarios are objectively optimal, but they illustrate one of the principles people have in mind when they use an interface like allocators (not the only one, I'm sure other commentors will talk your ear off), that when push comes to shove you'd prefer to be able to use your existing code to solve your new problems. And that does empirically mostly work here; you can use nearly the entire Zig stdlib (especially when ignoring things like the posix namespace) and most of the rest of the ecosystem as well on embedded devices, in WASM, in bounded-memory applications, in generic application code, in fast-running CLI apps not even bothering to free, etc.

I agree with much of your discussion about arenas by the way. They're a moderately poor fit for the current interface in Zig, largely because the free functionality is questionable at best. IME, most uses of arenas actually know they need such a thing. Functions taking allocator arguments and expecting the allocator to be an arena should take an arena argument. When using arenas for lifetime management, something should probably own that arena rather than implicitly assuming whatever gets passed through the stack is correct. Passing arenas to arbitrary functions expecting general-purpose allocators is prone to leaks, and you'd be better off using the arena (or a buffer created therefrom) as a backing allocator for a data structure capable of actually freeing if you can't trust the implementation you're calling into (and if you can trust it, they should expose a better API allowing you to detect that trustability at the callsite).

That doesn't sound right. Previous results proved that with bounded values you couldn't beat O(nlogn), among other things. The OpenAI result explicitly used arbitrary-precision complex arithmetic. Yes, it's galactic [0], but either it's wrong or the previous results were wrong, no?

[0] Very much not something I care much about in these sorts of conversations. Even if it weren't galactic, a random logn factor here and there usually loses to cache efficiency and whatnot. Their speedups were less than that, and I'd already assumed we were in the realm of applied math rather than real engineering.