Forgot your password?
typodupeerror
Social Networks Software

Discord Is Ditching Electron For Rust 74

Discord is replacing Electron with a desktop client built fully in Rust, which the company says should significantly reduce the app's notoriously high resource usage while improving performance and memory safety. "We've been early adopters of Rust since 2018 and a lot of our infra, voice tech, and even some of the current client is already Rust, the holy grail was getting the whole client there," explains Discord chief technology officer Stanislav Vishnevskiy in a post on X. "That means Electron goes away, and so does React Native, mobile keeps native UI but shares app code with desktop via Rust." The Verge reports: Vishnevskiy also shared an image of the Discord Windows client using just 290MB of RAM, which is a clear improvement as you only have to participate in a few servers and RAM usage can easily hit 1GB or more using the current Windows app. It's not clear when Discord will make the full switch over to Rust, but Vishnevskiy says the company "hope to get it into testing with users soon."

Discord Is Ditching Electron For Rust

Comments Filter:
  • by Arnonyrnous Covvard ( 7286638 ) on Thursday November 05, 2026 @02:21PM (#66411775)

    Just? For fucking what?

    • by dfghjk ( 711126 )

      99% of it is memory usage of a mile high stack of shit that the app is built on that none of the developers know or care about. Modern software. Can they even justify 1MB of memory usage?

    • by haruchai ( 17472 )

      Electron bundles a copy of Chromium and NodeJS inside every application and it's not unusual for one PC to be running more than 1 instance of Electron, sometimes more than FIVE.

      • by unrtst ( 777550 )

        Electron bundles a copy of Chromium and NodeJS inside every application and it's not unusual for one PC to be running more than 1 instance of Electron, sometimes more than FIVE.

        Um... this 290MB was for the Rust based client. No Electron there.

        • by haruchai ( 17472 )

          it's a lot but still better than the 1-2GB the Electron-based Discord client uses even when mostly idle

          • by unrtst ( 777550 )

            (just 290MB of RAM) For fucking what?

            (you) Electron bundles a copy of Chromium and NodeJS inside every application ...

            (me) 290MB was for the Rust based client. No Electron there.

            (you) ...but still better than the 1-2GB the Electron-based...

            Sorry, but I don't follow what point you're trying to make. Is the 290MB justified because it includes Electron and thus Chromium and NodeJS as well? ... it doesn't include that stuff, so I guess not. WTF is the justification for the 290MB? Just that it's an improvement over the other implementation? That still doesn't explain what it is that's adding up to 290MB of memory usage.

            FWIW, though that seems quite high still, it's not all that surprising. I'd still be curious to know what the big culprits are, bu

            • by haruchai ( 17472 )

              here's what Google AI said & the conclusion is the release version could use more RAM if it's at feature parity with the current Electron app
              "Even though the Rust rewrite completely eliminates the massive web-browser wrapper (Electron), ~290 MB is still considered a "heavy" baseline for a chat app because Rust only changes how the code runs, not what data the app has to process.
              The remaining memory footprint is driven by what Discord is doing behind the scenes:

              1. In-Memory Server and Channel Caches

    • 640KB is enough for anyone.
    • Re:just 290MB of RAM (Score:5, Informative)

      by darkain ( 749283 ) on Thursday November 05, 2026 @02:51PM (#66411827) Homepage

      1920x1080 24bit bitmap is over 6MB in size by itself. That's assuming the rendering target is a single flat surface with no back-buffering, and also not multiple layered sub-windows. Yeah, believe it or not, but painting things to the screen, just a flat window, still requires RAM using modern compositors. Now add memory allocation for fonts, glyphs, the logo, all the menuing/config sub-windows, and it adds up quite quickly.

      In the Win9x era, the only reason things didnt use this scale of RAM is because there was no compositor. Back then, you painted directly to video RAM, every and every single draw call. There was no persistence of individual window bitmaps, only raw draws to the final output framebuffer.

      And this is all just accounting for the main application, not counting the server content which is undoubtedly loaded with people sharing meme gifs 24/7.

      • Back then, you painted directly to video RAM

        Exactly. If we used the hardware as it is actually meant to be used, then there would be zero waste.

        • Nice smooth window drags and resizes without tearing is pretty great though.

        • Exactly. If we used the hardware as it is actually meant to be used, then there would be zero waste.

          Along with not a lot of everything else. Writing directly to video memory may reduce RAM usage but doesn't necessarily lead to the fastest end user experience. There's a reason we introduced first buffering, then double buffering, then compositors, and it is not because someone thought "hey, let's just waste ram for the LULZ" . The "waste" is not doing clever things with available hardware. Use of RAM to accelerate of smoothen user experiences is clever (but loading an entire web framework to display a wind

    • by Tarlus ( 1000874 )

      The first hard drive I ever owned couldn't hold that.

      • by HiThere ( 15173 )

        I think the first hard drive I used was 20MB, but it could have been smaller. And that was the claimed size, not what was really available.

      • My first hard drive was 30MB MFM drive, in a (at the time) state-of-the-art Intel 386 box. The 386 really was a huge improvement of the 286 segmented memory kluge. I still have the drive, but no way to connect it to a computer.
    • I agree, that's insane. Why bother switching from Electron in that case? I've seen Atom and VSCode use less memory.

      This is an IM client with some nice rich text features, emojis, and pictures/movie support. There's no reason for it to take more memory than 2000s era Microsoft Word.

      • Atom was an appalling memory hog. I was always mystified as to why everyone abandoned the superb sublime text and its tiny footprint for a giant wrapped webpage that seemed custom built for making peoples computers chug.

        On the upside, the day Atom was released, people stopped having the "bloat" excuse to not try Emacs anymore.

        • I don't understand it either. I mean, yes, right now I'm using VSCode, Atom's bastard brother with similar issues, but this is mostly because if I want anything approaching support for a generic web development environment it's the only thing on the table. The entire industry took one look at VSCode and said "Good enough, who cares about RAM anyway?" and... well, that's our industry. Before that it was Eclipse. Eclipse isn't even a good IDE, it has the most obnoxious autocomplete I've ever seen, but somehow

  • by Bahbus ( 1180627 ) on Thursday November 05, 2026 @02:27PM (#66411787) Homepage

    All forms of React are hot garbage.

  • by RobinH ( 124750 ) on Thursday November 05, 2026 @02:36PM (#66411807) Homepage
    As soon as everyone switched to using Claude Code to write all their software, it became affordable to rewrite in Rust, and people are seeing significant speed-ups and a reduction in memory usage, which is amazing. Using Claude to migrate an existing app to another language is a pretty good task for it because it has the existing one as a target, and AI agents work really well if they have a goal to iterate towards. The fact that human programmers find Rust to be pretty ugly doesn't seem to bother anyone, once the agents do most of the interaction. For the line-of-business app that I work on, I'm leaving it in C# for now because that's what I know, and I still review all (or most of) the code it writes. But if I were vibe-coding a weekend project, then telling it to use Rust is kind of a no-brainer.
    • I no longer consider it ugly. I mean, I write python, too. You know, the language where whitespace is significant. A thing that even COBOL dropped in the 1980s because it was a terrible idea.

      • by alvinrod ( 889928 ) on Thursday November 05, 2026 @03:27PM (#66411889)
        Unless you're writing in a text editor where you have to manage the whitespace yourself, almost any IDE will take care of it for you automatically. Also, even if you were using some language where it doesn't matter, you should be using proper indentation anyway. I think it's a particularly good "feature" for new programmers because it forces them to structure their code properly and in a way that makes it easier to identify certain kinds of mistakes that other languages can hide. More importantly it eliminates the need to argue where the curly brackets should go entirely and prevents the kind of holy war being waged to this day and wastes everyone's time when it winds up getting discussed or argued over yet again.
        • Instead we get to have holy wars over whether or not it's appropriate to have a language where if the indents get screwed up the code is completely ruined, and can't be fixed by simply running it through fmt(1).

          I've actually had this happen when copying Python examples from a webpage. I decided to use perl instead at that very moment.

          • Instead we get to have holy wars over whether or not it's appropriate to have a language where if the indents get screwed up the code is completely ruined, and can't be fixed by simply running it through fmt(1).

            It's not appropriate. Anything that is better is useless for corporate work [zerobugsan...faster.net].

            Worse is better. Falsehood is freedom. Truth is terror. Python is

          • by gweihir ( 88907 )

            Well, if you have a situation where anything adds or removes other chars, your code breaks as well. The problem is not Python, but a skill issue with understanding whitespace. I would be wary of any code on the web where somebody managed to screw up publishing Python code.

            The whole thing is really pretty much a non-issue. Sure, in the case you describe, the person posting the code crewed up, but that does not mean the tool is bad.
            Incidentally. Python is 1st on TIOBE at the moment, with almost 2x the rating

            • The whole thing is really pretty much a non-issue. Sure, in the case you describe, the person posting the code crewed up, but that does not mean the tool is bad.

              I don't know where the screwup was. I think it was with the website actually, doing something tricky with CSS to display the code nicely. It doesn't actually matter who didn't do the thing that they would have had to do though, it's a fundamental error in the creation of the language. This is literally going back to an aspect of punch cards.

              Incidentally. Python is 1st on TIOBE at the moment, with almost 2x the rating of place 2 (C). That is not what a fundamentally broken tool gets.

              The appeal to popularity is a logical fallacy.

        • Ah, yes... stupid ideas aren't stupid because they force you to do things the "right way".

          Too bad nobody can agree on what the right way is.

        • Unless you're writing in a text editor where you have to manage the whitespace yourself, almost any IDE will take care of it for you automatically.

          It doesn't. If you try to paste code, the IDE gets confused, which doesn't happen with braces.

          prevents the kind of holy war being waged to this day and wastes everyone's time when it winds up getting discussed or argued over yet again.

          It doesn't. You're a moron, an idiot, and a heretic for liking syntactically significant whitespace. You are the worst kind of person. Trump probably likes whitespace. If you care so much about color, you're probably racist.

        • I know a programmer with a vision disability (brain not eyes) who cannot write in Python only and explicitly because of the whitespace thing.

          Languages with braces are zero problem.

          This makes a programmer ineligible for a large number of jobs on the market.

          I've offered to write a preprocessor to allow braces if it ever became a deal breaker for a job.

          The second biggest problem with disabilities is when an implementer makes a decision having no idea that decision is unworkable for a disabled person.

          The ultima

          • by unrtst ( 777550 )

            I know a programmer with a vision disability (brain not eyes) who cannot write in Python only and explicitly because of the whitespace thing.
            Languages with braces are zero problem.

            At the risk of sounding argumentative, I'm very curious how that's a thing. I might even try to look up that issue to see if there's an essay on it or something.

            First thing that came to mind for me is:
            1. my editor can highlight all whitespace in another color. That would make those indents stand out like a sore thumb.
            2. one can "retab" a file to adjust the amount of whitespace. (see also: vim :retab) Retab to intelligently convert space indents to tabs, change tabstop to something sufficiently large enough,

      • by gweihir ( 88907 )

        I have no idea why people consider whitespace carrying semantics terrible. Sure, you have to be aware of it, but then it is just a minor thing.
        All this criticism just shows how mentally inflexible many "coders" actually are.

        Incidentally, I do not use an IDE for my Python coding. Whitespace is still not a problem.

    • by AmiMoJo ( 196126 )

      What's going to happen to the web version though? It's all Javascript.

      • Rust compiled to wasm, maybe?

        • by AmiMoJo ( 196126 )

          Could be. The current implementation is rather heavy.

          • by gweihir ( 88907 )

            Rust compiled to wasm should give pretty good results. That is if the Rust libraries are set-up for it. Would be a bit surprising if they were not at this time.

      • Some friends of mine were doing this sort of thing (split development) years ago, pre AI. They had a desktop client in C++ and JS client for the web, which was slow. They compiled the core of the C++ one into ASM.js (this dates it) and it ran a lot faster. After a while they scrapped the pure JS one.

        • by AmiMoJo ( 196126 )

          I was thinking they might try something like that. Hopefully it works.

        • by gweihir ( 88907 )

          Interpreted languages fall down when complex stuff is not available via libraries that run natively. One of the main reasons for wasm in browsers.

    • by evanh ( 627108 )

      I wouldn't call 290 MB amazing.

      I know, however, the one time I did launch Discord ... I immediately quit and deleted it and never tried again. It was so slow and clunky, I felt dirty for days after.

    • As soon as LLMs became viable, it became affordable and even smarter to stay with C and write better code or use mitigations where they are needed (and not where they aren't needed). LLMs didn't make Rust viable, they made C continue to be viable. They made Rust another language in a bucket of crabs :-)
      • I like it.

        "Rust is the language slop is written in"

        :)

        • Effectively, that's exactly what it's become.
          • by kertaamo ( 16100 )

            No, it's not just Rust. Rust and a bunch of other languages. Plenty of slop is being produced in JS and many others.

        • by kertaamo ( 16100 )

          Wel... If people insist on AI generating slop I would prefer that slop is in Rust. The Rust language is so fussy about types, object lifetimes etc the clankers have to iterate on its to even get it to compile. It has to be higher quality slop.

      • LLMs aren't good at writing verifiable code and invariants.

        That is, writing C with an LLM is basically guaranteeing that you'll have insecure code. Not in the least because much of the sample code has bugs in it.
  • RUST and what GUI ? (Score:4, Interesting)

    by 4wdloop ( 1031398 ) on Thursday November 05, 2026 @03:18PM (#66411875)

    RUST is generic programming language. Electron is a "webbrowser in a box". So apples and oranges. So what GUI toolking they used. (No I will not fall down this low to RTFA). The 290MB memory footprint still suggest they use HTML/JS there just in a rusting box?

    • by Mousit ( 646085 )

      So what GUI toolking they used.

      Vishnevskiy has said they are using GPUI [gpui.rs] which is from the same group that created the Zed text editor. Though it is quite new and still pre-1.0, so it's interesting that they've chosen that for their client.

  • ... layer is? Is it FOSS? Is it cross platform? Ditching a web layer for something native is a good idea, even better when Rust is the main PL, but I'd really like to know what stack exactly they're using and if it's running a FOSS cross platform GUI. Can someone enlighten me?

  • by JThundley ( 631154 ) on Thursday November 05, 2026 @06:50PM (#66412289)

    Does this spell the end of Discord modifications? This is concerning because Discord put very little effort into the Linux version and naturally the community stepped up and built mods that allow simple things like sharing audio and removing unwanted UI elements. I doubt they'll be opening any of this rust code.

    • by allo ( 1728082 )

      Today a LLM decompiles you the whole program in a day. Adding some modifications are probably no issue.

  • It could be written in assembly, be ultra-fast, use 60kb, never crash or have a security hole, and i would

    STILL HATE DISCORD. Giant privacy, maintenance and centralization nightmare.

  • You're cutting out the soda in your diet and replacing it with a cup. A cup of what? Electron is a framework for integrating HTML/CSS/JS content onto the desktop. Rust is a programming language. Are they still bundling CEF like Electron did (which is going to be most of the RAM usage anyway) or are they writing their own web interface from scratch? Or are they writing something closer to native desktop? I can't imagine doing the latter. If you have a perfectly good working web interface anyway, why duplicat

This login session: $13.76, but for you $11.88.

Working...