MartinodF

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

If you're referring to Apple Silicon, my intuition is that the SoC design allows for higher bandwidth between SSD and RAM which reduces the performance impact of paging. I might be totally wrong though

100% also our experience. We have an internal CLI which has grown to almost half a million lines of Go, mostly contributed to by first-time gophers (and agents nowadays), and with relatively little work spent on making sure the core entities and interfaces encourage doing the right thing, the entire codebase is still surprisingly readable and free of unexpected behaviors.

I'm also fairly certain I read a "helsp" instead of "helps" somewhere in the post

Say you have some code that does a request to an HTTP/1 dependency, and if it get an error response, just closes the connection without reading the response body.

Go 1.26 in practice never re-used that connection, it always established a new one because you can't reuse a connection which has a pending response ready to be read.

Go 1.27 will now consume the body for you, causing your application to re-use connections much more aggressively, bringing in potential edge cases (e.g. dependency is broken, connection is now permanently unusable, your app no longer recovers automatically).

To be clear, I'm very glad for the change and I had equivalent code in our in-house framework to do just that, but yeah it does change the behavior in a way that it could expose undetected issues.

Which is almost guaranteed to be the case for a large org, considering everyone will want auto complete and PR reviews, but on average most will not be making a ton of agent use

We do a lot of request signing (think AWS sigv4a) which practically speaking amounts to 1-request.

This is a pet peeve of mine and I'm glad to see it called out. That said, I haven't seen a comprehensive discussion of "here's the different factors that we think contribute to creating lift" for the general public, is anyone aware of a good source?

Yes, I am in a hybrid role, went through 5 interviews and several more check-ins, and the first time anyone saw me in person was on the first day when I picked up my laptop at the local office (which wasn't even required, I had the option of having it shipped at my home address)

I'm also 37. Two younger colleagues were complaining this week that something like `os.MkDir(..., 0755)` is extremely confusing and that they don't like and can't make sense of octal file permissions. I felt really old :)

Yeah but is it safe for concurrent use?

First of all, thank you for creating this app. A couple of years ago you've finally put an end to my decade of looking for a decent HN client for Android and I haven't looked back. I actually run Harmonic in Windows Subsystem for Android and on ChromeOS to use it as my primary way of browsing HN on all devices!

That said, if you have any spare time to dedicate to it, it would be great if you could open some issues on GitHub to express what you have been wanting to do but didn't manage to. I don't have any gripes with the app as-is (other than adding Material You support, but that's likely to require some large changes) and it would be great to have some guidance on what would be useful to contribute.

Thanks!

I've read many times about git bisect being used effectively on the Linux kernel, so I'm not sure build times are that much of an issue...

Card-only is way more common than you think in some countries, northern Europe in particular in my experience.

We have a ton of Christmas-only or Easter-only desserts in Italy, all very good. I'm guessing the short availability window increases sales, you just need to make sure you always have something in season ;) It's more of a tradition than anything else, really!