5 ms·

Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower

Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.

ctxc 1y ago
This is akin to saying if you rewrite it in Assembly it would be better than Rust. True, but what are the tradeoffs? Why doesn't everyone write it in assembly? It _would_ be bigger and eat more RAM and CPU. But that does not imply "shittier". There are parameters like dev time, skills available in the market, familiarity, the JS ecosystem etc that sometimes outweigh the disadvantage of being bigger/slower. You're pointing out the disadvantages in isolation which is not a balanced take.
- encom 1y ago
  All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly.
  - Sammi 1y ago
    End users care that they get a product at all. Which they won't if it's too costly to make. There is a balance that is appropriate for each project. Or else we should all be writing machine code by hand.
    - pkolaczk 1y ago
      Rust has been shown by Google to not be any less productive than other mainstream languages though.
      - aaronblohowiak 1y ago
        Link? I’d love to learn more!
      - Sammi 1y ago
        [citation_needed]
  - brailsafe 1y ago
    > All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly. A sensible take wouldn't pick one or the other as unilaterally better regarding the abstract context of what a good product is. The web as a platform is categorically amazing for building UIs, and if you chose continued to choose it as the frontend for a much more measurably performant search backend, that could be a fantastic product choice, as long as you do both parts right.
- Arch485 1y ago
  This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends. And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?
  - codr7 1y ago
    Rust's type system gymnastics compared to most languages goes quite a bit beyond preference. I can't see the overlap at all with dynamic scripting languages, two completely different tools for completely different problems.
    - mplanchard 1y ago
      TS has one of the more gymnastics-heavy type systems, IMO, and I think many if not most JS shops use TS.
      - codr7 1y ago
        TS is gradual though, Rust is all or nothing.
  - Capricorn2481 1y ago
    A world of difference between the borrow checker and a garbage collector.
  - HumanOstrich 1y ago
    > there is no reason not to choose Rust Sounds like Rust zealotry to me, followed by a mild attempt to walk it back.
- the_gipsy 1y ago
  > This is akin to saying if you rewrite it in Assembly it would be better than Rust Not really. Nobody is rewriting GUI apps in Assembly, the reasons are obvious.
- timeon 1y ago
  Dev time like cater for ever moving Node stack? (Not sure if it applies here because I'm not familiar with Tauri).
tapirl 1y ago
Comparing Rust with Electron is so weird. One is a language, the other is a lib/framework.
- gloxkiqcza 1y ago
  I think it’s clear what stack is typically meant by “an Electron app” and why using a blanket term like this is faster. However, you could use Rust compiled to WASM in an Electron app, therefore the two aren’t even mutually exclusive.
  - tapirl 1y ago
    For the OP's specified case, it is only a little language related. It is more a lib/framework related thing.
- Blahah 1y ago
  Tauri is the thing being implicitly compared with electron. Well worth checking out.
- worldsavior 1y ago
  It's not, both can be apps.
mike_hearn 1y ago
Possibly but not guaranteed. For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff. If your Rust UI library is as advanced and well optimized as Blink, then yes, maybe. But that's pretty unlikely given the amount of work that goes into the Chrome graphics stack. You absolutely can beat Chrome in theory, by avoiding the overhead of the sandbox and using hardware features that the web doesn't expose. But if you just implement a regular ordinary UI toolkit with Rust, it's not necessarily going to be faster from the end user's perspective (they rarely care about things like disk space unless they're on a Windows roaming account and Electron installed itself there).
- jppittma 1y ago
  Having worked on a graphical application in rust for a (albeit not a complex one) computers today are fast.. latencies top out at 3 ms with cpu based rendering in an application with just a few rendering optimizations. The fact that you just draw on the screen instead of doing whatever html parsing / DOM/IR is probably doing it? And doing rendering on the gpu means extra delay in the processing moving from cpu to gpu and being a frame behind because of vsync.
  - HumanOstrich 1y ago
    Can you clarify this? Seems to me that no matter how you render your UI, it has to go to the GPU framebuffer at some point. For any non-trivial case where I can enable GPU acceleration for an app, it's been anywhere from equivalent to much more responsive. What apps have you experienced delays with by enabling GPU acceleration?
  - mike_hearn 1y ago
    Where it really shows up is stuff like power usage and reliably hitting framerates even on slow machines with big hi-res monitors attached.
- 1y ago
wrasee 1y ago
All of that is true, but technological choices aside it doesn’t take away from all of the points made by the parent. I took that as the somewhat the point, and I think it was insightful. Your app will still be worse, but worse as result of your poor technology choices, not the arguments made here. Put together it may still be a bad move, but you would still get the greenfield effect.
TacticalCoder 1y ago
[dead]
namuol 1y ago
Performance is a feature, I agree. Language choice matters to a degree. Shitty apps can still be written in “fast” languages.

Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.

ctxc 1y ago

This is akin to saying if you rewrite it in Assembly it would be better than Rust. True, but what are the tradeoffs? Why doesn't everyone write it in assembly? It _would_ be bigger and eat more RAM and CPU. But that does not imply "shittier". There are parameters like dev time, skills available in the market, familiarity, the JS ecosystem etc that sometimes outweigh the disadvantage of being bigger/slower. You're pointing out the disadvantages in isolation which is not a balanced take.

encom 1y ago
All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly.
- Sammi 1y ago
  End users care that they get a product at all. Which they won't if it's too costly to make. There is a balance that is appropriate for each project. Or else we should all be writing machine code by hand.
  - pkolaczk 1y ago
    Rust has been shown by Google to not be any less productive than other mainstream languages though.
    - aaronblohowiak 1y ago
      Link? I’d love to learn more!
    - Sammi 1y ago
      [citation_needed]
- brailsafe 1y ago
  > All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly. A sensible take wouldn't pick one or the other as unilaterally better regarding the abstract context of what a good product is. The web as a platform is categorically amazing for building UIs, and if you chose continued to choose it as the frontend for a much more measurably performant search backend, that could be a fantastic product choice, as long as you do both parts right.
Arch485 1y ago
This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends. And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?
- codr7 1y ago
  Rust's type system gymnastics compared to most languages goes quite a bit beyond preference. I can't see the overlap at all with dynamic scripting languages, two completely different tools for completely different problems.
  - mplanchard 1y ago
    TS has one of the more gymnastics-heavy type systems, IMO, and I think many if not most JS shops use TS.
    - codr7 1y ago
      TS is gradual though, Rust is all or nothing.
- Capricorn2481 1y ago
  A world of difference between the borrow checker and a garbage collector.
- HumanOstrich 1y ago
  > there is no reason not to choose Rust Sounds like Rust zealotry to me, followed by a mild attempt to walk it back.
the_gipsy 1y ago
> This is akin to saying if you rewrite it in Assembly it would be better than Rust Not really. Nobody is rewriting GUI apps in Assembly, the reasons are obvious.
timeon 1y ago
Dev time like cater for ever moving Node stack? (Not sure if it applies here because I'm not familiar with Tauri).

tapirl 1y ago

Comparing Rust with Electron is so weird. One is a language, the other is a lib/framework.

gloxkiqcza 1y ago
I think it’s clear what stack is typically meant by “an Electron app” and why using a blanket term like this is faster. However, you could use Rust compiled to WASM in an Electron app, therefore the two aren’t even mutually exclusive.
- tapirl 1y ago
  For the OP's specified case, it is only a little language related. It is more a lib/framework related thing.
Blahah 1y ago
Tauri is the thing being implicitly compared with electron. Well worth checking out.
worldsavior 1y ago
It's not, both can be apps.

mike_hearn 1y ago

Possibly but not guaranteed. For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff. If your Rust UI library is as advanced and well optimized as Blink, then yes, maybe. But that's pretty unlikely given the amount of work that goes into the Chrome graphics stack. You absolutely can beat Chrome in theory, by avoiding the overhead of the sandbox and using hardware features that the web doesn't expose. But if you just implement a regular ordinary UI toolkit with Rust, it's not necessarily going to be faster from the end user's perspective (they rarely care about things like disk space unless they're on a Windows roaming account and Electron installed itself there).

jppittma 1y ago
Having worked on a graphical application in rust for a (albeit not a complex one) computers today are fast.. latencies top out at 3 ms with cpu based rendering in an application with just a few rendering optimizations. The fact that you just draw on the screen instead of doing whatever html parsing / DOM/IR is probably doing it? And doing rendering on the gpu means extra delay in the processing moving from cpu to gpu and being a frame behind because of vsync.
- HumanOstrich 1y ago
  Can you clarify this? Seems to me that no matter how you render your UI, it has to go to the GPU framebuffer at some point. For any non-trivial case where I can enable GPU acceleration for an app, it's been anywhere from equivalent to much more responsive. What apps have you experienced delays with by enabling GPU acceleration?
- mike_hearn 1y ago
  Where it really shows up is stuff like power usage and reliably hitting framerates even on slow machines with big hi-res monitors attached.
1y ago

wrasee 1y ago

All of that is true, but technological choices aside it doesn’t take away from all of the points made by the parent. I took that as the somewhat the point, and I think it was insightful. Your app will still be worse, but worse as result of your poor technology choices, not the arguments made here. Put together it may still be a bad move, but you would still get the greenfield effect.

TacticalCoder 1y ago

[dead]

namuol 1y ago

Performance is a feature, I agree. Language choice matters to a degree. Shitty apps can still be written in “fast” languages.