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

331–340 of 465 posts

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

#331

Post by rubymamis »

sillyboi wrote: post #142

It would be great to see an up-to-date benchmark comparing modern cross-platform frameworks like Tauri, Flutter, Electron, React Native, and others. Key metrics could include: - Target bundle size - Memory usage (RAM) - Startup time - CPU consumption under load - Disk usage - e.t.c. Additionally, for frameworks like Tauri, it would be useful to include a WebView compatibility matrix, since the rendering behavior and…

I've compared block editors (Notion - Electron, Appflowy - Flutter , etc) to my Qt C++ & QML block editor I've built in my blog post[1] using similar parameters. You might find it a good read.

[1] https://rubymamistvalove.com/block-editor

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

#332

Post by ctxc »

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.

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.

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

#334

Post by sroussey »

Aeolun wrote: post #268
yojo wrote: post #75

Earlier quoted context omitted.

It's not a new or scary thing, but it's way more expensive (in time or money) than relying on "it looks good on my machine, so it looks good everywhere." I've worked on large consumer-facing web-apps where we had a dedicated QA team (and/or contracting firm) that runs visual regression testing on multiple platforms and browser versions. As a solo developer, I have no interest in being that team for my hobby project.…

> it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them Tauri however, is.

Some of these apps then download huge models these days and the total space savings kinda vanishes.

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

#335

Post by capitol_ »

antonvs wrote: post #320
tapirl wrote: post #301

Earlier quoted context omitted.

My surprise is typescipt is so slow. I have never used it yet, but I think will never too.

Technically Typescript can't really be slow, since it's just a preprocessor for Javascript, and the speed of its programs will depend on which Javascript implementation you use. Typescript's sweet spot is making existing Javascript codebases more manageable. It can also be fine in I/O-heavy scenarios where Javascript's async model allows it to perform well despite not having the raw execution performance of lower-lev…

I thought that (for example) deno executed typescript natively?

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

#336

Post by IshKebab »

tapirl wrote: post #301
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-...

My surprise is typescipt is so slow. I have never used it yet, but I think will never too.

Depends what you mean by slow. The Typescript code was 3x slower than the Go code, and a 3x overhead is pretty much the best you can do for a dynamically typed language.

Languages like Python and Ruby are much much slower than that (CPython is easily 10x slower than V8) and people don't seem to care.

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

#337

Post by stouset »

tgma wrote: post #325
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…

> I have never understood why people want to use LLMs for programming outside of learning "I have never understood why people want to use C for programming outside of learning m. I have written PDP11, Motorola 6800, 8086 assembly professionally and to this day I feel like they would slow me down. I have used C in the past and I was not am still not a fan. But I recently had to break it out for a new project. Turbo C…

Right now they are fancy autocompletes. That is enormously useful for a language where 90% of the typing is boilerplate in desperate need of autocompletion.

Most of the “interesting” logic I write is nowhere close to autocompleted successfully and most of it needs to be thrown out. If you’re spending most of your days writing glue that translates one set of JSON documents or HTTP requests into another I’m sure they’re wildly useful.

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

#338

Post by tapirl »

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.

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

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

#339

Post by pjmlp »

charcircuit wrote: post #312
pjmlp wrote: post #306

Earlier quoted context omitted.

Ask BSD guys and girls how they feel about that. Monocultures are great, as long they are the one we bet on.

Well due to it being open source their niche operating systems were able to run Linux software via a compatibility layer and Linux drivers making them better.

Microsoft was right all along after all, what a waste of money in lawsuits, monoculture for the win.

Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal, why bother.

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

#340

Post by tgma »

stouset wrote: post #337
tgma wrote: post #325

Earlier quoted context omitted.

> I have never understood why people want to use LLMs for programming outside of learning "I have never understood why people want to use C for programming outside of learning m. I have written PDP11, Motorola 6800, 8086 assembly professionally and to this day I feel like they would slow me down. I have used C in the past and I was not am still not a fan. But I recently had to break it out for a new project. Turbo C…

Right now they are fancy autocompletes. That is enormously useful for a language where 90% of the typing is boilerplate in desperate need of autocompletion. Most of the “interesting” logic I write is nowhere close to autocompleted successfully and most of it needs to be thrown out. If you’re spending most of your days writing glue that translates one set of JSON documents or HTTP requests into another I’m sure they’r…

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. To wit, there was an actual Linux kernel vulnerability in SMB protocol stack discovered with LLM a few days ago.

Even if we take the narrow use case of boilerplate glue code that transforms data from one place to another, that encompasses almost all programs people write, statistically. There was a running joke at Google "we are just moving protobufs." I would not call this "fancy autocomplete."

Post reply on HN