dwattttt

I dunno, all those arguments work both ways. They're both called screws as well, they have a functional interface that's the same on both, they were all changes that broke backwards compatibility in the service of improving their purpose, and if you got a product that includes "screws" you don't know which one you're getting.

I don't know the history of knives and hammers, but screwdrivers _have_ evolved, in backwards incompatible ways.

Slot screws date back to the ~15th century, Phillips to the 1930s, and Torx to the 60s. They all brought improvements.

The TPS production/consumption stats disagree, they're up 300% just this quarter. Can't argue with results

Tesla do this if they know they're navigating to a charger.

> HF hadn't yet been pantsed by an agent swarm

It's not that long ago that sites were pantsed by bored college students, rather than agents. It didn't stop because sites got more secure really, it stopped because those students started getting real life consequences.

Gives you a real easy solution to stop the agents too.

I mean removing undefined behaviour from signed overflow isn't the problem. The problem is that when a programmer previously wrote a signed operation that could overflow, they didn't specify what behaviour they really needed.

You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.

The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.

Defining the behaviour for overflow in the language doesn't suddenly mean the behaviour is what every program wanted. Fine that it has a defined result, but if that result isn't what you meant when you wrote a+b it's still a bug.

At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.

> Imagine that the whole city has to install iron doors and window grilles, because wooden doors and glass windows are not safe enough anymore.

> That's a lot of work, but is it productive in the end? Probably not.

Your imaginary scenario defines the solution to be pointless. If that same city was subjected to weekly riots smashing windows & doors, and people regularly died, stopping "productive" work to install things that keep people alive and productive? That's productive.

How big is that gap? It was published publically in the last week.

Sure. But the heuristic the TaaS world is using isn't something as absurd as "allocates 3 pages", it's "uses undocumented system APIs". We're also not arguing in the abstract that "they might make a stupid determination in the future", they're making this determination now.

I'm not a fan of the the security industry's practices, but I can't say they're making a malicious/stupid choice here.

"standard normal" isn't the same as "normal"; standard normal defines the mean & variance (0 & 1 respectively), but normal distributions can have any mean & variance.

You need a measure of variance to perform that kind of estimate. There's scenarios where 98% of results land within 3-5% of a value, and the 14% is extremely unlikely. And scenarios where the variance is high, and it's much more likely. (you can also be wrong about what you think the variance is)

Because you want someone who trusts that different piece of software to use yours.

Zig's decision here means the problem is _yours_ to convince this third party to trust you.

From the link:

> > Won't this get flagged by anti-virus scanners as suspicious?

> Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve.

I am suddenly less interested in relying on Zig.

If you make it easy for lots of people to make the fuel, yes. EVs and smaller scale power generation anyone?

> A lot of testing and verification was avoided in the past because it wasn’t considered nearly as valuable as shipping code.

AI is changing how the code is written, but I'm not seeing anything at all changing the incentives around testing and verification.

This is the same highly verifiable domain that has delivered reliable, bug-free software to date?

And LLMs won't take the easy way out (like so many people) and suppress errors, change tests etc, tweak code until warnings go away?

I can't tell what you're saying; are you saying that "yearly revenue from fares is big", even when someone says "fares aren't the major revenue source, and sometimes doesn't even exceed the cost to implement"?

The Gnorp Apologue (https://www.reddit.com/r/rust/comments/18ul125/writing_a_gam...) has done pretty well.

> Rust is not a production language

Your argument was that the only Rust projects there are are little developer tools, so Rust isn't a production language. When pointed out there are large projects that every day users rely on that use Rust, and not just in corners of the codebase, code that's exercised by approximately all users, you insist it's still not production?

You.. doubt that people use Firefox, Chrome, Windows, or Android? That it must be "attention" that's the reason those projects have Rust in them now?

Rust is in use in more places than you may expect. Does the hypothetical grandma use Windows' kernel? Android? Firefox? Chrome?

> Apple's ecosystem depends on every middle-class person around the globe

I have terrible news about the distribution of iPhones and the middle class globally.

Fair? No, not at all. Even eminent domain specifies that the seizure be for public use, and the owner be fairly compensated.

You don't. Or less snarky, I imagine you'd have to use macros to generate wrapper functions, in order to generate a new function of a user provided type.

An INT 3 isn't even always one byte; there's a one byte encoding, but I believe it's also legal to issue a two byte encoded INT N, where N is 3.

Agreed, and just to make it shorter and clearer; when you resume a debugger, it resumes at that next address. If it's outside a basic block, it's because in the absence of a debug break, it was about to go off the rails anyway, nothing to do with the break.

I'm not sure what your point is. A collection of samples were taken from humans, and they did not form a uniform distribution. Samples from an unbiased RNG are much closer to uniform.

Are you saying we should ignore the distribution we observe from humans and predict them as uniform anyway?

Only if you can hold the debt until someone is willing to pay the price you're asking to make it profitable.

It looks like you're right, my memory is wrong re. trait bounds. My guess then is that it only works for lifetimes because they involve subtyping, and impl Drop for all T means that it's valid for more constrained lifetimes.

That said I was wrong earlier.