So have you measured it or do you just mean you haven't implemented as many features? -> Usually the latter.
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.
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).
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.
Okay, enough navel gazing for me!
The Revolt.chat SPA looks decent, if featureless, and will probably be fine as the project progresses. This has just launched its beta, after all.
My private computers they are mostly Electron free as far as I can tell, and yes I even pay for Sublime Text.
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).
If your dev team thinks in web-like terms, Electron is a more comfortable place to be. 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.
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.
So, +1 to the developers of Revolt.
I think it's perfectly reasonable for you guys to do it, and I am pretty certain that most of your userbase won't care.
Best of luck and thanks for dropping by!
Hate on HN does not predict any kind of product metric.
Thank you for writing for all.
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.
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.
You have to be where the people are to make it worth anyone's time to complain about performance.
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.
telling the author what their priorities need to be... nice.
On Windows that another story since you have ETW which is incredible and works with anything. But on Linux, if your application doesn't offer observability, you have to resort to strace and adhoc EBPF that you have to write, to diagnose a missbehaving application in production.
It's great to be able to use new Java language/platform features. We're moving to Java 17 next year once the dust settles (it will be the first LTS release in 3 years and comes up this month - Sep 2021)... it will be a much easier migration as there's nothing like the big Java 9 barrier to cross.
I can't understand why anyone would start something new in Java 8, all traditional Java tooling already works really well with Java 11 and even Java 17.
Quite frankly: they just don't know better and they just don't care. I could go on for pages, but in short the people running the show are just really inexperienced and are pretending not to be. I'm going to start applying for jobs soon as its beginning to feel hopeless.
Biggest problem is that installing any app includes a free black hole.
This is gospel at this point.
Npmming and yarning are giving me anxiety these days.
Most projects don't define the node version that their project runs on either, so what ran in node 8 might not run in node 14 now.
What's wonderful to run into is non-JS dependencies: node-gyp happens to be used here and there. Sometimes the native lib will be pulled, sometimes it will be built, who knows why. And node-gyp might then depend on python2 which might not even be present on newer distros anymore.
And so on and so forth. If it doesn't come in an AppImage or docker image, there's no chance I'm getting myself into a node mess.
As you said, it's good to separate the ecosystem from the language/runtime. Things will improve over time, but everything has just been in transition for so long. I dream of the day that transpilers are no longer needed and TypeScript is baked in to all browsers. Until then it is a mess.
> node-gyp might then depend on python2
`cmake-js` is the preferred option now. And Rust native deps don't have this issue.
The only time when I think it’s really appropriate for a mature language is when the language itself is a feature. But that is really rare for that to be the case.
Other languages (eg Python, Haskell and Erlang) are in the mix too, but more evenly distributed and less fad-ish.
This is just part of the hype cycle of languages. I’m not saying Rust is only a fad, but we are definitely in that part of the cycle for Rust.
Lately I've been thinking, it's kind of funny how the modern development mindset is so all about code reuse what with its giant dependency graphs and reliance on cross-platform frameworks; and yet the favorite sport is still rewriting perfectly good applications in the new hotness.
> One thing that makes me appreciate it even more is the fact that it's written in rust without the authors trying to make it into a primary selling point, which is annoyingly common in these days("X written in rust").
Nowadays I’ve come around to appreciating the opportunity to see what other gophers are doing. I usually skip over those posts but occasionally I look at the code and learn something new.
Even when I’m dealing with compiles binaries, I slightly prefer something written in a language I’m familiar with just so there’s a better chance I will be able to diagnose any bugs I encounter.
It is a signal that this will be easy to build, easy to deploy (because it is compiled into a single binary in general), memory safe, and likely to be written by a someone that cares about performance and efficiency.
I think those are all valuable hints.
That's an incorrect assumption if you haven't audited the code.
> likely to be written by a someone that cares about performance and efficiency
Ah, the stamp of approval that comes from signalling to the "right people". Reminds me of the preamble to almost every C++ Boost library -- "written with performance in mind".
> That's an incorrect assumption if you haven't audited the code.
Audit the code? Simply `grep unsafe`.
Even without an audit, the odds of a Rust project being memory safe are so much higher than in comparable languages.
Furthermore, Rust makes auditing so much easier by allowing you to concentrate on unsafe blocks.
GC'd languages (Java, Go, Haskell etc) are safer than Rust by default, you just have the tradeoff of GC. Note that this isn't always a tradeoff as GCs can outperform static allocation in scenarios like large dynamic heaps.
Haskell is the safest for concurrency because of the strictly typed functional semantics.