Hey, I happened to try this recently when I was holding my breath for another reason! It hit 70% or a little lower by the end*, but that was after having exhaled for a while. I do wonder what effect that kind of thing can have, even minor.
There’s nothing wrong with the CommonJS approach except that it’s not designed for static analysis (and whether that was really an issue is debatable). In Zig, it’s compile-time.
Not really, because I expect to also have binary distribution of modules, as in systems languages like Modula-2, Mesa, Object Pascal/Turbo/Delphi, D, Ada,....
Yes, CSS and <picture> etc. can load different resources based on viewport size. Then there are side channels like lazy loading, layout + what you interact with.
No, they don't. They're using a different meaning for "thread safety" that's more useful in context since they do ensure data race safety - which is the only kind of thread safety OP is talking about. By guaranteeing data race safety as a language property, Java and C# are proving OP's point, not refuting it.
In keeping with the theme of the comment you're replying to, writing better-performing code and providing performance options are not mutually exclusive. Both are good ideas.
> This feels like your car having the option to burn motor oil to show a more precise clock on the dash; you don't get kudos for adding an off-switch for that.
(Sounds more like you're arguing that it should be forced off instead of being an option? Reasonable take in this case, but not the same argument.)
No, I think they’re arguing that showing seconds in the system tray shouldn’t be so inefficient that turning it off gives back double-digit percentage energy savings.
I think we all agree there needs to be some additional power draw for the seconds feature, but it’s unclear how much power is truly necessary vs this just being a poor implementation.
there's a dramatic increase in how frequently you interrupt the CPU to update the display. That is true at the OS level no matter how efficient you make the second display code.
It shouldn't take any noticable power/cycles to accomplish this task. Having flags for "performance" littered through the codebase and UI is a classic failure mode that leads to a janky slow base performance. "Do always and inhibit when not needed".
Yes, they’re so tertiary that there was no reason to include them on the website. They’re ugly and mismatched, don’t consistently add value to the content, and make a negative first impression (for these reasons and for people who have valid aversions to AI slop). (By the way, all or almost all of the images are generated, not just the two you listed.) Useless images are far from a new problem (gotta love those Medium-article-style heros that can take multiple MB when people forget to optimize them) but AI further lowers the quality bar.
I think you missed the second, much more horrifying part of the code at the link. The thing “stopping” the output from being treated as instructions appears to be a set of instructions.
* sensor accuracy not guaranteed
reply