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.
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.
Rust has stacktraces without needing a runtime. Don’t ask me what exactly is going on behind the scenes, but there is a way to request a stacktrace for a given point in the program. And unless you’re doing embedded stuff, a stacktrace is automatically generated for errors.
And as for concurrency/parallelism, it’s correct what you wrote, but I just wanted to point out that it doesn’t have to be a language runtime. Using Rust as an example again, you typically spawn the Tokio async runtime on program start, if you’re gonna do async/await stuff.
What the hell are you talking about? Who are you talking to?
You don’t need a ‘framework’ to write JavaScript. And HTML doesn’t ‘simulate’ a GUI, it in fact provides a paradigm and an engine ready for rendering gobs of text, images and whatnot, on which any other typical GUI framework would choke like a little baby. And you would have to implement any minuscule element from scratch in godforsaken C++ of all things.
Maybe learn a thing or two of what you’re trying to speak about.
Do you imagine that it abstracts an underlying GUI framework?
Please tell me, how would an HTML engine render something like a few paragraphs of text flowing around embedded images whatever which way, if it did that over a traditional framework like Qt/Gtk/etc.
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.
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.
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.
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:
Note that Electron, and only Electron, is a supermassive black hole of bloat. Whatever is going on here, it’s not Javascript.
Rust has stacktraces without needing a runtime. Don’t ask me what exactly is going on behind the scenes, but there is a way to request a stacktrace for a given point in the program. And unless you’re doing embedded stuff, a stacktrace is automatically generated for errors.
And as for concurrency/parallelism, it’s correct what you wrote, but I just wanted to point out that it doesn’t have to be a language runtime. Using Rust as an example again, you typically spawn the Tokio async runtime on program start, if you’re gonna do
async/awaitstuff.Even Electron apps can be small: Stretchly, a break reminder, normally takes something like 20 MB of memory.
Still has about 20 abstractions to simulate a GUI in a Document Object Model. And the framework for your small code has more loc than your OS.
What the hell are you talking about? Who are you talking to?
You don’t need a ‘framework’ to write JavaScript. And HTML doesn’t ‘simulate’ a GUI, it in fact provides a paradigm and an engine ready for rendering gobs of text, images and whatnot, on which any other typical GUI framework would choke like a little baby. And you would have to implement any minuscule element from scratch in godforsaken C++ of all things.
Maybe learn a thing or two of what you’re trying to speak about.
Uhuh. And how you think it does that?
Do you imagine that it abstracts an underlying GUI framework?
Please tell me, how would an HTML engine render something like a few paragraphs of text flowing around embedded images whatever which way, if it did that over a traditional framework like Qt/Gtk/etc.
That’s what i say, minimized webbrowsers are a slight bit less bloaty but still make for bloaty GUI frameworks.