Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I rewrote my Mac Electron app in Rust

desktopdocs.com

Post reply on HN
Print view View original

381–390 of 465 posts

Re: Show HN: I rewrote my Mac Electron app in Rust

#381

Post by mike_hearn »

bboygravity wrote: post #313
namuol wrote: post #297

Beware the greenfield effect. I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it’s better” is essentially a fact of life no matter the tech choices, at least for the first big rewrite. First, you’re going to make better technical choices overall. You know much better where the problems lie. Second, you’re rarely going to want to port over…

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.

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).

Re: Show HN: I rewrote my Mac Electron app in Rust

#382

Post by timschmidt »

stevekemp wrote: post #366
tgma wrote: post #340

Earlier quoted context omitted.

I don't know which models you are using, but in my experience they have been way more than fancy autocomplete today. I have had thousand line programs written and refined with just a few prompts. On the analysis and code review side, they have been even more impressive, finding issues and potential impacts of changes and describing the intent behind the code. I implore you to revisit good models like Gemini 2.5 Pro.…

It comes back to the nature of the work; I've got a hobby project which is basically an emulator of CP/M, a system from the 70s, and there is a bug in it. My emulator runs BBC Basic, Zork, Turbo Pascal, etc, etc, but when it is used to run a vintage C compiler from the 80s it gives the wrong results. Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case…

> Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case for this CP/M BDOS function, in the same style as the existing tests"

These are all things I've done successfully with ChatGPT o1 and o3 in a 7.5kloc Rust codebase.

I find the key is to include all information which may be necessary to solve the problem in the prompt. That simple.

Re: Show HN: I rewrote my Mac Electron app in Rust

#383

Post by stevekemp »

timschmidt wrote: post #382
stevekemp wrote: post #366

Earlier quoted context omitted.

It comes back to the nature of the work; I've got a hobby project which is basically an emulator of CP/M, a system from the 70s, and there is a bug in it. My emulator runs BBC Basic, Zork, Turbo Pascal, etc, etc, but when it is used to run a vintage C compiler from the 80s it gives the wrong results. Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case…

> Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case for this CP/M BDOS function, in the same style as the existing tests" These are all things I've done successfully with ChatGPT o1 and o3 in a 7.5kloc Rust codebase. I find the key is to include all information which may be necessary to solve the problem in the prompt. That simple.

I wrote a summary of my issue on a github comment, and I guess I will try again

https://github.com/skx/cpmulator/issues/234#issuecomment-291...

But I'm not optimistic; all previous attempts at "identify the bug", "fix the bug", "highlight the area where the bug occurs" just turn into timesinks and failures.

Re: Show HN: I rewrote my Mac Electron app in Rust

#384

Post by worldsavior »

tapirl wrote: post #338
bboygravity wrote: post #313

Earlier quoted context omitted.

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.

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

It's not, both can be apps.

Re: Show HN: I rewrote my Mac Electron app in Rust

#385

Post by jppittma »

mike_hearn wrote: post #381
bboygravity wrote: post #313

Earlier quoted context omitted.

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.

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 optimi…

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.

Re: Show HN: I rewrote my Mac Electron app in Rust

#386

Post by pkolaczk »

Sammi wrote: post #367
encom wrote: post #341

Earlier quoted context omitted.

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.

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.

Rust has been shown by Google to not be any less productive than other mainstream languages though.

Re: Show HN: I rewrote my Mac Electron app in Rust

#387

Post by pkolaczk »

tgma wrote: post #304
kristianp wrote: post #299

Earlier quoted context omitted.

Microsoft rewriting typescript tools in Go and getting a 10x speedup? It's wild that they would choose Go for that. And a surprising level of speedup. https://devblogs.microsoft.com/typescript/typescript-native-...

In my experience, Go is one of the best LLM targets due to simplicity of the language (no complex reasoning in the type system or borrow checker), a high quality, unified, and language-integrated dependency ecosystem[1] for which source is available, and vast training data. [1]: Specifically, Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consi…

Go is a great target for LLM because it needs so much boilerplate and LLMs are good at generating that.

Re: Show HN: I rewrote my Mac Electron app in Rust

#388

Post by tapirl »

codr7 wrote: post #378
tapirl wrote: post #357

Earlier quoted context omitted.

I believe future AI systems can make correct answers. The rule is clearly specified in Go specification. BTW, I haven't found an AI system can get the correct output for the following Go code: package main import "fmt" func main() { for counter, n := 0, 2; n >= 0; n-- { defer func(v int) { fmt.Print("#", counter, ": ", v, "\n") counter++ }(n) } }

What do you base that prediction on? Without a fundamental shift in the underlying technology, they will still just be guessing.

Because I am indeed experiencing the fact that AI systems do better and better.

Re: Show HN: I rewrote my Mac Electron app in Rust

#389

Post by jacobgorm »

starkparker wrote: post #48
katrinarodri wrote: post #35

Earlier quoted context omitted.

We actually haven't rolled out cross platform support yet with the Tauri version, so we will see how that goes. Our UI needs are simple, luckily. What kind of rendering differences were you seeing with Tauri? Was there one platform that worked the best/worst for your app? We'd love to support Windows next. With the Electron version of the app, we had issues running our bundled binaries on Macs with Intel chip. That c…

I worked with an open-source project that uses Tauri 1.x and their migration has been blocked with issues for months. It was a nightmare for the span I was involved in, and it looks like it hasn't moved forward since I stopped. In particular, rendering and crashing issues specific to Linux have been blockers, but Tauri 1.x also has other rendering issues on Linux that 2.0 fixed. There's little to no guidance on what'…

Also the multi repo nature of the Tauri project, and the changes to this structure between 1.x and 2.0, makes migration hard.

Re: Show HN: I rewrote my Mac Electron app in Rust

#390

Post by timschmidt »

stevekemp wrote: post #383
timschmidt wrote: post #382

Earlier quoted context omitted.

> Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case for this CP/M BDOS function, in the same style as the existing tests" These are all things I've done successfully with ChatGPT o1 and o3 in a 7.5kloc Rust codebase. I find the key is to include all information which may be necessary to solve the problem in the prompt. That simple.

I wrote a summary of my issue on a github comment, and I guess I will try again https://github.com/skx/cpmulator/issues/234#issuecomment-291... But I'm not optimistic; all previous attempts at "identify the bug", "fix the bug", "highlight the area where the bug occurs" just turn into timesinks and failures.

It seems like your problem may be related to asking it to analyze the whole emulator _and_ compiler to find the bug. I'd recommend working first to pare the bug down to a minimal test case which triggers the issue - the LLM can help with this task - and then feed the LLM the minimal test case along with the emulator source and a description of the bug and any state you can exfiltrate from the system as it experiences the issue.
Post reply on HN