this post was submitted on 13 Dec 2025
28 points (93.8% liked)

Programming

23863 readers
285 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
top 17 comments
sorted by: hot top controversial new old
[–] Oinks@lemmy.blahaj.zone 7 points 7 hours ago* (last edited 7 hours ago) (1 children)

This isn't a very good article IMHO. I think I agree (strongly) with what it's trying to say, but as it's written, it just isn't it.

Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot.

Runtimes/"VMs" like the JVM also allow nice things like stack traces. I don't know about the author but I much prefer looking at a stack trace over "segmentation fault (core dumped)". Having a runtime opens new possibilities for concurrency and parallelism too.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it's smaller and faster and more customisable because it's native Rust code.

This just doesn't make any sense. COSMIC is more configurable because it wants to be, this has absolutely nothing to do with Rust vs Javascript.

Dennis Ritchie and Ken Thompson knew this. That's why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything's in a container all the time, the filesystem abstracts the network and the GUI and more.

And here the author just contradicts themselves. So wrappers, runtimes and VMs are bad, except when it's Ken Thompson doing it in which case adding containers and a language runtime into a kernel is a great idea actually?

Lastly, I didn't address the efficiency arguments in the quotes because it's mostly just true... but I do think it requires some more careful consideration than "JS bad Rust good". Consider this unscientific sample of different apps on my PC and how much of my (expensive!) RAM they use:

  • Spotify (Electron): 1G
  • Ghostty (Zig/GTK): 235M
  • Decibels (Typescript/GTK): 140M
  • Anyrun (Rust/GTK): 110M

Note that Electron, and only Electron, is a supermassive black hole of bloat. Whatever is going on here, it's not Javascript.

[–] SlurpingPus@lemmy.world 1 points 6 hours ago

Even Electron apps can be small: Stretchly, a break reminder, normally takes something like 20 MB of memory.

[–] yggstyle@lemmy.world 56 points 13 hours ago (1 children)

What's the point of being healthy when they have rascal scooters?

[–] nullPointer@programming.dev 24 points 13 hours ago (1 children)

here I am, using my legs like a sucker.

[–] Quetzalcutlass@lemmy.world 14 points 10 hours ago (1 children)

Not to judge, but you're supposed to walk on them, not suck them.

[–] Zorque@lemmy.world 6 points 8 hours ago

Don't tell me how to live my life.

[–] talkingpumpkin@lemmy.world 45 points 13 hours ago (1 children)

...and that's why you need 16GB and a decent CPU to navigate the web

[–] yggstyle@lemmy.world 16 points 10 hours ago (2 children)

What is utterly stupid is with modern compression and rendering techniques - if it weren't for developers shipping a whole ass library to prod for one function that is simplifying 8 lines of code... 56k would still be usable for light browsing and access. It'd be slow still.. But far from literally impossible now.

The sheer amount of "fat" on some (most) sites and applications is just depressing.

[–] shalafi@lemmy.world 4 points 5 hours ago

Back in the day when we were all amazed at Yahoo!'s loading speed I pulled the homepage HTML. 79K. Imagine that.

[–] thingsiplay@beehaw.org 3 points 13 hours ago (2 children)
  • The fastest code is the code you don't run.

Not really. The code can be slow, even if I do not run it. Also, sometimes additional code can do optimization (like caching), which is more code = faster. Or additional libraries, complexity and code paths can in example add multicore execution, which could speed up. So, I do not buy the less code is faster logic.

[–] Malgas@beehaw.org 4 points 11 hours ago

I think the most obvious example is loop unrolling. An unrolled loop can be many times more code, but runs faster because you're not updating a counter or doing conditional jumps.

[–] voytrekk@sopuli.xyz 5 points 13 hours ago (1 children)

I think it really depends on what your code is doing. I do agree that less isn't always faster or as they mentioned in the post, safer. Taking a raw input is fast, but not very safe for a variety of reasons. I personally make "simple to understand" as the highest priority for my code.

[–] thingsiplay@beehaw.org 2 points 12 hours ago

On a slightly different example, the suckless project has a huge emphasizes on lightweight code, which they call "suckless". I don't think in this case faster is the goal, but having less code and be simple as possible (not even configuration files allowed, you just recompile program) and almost no documentation in the code either. But the idea is the same, of having "lightweight" code.