> In a decade or so Go the awkward things about Go will have multiplied significantly and it'll have many of the same problems Python currently has.
The stdlib packages are far better designed in Go than in Python. “The standard library is where packages go to die” is literally not a thing in Go, in fact quite the opposite.
> Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option.
> I remembered how helpful that was, so I decided to add it to my command as well.
He mentions the reason he added it, and it's a compelling enough story to be true.
Of course and I am not trying to point fingers. But I do think it's interesting because it's also possible that it is confabulation. Not lying, but genuinely constructing coherent explanations for decisions whose true origins are different than we recall. I think working with coding agents has already made this immensely more common.
I had the equivalent of --dry-run in my kdecvs-build script from 2003 (where it was called --pretend) so it's not that spontaneous an idea that it must have been dreamed up by an AI.
Any time you have a script that needs to run for a long time or might involve destructive actions, having a way to run the script in a "tell me what you would do without actually doing it" mode is a fairly obvious user story to throw in.
Again, it's completely possible that OP and you are the wonderful exceptions (untouched and uninspired by coding agents) that have been using these patterns for as long as you can remember. My comment revolved around the psychological phenomenon, not whether dry-run is a clever/novel idea. It's about how we might tell ourselves stories about the origin of our ideas when working with those tools.
And my point is simply that if it were obvious enough an idea that I thought of it after initially using my tool, you probably will want to look for more realistic examples of where a person thinks they came up with an idea that was really prompted back to them in an AI chat.
This isn't something with surprising nuance like how a McDonald's milkshake serves a non-food "job to be done" during a shopper's morning commute. As evidenced by all the others in this thread pointing out other tools that do similar things, it's a fairly obvious idea to come up with after actually using a new tool.
You'd be more likely to learn about it doing product comparisons of other tools, although since there is a lot of common art for AI training to draw from, yes it is also possible to hear about it from your AI first.
> And as a consequence, C# can pack the value types directly in the generic data structure, instead of holding references to heap-allocated objects.
> This is very important both for cache locality and for minimizing garbage collector pressure.
How is C# just not straight-up faster than Java then? Instead of both language punching around the same weight on benchmarks? Doesn't cache locality like, have a huge effect on performance?
I have no answer except that Java Hotspot JIT seems to be almost too good to be true. I guess it's my way of saying I would also like to know why C# isn't just plain faster than Java.
> Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.
This isn't what is happening. A company called Garantia Data renamed themselves to Redis Labs and acquired the Redis trademark. They're not the original company, and they used a naming trick to present as if they are official (they are now, and nothing they did was illegal).
No. Scrollbars are besides the content, AI-generated content is the content. An article absolutely deserves to be called out if the author has the gall to AI-generate it and then share it on HN (or elsewhere).
I always do this. There's usually one field that you can put at the start that never changes. But the field at the end will keep changing as you add more fields to the SELECT list.
SELECT
a
,b
,c
,d
FROM
Customers
ORDER BY
b
,c DESC
Your argument is that writers do this because of "economics", but to the detriment of readers. I don't see how this extends only to HN readers. It applies to all readers in general.
This is awful. The alternative isn't "no name", it's a full and unambiguous name (even if it's a mouthful). If you can't come up with a good short name, stick with the long one.
The stdlib packages are far better designed in Go than in Python. “The standard library is where packages go to die” is literally not a thing in Go, in fact quite the opposite.
reply