4 ms·

I couldn't upvote this enough. I find it utterly infuriating that across the world, we spend hundreds of billions (trillions?) of dollars on computing hardware.

I couldn't upvote this enough. I find it utterly infuriating that across the world, we spend hundreds of billions (trillions?) of dollars on computing hardware. And almost all of the cycles (easily over 99% of them) are totally wasted doing stupid, totally unnecessary makework because programmers are too lazy. Tauri (an electron-like written in rust) used to have a page where they touted how efficient it is, boasting that it "only" took 300mb of ram to run a “hello world” app, and it started up in only ("only") 25000 syscalls. 300mb of ram is 2.4 billion bits. Just, how? The tauri benchmarks page has since been taken down - perhaps out of embarrassment. In comparison, the Super Nintendo had 128kb of RAM (2000x less than needed for tauri's hello world) and it ran all sorts of incredible games, including the legendary super mario bros. The Atari 2600 shipped with 128 bytes of ram, which is less than one tweet. (Though cartridges could contain extra ram chips).

ryandrake 2y ago
The Apollo guidance computer had 4 kilobytes of core memory and took humans to the moon.
jeroenhd 2y ago
The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. It had zero mouse support, its keyboards lacked almost every key, and its audio output was simply terrible. I don't think it supported IMEs or screen readers either. When I'm doing desktop work, I'd take a 300MB browser application over a SNES any day. The laudable terms used in the Tauri benchmark was a tad silly (though it makes some sense, as Tauri competes with Electron, not with normal native toolkits) but modern GUIs require more processing power than those 160x120 GUIs from back in the way did. It also helps a lot that you can subscribe to modern app subscriptions for half a decade before you've paid the price of what software used to cost (software that would be outdated by next year, and you had to pay again to upgrade), and that old price didn't come with hosting of any kind either. Programmers have always been lazy, but the modern laziness when it comes to performance isn't because nobody cares; it's because nobody is willing to pay for the kind of responsiveness of yore anymore.
- mwcampbell 2y ago
  This is the standard response, and I've given it myself, but I refuse to accept that we need all of the bloat of Chromium in order to do internationalization, accessibility, fast high-resolution rendering, etc. I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS). And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either. But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.
  - josephg 2y ago
    Yeah the other reference point I sometimes think about is the old windows IRC client mIRC. mIRC was super fully featured - it supported downloads, scripting (I think it had its own embedded scripting language), colors, and all sorts of other wild things that I never learned to use. It had way more features than modern discord, although it was missing discord's voice chat, video chat and screen sharing. (And it obviously didn't have any of the modern encryption algorithms). I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.
alpaca128 2y ago
I got curious and it turns out both Tauri and Electron seem to have gotten much more bloated over time. In 2021 they claimed a RAM usage on Mac OS of 13MB vs 34MB for Electron [0]. In 2022 the numbers (on Linux) were more than 10x as high, 180MB vs 462MB as well as a startup time of 0.4s vs 0.8s [1]. In 2023 the comparison is gone from the Readme. [0] https://archive.org/details/github.com-tauri-apps-tauri_-_2021-02-20_11-21-40 https://archive.org/details/github.com-tauri-apps-tauri_-_20... [1] https://archive.org/details/github.com-tauri-apps-tauri_-_2022-09-18_02-58-53 https://archive.org/details/github.com-tauri-apps-tauri_-_20...

ryandrake 2y ago

The Apollo guidance computer had 4 kilobytes of core memory and took humans to the moon.

jeroenhd 2y ago

The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. It had zero mouse support, its keyboards lacked almost every key, and its audio output was simply terrible. I don't think it supported IMEs or screen readers either. When I'm doing desktop work, I'd take a 300MB browser application over a SNES any day. The laudable terms used in the Tauri benchmark was a tad silly (though it makes some sense, as Tauri competes with Electron, not with normal native toolkits) but modern GUIs require more processing power than those 160x120 GUIs from back in the way did. It also helps a lot that you can subscribe to modern app subscriptions for half a decade before you've paid the price of what software used to cost (software that would be outdated by next year, and you had to pay again to upgrade), and that old price didn't come with hosting of any kind either. Programmers have always been lazy, but the modern laziness when it comes to performance isn't because nobody cares; it's because nobody is willing to pay for the kind of responsiveness of yore anymore.

mwcampbell 2y ago
This is the standard response, and I've given it myself, but I refuse to accept that we need all of the bloat of Chromium in order to do internationalization, accessibility, fast high-resolution rendering, etc. I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS). And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either. But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.
- josephg 2y ago
  Yeah the other reference point I sometimes think about is the old windows IRC client mIRC. mIRC was super fully featured - it supported downloads, scripting (I think it had its own embedded scripting language), colors, and all sorts of other wild things that I never learned to use. It had way more features than modern discord, although it was missing discord's voice chat, video chat and screen sharing. (And it obviously didn't have any of the modern encryption algorithms). I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.

alpaca128 2y ago

I got curious and it turns out both Tauri and Electron seem to have gotten much more bloated over time. In 2021 they claimed a RAM usage on Mac OS of 13MB vs 34MB for Electron [0]. In 2022 the numbers (on Linux) were more than 10x as high, 180MB vs 462MB as well as a startup time of 0.4s vs 0.8s [1]. In 2023 the comparison is gone from the Readme. [0] https://archive.org/details/github.com-tauri-apps-tauri_-_2021-02-20_11-21-40 https://archive.org/details/github.com-tauri-apps-tauri_-_20... [1] https://archive.org/details/github.com-tauri-apps-tauri_-_2022-09-18_02-58-53 https://archive.org/details/github.com-tauri-apps-tauri_-_20...