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

341–350 of 465 posts

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

#341

Post by encom »

ctxc wrote: post #332
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.

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

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.

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

#343

Post by lelanthran »

kristianp wrote: post #299
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…

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

> And a surprising level of speedup.

Not surprising at all; I keep pointing out that the language benchmarking game is rarely, if at all, reflective of real-world usage.

Any time you point out how slow JS is someone always jumps up with a link to some benchmark showing that it is only 2x slower than Go (or Java, or whatever).

The benchmarks game, especially in GC'ed languages, are not at all indicative of real-world usage of the language. Real world usage (i.e. idiomatic usage) of language $FOO is substantially different from the code written for the benchmarks games.

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

#344

Post by izacus »

Klonoar wrote: post #135
mort96 wrote: post #58

Earlier quoted context omitted.

I know. I'm saying that Tauri doesn't make things more difficult than any normal web app development, it's not like making web apps which work across browsers is a new and scary thing

Tauri does not do this in all cases, as WebkitGTK on Linux has performance issues and is often the ugly duckling of everything. I also feel like I will have to, yet again, trot out the comment from a Slack dev that explains why they moved _from_ per-platform webviews to Chromium. This isn't new ground being charted, plenty of companies and teams have been down this path and Electron exists for a reason. (I am not say…

Slack in web works fine in several platform browsers still though.

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

#345

Post by charcircuit »

wolvesechoes wrote: post #329
charcircuit wrote: post #228

Earlier quoted context omitted.

It's much more convient for developers for there to be a dominant to open source browser engine. Open source reduced the need for these standards and multiple vendors. See what happened with how Linux largely replaced the slew of UNIXes. The ability for everyone to contribute to a single project paired with the ability to customize it where needed to suit the product you are building has shown to be a winning model.

Chromium may be open-source, even free software, but only in letter, not in spirit. Google has total control over it, and will force any changes it likes. Developer community can only abide.

>but only in letter, not in spirit. Google has total control over it

This applies to every open source project. The owners control what will be merged upstream and the direction the project will go in.

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

#346

Post by izacus »

Capricorn2481 wrote: post #78
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.…

> Reading anecdata on forums, 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 I think it's good to be wary of overly sensitive advice that regular users don't care about. But would a regular user realize they have 10 electron apps running and their ram is maxed out all the time? The argument against Electron isn't just a single bloated bina…

At one of my jobs we actually measured those differences and even 10s of MB in app size increase moved user download, use and update metrics (negatively).

I think the person you're responding to didn't actually measure if their claim is true.

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

#347

Post by imhoguy »

Inspiring! It seems Electron has proved it's value for the v1 MVP anyway. And then Rust has cemented the already proven functional value.

I don't know a technical details but maybe Sqlite would be the best next step of slim down?

I noticed screenshots on the page are displayed croped on Chrome Android (yeah I know).

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

#348

Post by [deleted] »

tgma wrote: post #318
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.

I suspect the particular use-case of parsing/compiling is pathologically bad for JavaScript runtimes. That said, they are still leaps faster than reference Python and Ruby interpreters.

[deleted]

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

#349

Post by tapirl »

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…

I have never seen any AI system could explain correctly on the following Golang code:

    package main

    func alwaysFalse() bool {
     return false
    }

    func main() {
     switch alwaysFalse() // don't format the code
     {
     case true:
      println("true")
     case false:
      println("false")
     }
    }
> Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across time

Not true for Go 1.22 toolchains. When you use Go 1.21-, 1.22 and 1.23+ toolchains to build the following Go code, the outputs are not consistent:

    //go:build go1.21
    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)
     }
    }

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

#350

Post by tgma »

tapirl wrote: post #349
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 seen any AI system could explain correctly on the following Golang code: package main func alwaysFalse() bool { return false } func main() { switch alwaysFalse() // don't format the code { case true: println("true") case false: println("false") } } > Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across…

You're bringing up exceptions rather than a rule. Sure you can find things they mess up. The whole premise of a lot of the "AI" stuff is approximately solving hard problems rather than precisely solving easy ones.
Post reply on HN