Personally I see “Written in rust” as more of a meme, often using buzzwords like “blazing fast” and “memory safe.” Electron is definitely worse than rust is good.
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.
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.
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.
Ah, the monolithic HN myth again. That's right, let's just ignore that this place has thousands of readers, thousands of commenters, and that there's no thing called "HN" to talk about as it if had intentionality and/or opinion.
While the readership may be large and diverse, there is nevertheless a Hacker News zeitgeist, especially due to the way downvoting causes comments to be greyed out. The acceptable range of discourse does not extend to anything non-flaggable, and comments do not stand or fall based solely on their thoughtfulness or logic. This forum is still a popularity contest, and there are both winners and losers.
Greyed out comments are still legible. I regularly see people saying things like "I'm sure my comment will be flagged", and days later, it just isn't. Sure, there's a popularity contest - unless you get rid of voting and display-in-vote-order, there always will be. But I would say that paying much attention to that rather than the contents of comments represents a personal choice to be distracted by the noise of the "contest", even while the signal remains in plain sight.
Sometimes folks probably feel HN has three people: the person, the people that agree with the person, the people that disagree with the person. Four, if you count moderaters (who I imagine are cooler than Robocop).
Electron is MAX_HATE, Rust is MAX_LOVE, but Discord is more Electron than it is anything. As in, I don't care if Rust runs on their servers if Electron runs on my desktop.
Loves Rust? My eyes glaze over whenever rust is mentioned in a headline. At this point rust really isn't novel anymore, it's a language loads of programs use.
Hi, one of the developers here, we use electron because its hard for our small amount of devs (there are about 4) of us to maintain multiple clients, this is the same reason we use the same web client for mobile.
Did you consider Qt or some other cross-platform native option? There was just recently a HN article [1] on the topic of cross-platform development and UX, with a few alternatives proposed. I think some teams just reach for the Electron tool by default now, instead of weighing each alternative and then choosing it with eyes open. Maybe your team did examine the pros and cons, but it seems the overall software industry is headed toward a simplistic "Cross Platform Client equals Electron" which is disappointing.
It reads as though there's some confusion between "simplistic" with "simple". Electron is the simple answer, and "simplistic" is frequently used to try to shit on that. (Its implementation is complex. So is Qt's. But nobody cares about that for either, because it's done.) Qt's definition of "cross-platform" is functionally limited to "Windows, Mac, and Linux" unless you want to do way more work for a way worse result. That's not simple at all.
Qt runs in a web browser via WebAssembly but building an application that way--I mean, if you want that to work, good luck, but it's a presumptuous ask to make of a developer. If you want to have a client somebody can log into via Chrome or Firefox? Hi, now we have two codebases that aren't sharing logic.
Qt also doesn't work well on iOS or Android. Attempts have been made. They're not viable without significant work that "Qt is cross platform" elides, and you're probably forking your entire codebase for what you can actually salvage. And when you've built a Qt application, there's a whole lot less that's reasonably sharable when you eject out of it on those platforms (because you will), as opposed to the large amounts you can effectively share between React and React Native (see also the web-hosted option above).
Personally, managing a QT application across multiple OSes is itself harder as I’ve spent a lot of time doing platform-specific UI work (eg. fonts on macOS and DPI scaling problems on Windows) compared to Electron. The only similarity was in doing platform-specific tooling for deployments/code signing which is par for the course.
"Better? I'd agree with you that it's probably not. "
Not really disagreeing, but "Better" is just constrained by the real ressources at hand. You have a team, specialised in making plattform independent QT apps? Sure, that is what you do. But chances are you don't, so you just target the web as web devs are plenty around.
"Academic" metrics of what is theoretically more preferable as a plattform and should be considered "better" are usually not very helpful to actually build things.
There's a bit of a chicken-and-egg thing going on here, though. As a close-by comment noted, there are signs of a convergence of thinking towards "cross-platform means Electron", when this is not actually the case (or is not required to be the case).
To the extent that this is true, it acts as disincentive for people wanting to pursue non-web-dev pathways in their careers, which then further limits the availability of such developers, which then further "confirms" the "cross platform is Electron" idea.
Developing with Qt is (I am told [0]) not much harder than typical web equivalents, but it is different. The result is generally more performant, both in terms of UI and also data handling/computation.
[0] I personally work with GTK, not Qt; Qt goes much further with hand-holding developer helpers than GTK does.
I suspect "everything is a web app now" has become a really big consideration. JavaScript has essentially succeeded in doing what Java tried to do two decades ago: be the One Language for both client and server. So if you're building a server-client application like a Discord competitor, it sounds like just an awesome idea to be able to use JavaScript to build your server back end and your web app and your various desktop client apps.
FWIW, as a mostly backend/native developer, I know that I've spent way too much time looking for a widget set that works well enough for my needs. These days, if I need a front-end, I'll be targeting the web or Electron.
A friend and a bunch of her friends had visibly too much time and implement a chat protocol with a server implementation in rust, one in go and one in swift. As well as a client in flutter, rust (iced), Vue and Qt. https://github.com/orgs/harmony-development/repositories
Would be amazing if you worded it as Free Software rather than just open source, since the practical and ethical advantages are indivisible, which is a characteristic of the former and not the latter.
it'll be neat to see if ya'll end up near slack or discord levels of resource consumption, or whether you are slimmer/leaner. is this at all a concern of the team? is chat data all kept in memory or does some of it get stored/loaded on demand, in service worker caches or indexeddb or sqlite or other?
on my 4gb, 6 year old daily driver i dont find electron apps to be difficult. personally i dont think it's that worthwhile to try to appease the vast ranks of anti-electron anti-web zealots (i doubt any of them would ever be satisfied no matter how many gains were made). but it would be interesting to hear of folks adopting more advanced techniques to keep resource consumption down.
Performance is more important that cross-platform support. If a user has money to feed more and more and more resources into a gluttonous, hideously inefficient web browser masquerading as a program, they have enough money to get on the platform everyone else is on.
Discord is an obscene drain on resources. That's the problem that's easy to solve: just stop with the bad programming choices.
That said, I didn't realize at first that Revolt is in fact meant to be a REPLACEMENT top to bottom, and not just a rogue Discord client like Ripcord. You're hawking it on the basis of privacy, rather than speed (since it obviously won't be much better there). But the privacy angle is laughable from the start. Do we run our own servers? It's not clear to me from reading the site. You talk about "creating" servers, but Discord users "create" servers as well: on Discord's hardware. If Revolt genuinely allows for the creation of independant servers, with no control or access by the Revolt devs, that is at least something. If not, I don't see the point.
The backend and the clients are both open source, so I think the idea is that people do run their own servers. There's certainly nothing stopping you. I assume the hosted server is just for convenience and/or demo purposes.
Not very familiar with Discord, but from what I understand it seems everyone runs their own server? Like every game/topic/etc community has their own server?
I think a "server" on discord is more like a "organisation" on slack than an actual server. i.e. it's a tenant partition on a multi-tenant centrally hosted system.
