Really like your approach! Local-first and clean UI makes a big difference.
We're building a social media tool with similar values—more account support and personal profile compatibility.
RSS deserves this kind of revival. Keep it up!
Show HN: I rewrote my Mac Electron app in Rust
311–320 of 465 posts
Re: Show HN: I rewrote my Mac Electron app in Rust
#312Earlier 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.
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.
Re: Show HN: I rewrote my Mac Electron app in Rust
#313Beware 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.
Re: Show HN: I rewrote my Mac Electron app in Rust
#314Earlier 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…
AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
The borrow checker does not change behavior, so any correct program will be fine without borrow checking. The job of borrow checking is to reject programs only.
mrustc also does not implement a borrow checker.
Re: Show HN: I rewrote my Mac Electron app in Rust
#315Earlier 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…
AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
[deleted]
Re: Show HN: I rewrote my Mac Electron app in Rust
#316Earlier 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…
AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
Not that much different than a type checker in any language (arguably it is the same thing).
I have been using various LLMs extensively with Rust. It's not just borrow checker. The dependencies are ever-changing too. Go and Python seem to be the RISC of LLM targets. Comparatively, the most problematic thing about generated Go code is the requirement of using every imported package and declared symbol.
Re: Show HN: I rewrote my Mac Electron app in Rust
#317Earlier quoted context omitted.
On the contrary it is a big big issue if you have a complex web app like we do. It was a PITA to deal with user bugs in a specific macos version with a 8y out of date webview. And the performances of webkitgtk are horrible on Linux.
That’s a big issue if you can’t set a minimum required version for some reason, same for web apps in general - I rarely find much problems with platform behavior but that’s probably because we just reject out of date browsers.
That's one of the main selling points of Electron: it ships a single browser instead of using the system webview.
The main drawback, of course, is that it ships a browser with every app.
Re: Show HN: I rewrote my Mac Electron app in Rust
#318Earlier 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.
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.
Re: Show HN: I rewrote my Mac Electron app in Rust
#319Earlier 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…
Well it certainly makes error handling easy. No need to reason about complex global exception handlers and non-linear control structures. If you see an error, return it as a value and eventually it will bubble up. If err != nil is verbose but it makes LLMs and type checkers happy.
Re: Show HN: I rewrote my Mac Electron app in Rust
#320Earlier 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.
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-level languages.