Recent submissions

Comment · 5 days ago
More often than you might think: low latency on interactions, loads, responses, etc is a high priority for e.g. social media sites and online marketplaces, where fast, smooth interaction measurably increases user retention and spending ([link](https://www.youtube.com/watch?v=x2EOOJg8FkA)).

Also the case for desktop applications: lower latency on input directly improves user experience and satisfaction. Some applications directly market based on this: half of the Zed editor's marketing is 'coding at 4k 144FPS'.

Though you might not immediately think of it as 'software' gamedev is one of the most performance-focused regions of the industry, especially in graphics, especially especially for studios building or customizing their engines. Reducing memory consumption lets you comfortably increase scope, making the engine more efficient increases your frame count. A bad framerate on console/mid-range PCs alone can be the touch of death for a project.

In cases where the software isn't end-user facing, performance is still often a concern even when there isn't a strong real-time constraint, not just because of temporal latency, but because slow software means more time spent running the software, which means paying for more servers or a higher cloud bill. A badly optimized core cloud pipeline can devour an org's budget, where a well-optimized one can run for peanuts.

Comment · 1 month ago
I can confirm that Bryan Cantrill has seen, and had a good laugh with this comment. Well done.
Comment · 11 months ago
If it helps, GPTZero rates the text as 99% AI-generated. In addition, the whole article has a patter that's very typical of LLM-writing, fond of short phrases and reversals. You might also consider that the medium page it's pulled from posts short daily articles on programming, full of surface-level takes on language and technology choice without going into serious technical detail or providing biographical detail about the author, their work, or their projects. Or, most clearly, you might notice that those articles are replete with ASCII flowcharts--something a human writer would almost certainly not bother with in favor of just drawing them, but which is very easy for an LLM to output.

All of this points quite clearly to this being LLM-generated. But, as I pointed out in my other comment, as have others above, it's just not well argued. The points are shallow and don't adequately support the claims made. It looks to me very much like someone churning out posts on surface-level topics by prompting an LLM, either not having the expertise to tell the quality of the argument or just not bothering.

Comment · 11 months ago
Leaving the LLM writing aside, this argument just doesn't hold together. It wants to say 'Rust has these flaws, therefore it will not replace C/C++', but doesn't make (or doesn't realize it is necessary to make) the intermediary claim 'C/C++ do not have these flaws/Rust does not provide enough other attractive features to overcome these flaws'.

It's also engaged in an odd two-step where it conflates C and C++, championing C's simplicity in contrast to Rust's complexity... and then just doesn't address C++'s complexity, as though it's interchangeable with C. The notion that Rust developers are running into quirks with tooling and this is reason not to use it in preference to C++ is ludicrous.

Comment · 11 months ago
Presumably because it's LLM-generated, as other comments here are pointing out.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton