> but for say Nvidia or Apple I would assume the employees would be a good people to take the stock advice from
Isn't Apple pretty famously secretive even internally around stuff like product launches? I would expect a company that runs a tight ship to have rank-and-file employees who would have less potentially actionable info than ones at companies that don't control information as well.
Sure, but eliminating bugs isn't a binary where you either eliminate all of them or it's a useless endeavor. There's a lot of value in eliminating a lot of bugs, even if it's not all of them, and I'd argue that empirically Rust does actually make it easier to avoid quite a large number of bugs that are often found in C code in spite of what you're saying.
To be clear, I'm not saying that I think it would necessarily be a good idea to try to rewrite an existing codebase that a team apparently doesn't trust they actually understand. There are a lot of other factors that would go into deciding to do a rewrite than just "would the new language be a better choice in a vaccuum", and I tend to be somewhat skeptical that rewriting something that's already widely being used will be possible in a way that doesn't end up risking breaking something for existing users. That's pretty different from "the language literally doesn't matter because you can't verify every possible bug on arbitrary hardware" though.
The study they cite seems to be leaving out something: are the participantsforced to make a choice, or could they choose to not take either? If I were presented with the two choices they give, I'd probably take the free one in the first choice but not take either in the second because I just wouldn't care enough to buy the single small piece of chocolate for either price. If I were forced to make a choice, I might pick the Lindt, but I'd argue that then their experiment isn't actually testing the same thing. A forced choice been two things isn't the same as two options that can both be rejected.
Venmo isn't really something I'd consider a "bank service"; it was its own company for a bit, and I think now it's owned by PayPal.
The closest thing here is probably Zelle, but at least with my bank's app, the interface is a bit of a pain. This basically is just another form of what the parent commenter said; how much do I value my own time and convenience compared to what I'd be getting?
> This may be a hot take but I'd be willing to pay my ISP $10 extra that they would distribute to sites I visit, if it meant zero tracking and ads. I use an ad blocker but I genuinely want to support content creators in a way that doesn't optimize for ads or clicks.
The problem is that both the ISP and the websites would then go "Cool, we're getting $10 a month from them!" for about a minute before they started trying to come up with ways to start showing you ads anyways. With the level of customer appreciation ISPs tend to show, I'm sure they'd have no problem ignoring your complaints and would happily revoke your service if you stopped paying the now $10-higher price per month.
> Only being half ironic with this. I generally find that people somehow magically manage to understand how to be materially helpful when the subject is a helpless LLM. Instead of pointing it to a random KB page, they give it context. They then shorten that context. They then interleave context as comments. They provide relevant details. They go out of their way to collect relevant details. Things they somehow don't do for their actual colleagues.
"Self-descriptive code doesn't need comments!" always gets an eye-roll from me
I suspect that's the logical endpoint of trying to provide everything as context to an agent. Why use a separate markdown file and have to waste extra tokens explaining what part of the codebase something applies to when you can just put it right there in the code itself?
The issues is that you should have a work flow that strips the comments before sending the code to production. I'm sure they assumed that minifying it is enough though.
They also weren't supposed to be leaking the code itself either. I don't know enough about JS tooling, but is it possible that this might just be the pre-stripped version?
That’s what a source map is. It’s included in debug builds so that browser debuggers (and others) can step through the original code, comments and all, instead of the compiled javascript (which back in the day could become an undecipherable mess of callbacks if you were transpiling async/await to the legacy Promise API).
Unfortunately in many bundlers making a mistake like this is as easy as an agent deleting “process.env[‘ENV’] === ‘debug’” which they’ll gladly do if you point them at a production or staging environment and ask them to debug the stripped/compiled/minified code.
I see. I had read that it was a source map that was leaked here specifically, but my vague understanding of the term was mostly that it might be a way to trace back JavaScript lines to the TypeScript it compiled from, since I don't have much of an understanding of all of the other various steps that are part of a JavaScript build nowadays.
I think I still disagree with the parent comment premise that "they probably thought minifying was enough", since it sounds likely they were doing all of those other steps. The issue seems like insufficient auditing of the build process (especially if agents were involved, which seems likely for Anthropic) rather than not doing all of the usual JS build stuff.
Last time I took this I ended up with the exact font I already use, and I realized that it was because I was basically picking whichever font was closer to it on each choice. Because I also enforce my fonts of choice on my browser, I guess it's just the only font I've read code in for so many years that it's just "what code should look like" to me.
You seem to be ignoring the "just to save face" part. I'd argue it would be a worse thing for our bar for how safe it should be to be raised significantly from when we had been in space as a species less than a decade to now that it's been 65 years.
Isn't Apple pretty famously secretive even internally around stuff like product launches? I would expect a company that runs a tight ship to have rank-and-file employees who would have less potentially actionable info than ones at companies that don't control information as well.
reply