> Blazing fast

So have you measured it or do you just mean you haven't implemented as many features? -> Usually the latter.

Cynicism aside, from what I’ve seen it’s been the former. See regex and rg by burntsushi as an example.

Don't get me wrong there's a lot of room for speed in programs we use regularly, but I make two observations:

    1. Speed is usually found by by people have worked on 
    existing tools in the space, and they don't often make 
    that much of a song and dance about it beyond that 
    theirs is faster.

    2. Speed is found in the minds of people not in their 
    tools. When you get past a certain amount of native- 
    ness, you get optimizations by knowing more or having 
    a brilliant insight into the problem rather than using 
    a new meme-language. It might be necessary for certain 
    types of programming but it's not sufficient.

Basically I don't like weird meme based marketing of tech. I'm a grumpy old man already and I'm the ripe old age of 20

You were the one that cynically asked if the advertised performance improvements were real or imaginary, not me.

To your point, many of the improvements from Rust-based tools appears to come from the ability to express performant semantics safely and elegantly in the language. You could write an equivalent in C, but the Rust one comes naturally, can be expressed at a higher level with better abstractions, and often comes out with top-tier performance before even investing in microoptimizarions (as long as the Big-O performance is in check).

I’ve always seen “written in Rust” as relevant for a specific sort of software. Because CVEs are inevitable in C/C++ software and dealing with CVEs has become part of the user interface to that software. Knowing something is “written in Rust” means its attack surface is much smaller. Working in tech, the “drop everything and migrate to a version that isn’t vulnerable” instances are far too common and disruptive.

But as soon as you get into consumer software with auto-update mechanisms and an expectation that end users won’t be computer professionals who know how to read a CVE and evaluate its urgency, the “written in Rust” distinction becomes a mostly irrelevant implementation detail. Or, worse, it’s an indication that the GUI will feel wrong in some way because the Rust community seems averse to writing GUIs with GTK, UI Kit and whatever the hell Microsoft recommends using for Windows these days.

"Electron is definitely worse than rust is good."

I would say, it depends very much on the developer. There are probably only a handful of people, who can write a fast GUI in C/++ that is also safe, plattform independent - and a joy to use.

(I am definitely not among them)

But there are a ton of devs, knowing how to accomplish it - with the webtoolkit.

In other words, I indeed would prefer a electron app, over some hacked together GUI in a "performant" language. Security, performance - and UX wise.

Thankfully there is no C++ on Electron.

Is Rust as blazing fast as Electron is slow?

But Rust runs on the server while Electron runs on the client. You can't compare them like that!

Rust is about as fast as C++, so I'd call that normal speed.

Electron is not necessarily slow - see Visual Studio Code; it's certainly not as reactive as Sublime Text, but it's fast/reactive enough.

I know, it was a (admittedly vague) joke.

People rag on Electron with the same shallowness as they praise Rust. I bet you can make slow things in Rust. It's all a soup of trade-offs, resource management and hype.

The issue is that the alternatives to Electron--GUI frameworks that use native controls--are so hard to use and inconsistent that Electron seems good by comparison.