Ability to verify things like "N comparisons were made during this sort" matters and having to write generic implementations needlessly so I can swap out "test" versions is just mocking but more annoying.

In general the Rust community says that mocking is just bad, that these test patterns are bad, etc. I think it's just totally wrong. I've caught bugs in other languages because I could trivially mock.

In general "user workspace" shouldn't have creds, is basically my point. I guess that's a lot to ask though. But even in AWS, using IAM with roles etc would help a ton to limit impact.

Seems like you should just not be giving access to credentials. I can't think of a reason to do so vs putting the creds behind an API that a tool would call out to. That way the creds (for the tool) are the only ones exposed, and that tool can be locked down in more specific ways.

I mean, do you, not to pile on your replies or anything. It's just incredible to see the "moderate" replies to you still tone policing.

It feels a lot like the "I don't like pancakes" "wow so you hate waffles". You don't have to Be Better, you made an off hand remark where you said a response seemed uneven and people lost their mind and responded with images intended to be shocking. I don't think "be better" is on you here lol

Like (a) it doesn't make sense and won't be effective (b) it isn't happening anyway (c) it has strict security downsides

So why prioritize it over the solutions that are decades old and actually work and have been proven to work? Browsers did this in 2003.

Sandboxing is older than I am, I don't see why it should be something that can't be implemented in the short term. Orgs aren't going to change their patch management on a dime either and delays go against current fed recommendations anyways.

I just don't see the reason to think about the approach.

Also, sandboxing and attestation aren't new. I advocated for mandatory 2FA in crates.io back in 2016. Package signing has never been easier. Sandboxing package managers isn't a new idea either.

I don't think we're in a "do this while we wait" phase here, it's time to just do that work.

I basically think it's all cost, no value. It's also not even possible to implement under some conditions - if a CVE is published for a dependency, I have *no choice* but to patch it if I distribute software to specific orgs + I'm vulnerable for longer to that CVE.

This is actually an incredibly easy problem to solve if you set the time aside and decide it's a priority. The hard work was done a long time ago.

There is 0 need for complex language features like effects to solve it.

I have a prompt for (1) that instructs it to first generate the expected properties of the project from a UX/ semantic point of view, and to write tests that may fail because of mismatches in implementation and UX expectations. Otherwise I find it can write bad tests.

I think maybe people don't understand that investors fundamentally *invest* in future value? Or something? You would never buy a stock based on its current value, you buy it based on the potential value. There's a gap between current and maximum, but that doesn't matter much.

did the same thing for a toy language recently - I had a few restrictions on returning borrows and storing them, but otherwise it was no-gc safety with no borrow checker.

I'll look forward to what you come up with.