Hmm, the Go GC is really quite capable, so I wonder what kind of pathological load it was being presented with. Even then, when the GC "fails" it means elevated CPU load from collection.
The main thing I can think of would be the application "leaking" by having unintentional references (or worse, actually leaking through cgo bindings), or trashing the allocator to cause temporary spikes in between cleanups.
However, while I don't think Go was actually to blame here, I would never use native UI bindings to a language that isn't 1:1 compatible with the original design and memory management principles, as such bindings get disproportionaly large and complex. It just sets you up for a bad time.
This sounds to me like leaking resources from the binding. Which binding did you use and how did you manage it's lifetime?
Recently for a specific purpose I was reviewing options including Tauri, various WebView bindings, and in the end had to admit that Electron is probably the best approach in terms of feature set, development speed, etc.
Which bindings did you use ?
And for most apps using browser based rendering won't be an issue. People often underestimate how optimized mondern browsers really are. And because Chromium is not shipped the bundle size is managable.
Not wanting to use JS on the backend I tried both Tauri and Wails and found the simplicity of Go to just work perfectly for my use-cases
Tauri and Wails just use the one available in the OS (UIWebKit in macos, WebView2 in windows), it is also why they load so fast, you probably already have the heavy part loaded in memory. And, of course, brings a tiny statically linked binary instead of running on top of a massive runtime.
0 - https://fyne.io
Other discussions: - https://news.ycombinator.com/item?id=31785556 - https://news.ycombinator.com/item?id=19478079 - https://news.ycombinator.com/item?id=22291150
Just my 2 cents ;)
With Electron, for example, a stripped down Chromium is shipped. So what does the web view rendering with this package?
Why is that hidden behind a click and two walls of text?
1. The state of C++ is not great. Few developers, C++ footguns, complicated build systems, and generally slow progress, see my https://arewemodulesyet.org/
2. How Qt presents and licenses itself. Either you go LGPL or you have to pay big money for a commercial license, which will then infect all other apps as well. For example, when you have two Qt apps that talk to each other you must license _both_ commercially.
3. The split of Widgets and QML makes the ecosystem fragmented, because Widgets will never die. Even the Qt devs themselves are split about this. You can see this when example code for a new feature uses Widgets. QtCreator is also a nice example, where they reverted some new QML code quite a while ago and have not substantially added any new QML code since then.
4. Tooling: We use QML for everything and the tooling is not great. The language server is still super flaky and breaks, and developer tooling like the Chrome Dev Tools is virtually nonexistent.
5. Packaging is still also not great but has gotten better in the last few versions where Qt creates a deployment cmake script for you, but you still need logic for your own (vcpkg) packages.
I can also think of QT and GTK for other languages too.
On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI).
I'm personally a fan of AppKit and Win32, but those are "dated" apparently.
Just as a book will be read many more times than it is written, the burdens associated with a program's architecture will be borne many more times (collectively) by its users than by its developer. This is why I avoid web-based tech when building applications.
Relatedly, I'm glad to see that sustainable computing has begun showing up in global discourse.
Coming to desktop app development from the web, I’ve got most of the same conveniences I’m used to like GammaRay as the inspector. The only real difference is I’m willing to wade through cmake and linking errors.
Even QWidgets is still super fast to develop with if you’re using PySide (although hot reload is a bit more difficult to implement and distribution becomes the nightmare).
Ya gotta be practical.
Doing native UIs is only a matter of actually wanting to learn how to do it.
At least last I looked into it.
