dwattttt

> 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 now 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.

They didn't special case this (in this way at least). You only need to specify the bounds relevant to this impl at this point.

It doesn't even have to be less constrained than the containing types definition. You can provide an impl with more constraints; for example, a type Q<T: Read + Write>, but impl Seek for Q<T: Read + Seek>

The strings are equally likely if they're being purely randomly selected, but not if they're being selected by people with a poor understanding of random. In the latter case, people are more likely to select HTHTHT.

Sorry, yes. I mean that Drop isn't implemented for all Q<T>, just all Q<T> where T meet the bounds of legally constructing Q. I note the difference because you can write a Drop impl with no bounds on T, and I believe it would not be able to trigger the bug.

Even if the bounds are the same on the struct and the impl, it's still true that placing bounds on the Drop impl means it's not implemented for all T (just all T that also satisfy Q).

You also don't have to place those bounds on the Drop impl just because they're on Q, that's not an error.

This code, from the bug submission?

  impl<T: 'static + Send> Drop for Q<T> {
      fn drop(&mut self) { if let Some(t) = self.0.take() { KEPT.lock().unwrap().push(Box::new(t)); } }
  }

The bound on T in the Drop impl means Drop is not implemented for all T, only where T: 'static + Send. Q<T> also having the same bound doesn't make a difference to the Drop impl.

You're claiming that this bug that reproduces back to Rust 1.4 (2015) is a sign they're adding too many features to make sure they don't introduce bugs? Or do you have bugs that are due to these recent features?

How many of them only conditionally implement Drop, based on a generic param lifetime?