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

351–360 of 465 posts

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

#351

Post by gloxkiqcza »

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.

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.

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

#353

Post by charcircuit »

pjmlp wrote: post #339
charcircuit wrote: post #312

Earlier quoted context omitted.

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.

>monoculture for the win

The browser is the actual product. An open source browser engine lowers the barrier of entry of creating new browsers.

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

Which is why Valve recommends game developers to target Windows and use Proton for compatibility. Having one platform to target simplifies developers lives. Before developers were making bad ports to Linux because they did not have the resources to properly support another tech stacks. The value of developers being able to target a single platform can not be understated.

Though this is fundamentally a different situation as the leading implementation is closed source and is more capable.

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

#354

Post by tapirl »

gloxkiqcza wrote: post #351
tapirl wrote: post #338

Earlier quoted context omitted.

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

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.

For the OP's specified case, it is only a little language related. It is more a lib/framework related thing.

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

#355

Post by szszrk »

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…

OK, but you phrase it like it's something bad, while you say it's very, very good in practice. But maybe for different reasons than language change.

We should state: "this is true and really works, just remember language was likely only part of that".

It's rather "embrace" instead of "beware".

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

#356

Post by wiseowise »

capitol_ wrote: post #335
antonvs wrote: post #320

Earlier quoted context omitted.

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?

It executes typescript without you compiling it to JavaScript first, it doesn’t make code execution any faster.

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

#357

Post by tapirl »

tgma wrote: post #350
tapirl wrote: post #349

Earlier quoted context omitted.

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.

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

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

#358

Post by wiseowise »

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…

It can easily explain it with a little nudge.

Not sure why you feel smug about knowing such a small trivia, ‘gofmt’ would rewrite it to semicolon anyway.

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

#359

Post by KronisLV »

FINDarkside wrote: post #286
taroth wrote: post #215

Earlier quoted context omitted.

Here's a great comparison, updated two weeks ago. https://github.com/Elanis/web-to-desktop-framework-compariso... Electron comes out looking competitive at runtime! IMO people over-fixate on disc space instead of runtime memory usage. Memory Usage with a single window open (Release builds) Windows (x64): 1. Electron: ≈93MB 2. NodeGui: ≈116MB 3. NW.JS: ≈131MB 4. Tauri: ≈154MB 5. Wails: ≈163MB 6. Neutralino: ≈282MB Mac…

The benchmark also says Tauri takes 25s to launch on Linux and build of empty app takes over 4 minutes on Windows. Not sure if those numbers are really correct.

A few months ago, I experimented with Wails and Tauri on Windows. The builds did indeed take unreasonably long with the Rust option and were way faster with Go, no idea why but I ditched Tauri because of that since Wails did more or less the same thing.

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

#360

Post by pjmlp »

charcircuit wrote: post #353
pjmlp wrote: post #339

Earlier quoted context omitted.

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.

>monoculture for the win The browser is the actual product. An open source browser engine lowers the barrier of entry of creating new browsers. >Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal Which is why Valve recommends game developers to target Windows and use Proton for compatibility. Having one platform to target simplifies developers li…

There will be no browsers left, likewise the Year of Desktop Linux will never come, cursed forever to emulate/translate other platforms, ChromeOS and Windows, so that it can have any kind of applications, pretending to be "native".
Post reply on HN