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

411–420 of 465 posts

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

#411

Post by TacticalCoder »

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.

[dead]

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

#412

Post by mort96 »

ksherlock wrote: post #209
mort96 wrote: post #177

Earlier quoted context omitted.

Especially macOS is built on the assumption that you rarely "quit" apps. When you close all of an app's windows, it remains running. You actually have to hit cmd+q or right click and hit "Quit" in the Dock to really quit an app. In other circumstances too though, it's not great UX to demand your users quit your app once they're done with it because it eats too many resources just being idle in the background. It's an…

Electron doesn't seem to support it (and even if it did, I suspect most electron developers wouldn't pay it any mind) but... NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes. https://developer.apple.com/documentation/appkit/nsapplicati... It's not 100% consistent but if…

Electron doesn't automatically exit when the last window is closed, and the Electron getting started guide (https://www.electronjs.org/docs/latest/tutorial/tutorial-fir...) recommends this code:

    app.on('window-all-closed', () => {
        if (process.platform !== 'darwin') app.quit()
    })
Most Electron apps probably do exactly that. It would feel extremely out of place for a macOS app to quit just because you closed a window.

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

#413

Post by [deleted] »

mort96 wrote: post #39
yojo wrote: post #14

I recently went the other way (started a project in Tauri, moved to Electron) because of frustration with rendering differences between the web views employed on different platforms. Have you run into any cross platform UI bugs since you switched? It looks like your UI needs are pretty simple while computation is complex so the extra QA tradeoff would still be worth it for you. I'm just wondering if my experience was…

Dealing with the rendering differences isn't any more difficult with Tauri than it is when making a normal web app, is it?

[deleted]

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

#414

Post by mort96 »

oblio wrote: post #226
porridgeraisin wrote: post #198

Earlier quoted context omitted.

Have you actually tried deploying to webkitgtk ever? Good luck "testing" your video conferencing app on webkitgtk - it doesn't support webrtc! It is still useful to test your error page I suppose. Note that this is one example among many of missing features, bugs and/or horrible performance. Here's a preview: no notifications, no :has, no TLA. (Not blaming the epiphany devs for the situation here to be clear)

The thing is, Firefox/Gecko isn't embeddable (probably the one of worst tech blunders ever). I wonder if Tauri could wrap around Blink, instead? Then your app could just ask for Chrome to be installed.

The modern Qt web view component, QtWebEngine, is actually Chromium-based. So you could imagine a Tauri which uses Qt instead of GTK and uses QtWebEngine as its renderer instead of WebKitGTK.

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

#415

Post by itsibitzi »

platevoltage wrote: post #186

I did the same thing with one of my projects. I built a simple webcam viewer that is optimized for USB microscopes as I couldn't find anything out there for this purpose. Basically all of the functionality was implemented in the renderer. As I was planning for App Store submission, I realized that a 500mb webcam viewer might not be the best thing. I decided to port it to Tauri V2 and got it down to about 15mb.

Out of interest, how did you stream the video data to the frontend?

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

#416

Post by spmurrayzzz »

stouset wrote: post #321
tgma wrote: post #304

Earlier quoted context omitted.

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…

I have never understood why people want to use LLMs for programming outside of learning. I have written Perl, C, C#, Rust, and Ruby professionally and to this day I feel like they would slow me down. I have used golang in the past and I was not am still not a fan. But I recently had to break it out for a new project. LLMs actually make golang not a totally miserable experience to write, to the point I’m honestly asto…

I've always found it fascinating how frequently I've seen the complaint about Go re: boilerplate and unnecessary toil, but in previous statements Rust was uttered with an uncritical breath. I agree with the complaint about Go, but I have the same problem with Rust. LLMs have made Rust much more joyful for me to write, and I am sure much of this is obviously subjective.

I do like automating all the endless `Result` plumbing, `?` operator chains, custom error enums, and `From` conversions. Manual trait impls for simple wrappers like `Deref`, `AsRef`, `Display`, etc. 90% of this is structural too, so it feels like busy work. You know exactly what to write, but the compiler can't/won’t do it for you. The LLM fills that gap pretty well a significant percentage of the time.

But to your original point, the LLM is very good at autocompleting this type of code zero-shot. I just don't think it speaks ill of Rust as a consequence.

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

#418

Post by stouset »

DoesntMatter22 wrote: post #362
stouset wrote: post #321

Earlier quoted context omitted.

I have never understood why people want to use LLMs for programming outside of learning. I have written Perl, C, C#, Rust, and Ruby professionally and to this day I feel like they would slow me down. I have used golang in the past and I was not am still not a fan. But I recently had to break it out for a new project. LLMs actually make golang not a totally miserable experience to write, to the point I’m honestly asto…

This is akin to saying that you prefer a horse to a car because you don't have to buy gas for a horse, it can eat for free so why use it?

The first cars were probably much less useful than horses. They didn’t go very far, gas pumping infrastructure wasn’t widely available, and you needed specialized knowledge to operate them.

Sure, they got better. But at the outset they were a pretty poor value proposition.

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

#420

Post by aaronblohowiak »

pkolaczk wrote: post #386
Sammi wrote: post #367

Earlier quoted context omitted.

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.

Link? I’d love to learn more!
Post reply on HN