I love Advent of Code! I have used previous years' problems for my guest lectures to Computer Science students and they have all enjoyed those more than a traditional algorithmic lecture.
We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron. (Not-so) Surprisingly, both the DX and UX improved significantly for our use case. Personally, I’d still prefer Swift/C#/C++ for native desktop work (coming from a Qt C++ background), but given the business constraints at the time, Electron ended up being the most pragmatic choice.
> When we profiled it, we found that the GC essentially gave up under load
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.
I totally agree :) I don't blame Go either. We were already a pure Go shop with a lot of focus on backend and infra systems engineering and were trying to venture into the desktop app market for our device monitoring software. Once we validated our idea with a rather buggy MVP haha, we quickly switched over to Electron and deployed on all 3 desktop OSes properly.
I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io. That said, I do not remember how we managed the lifetime but we did test it thoroughly before deploying to our initial beta users (or so we thought :P). The GC behavior started to happen whenever the app was in the background, which it was supposed to be for the majority of the time.
I actually did something similar: business logic and most things written in Go, but the menu bar or tray icon done in native APIs like Win32 and Gtk. It was surprisingly very good experience overall. I have tried so many ways around it before settling for that.
Ohh, my apologies for the confusion. I was just using Go as a menubar/tray icon application (with some OS-specific bindings) and meant to say that its performance was excellent. No electron involved
That is a surprising use case about Go and Electron (!), I would have imagined no contest for the superior performance of a compiled language, even with garbage collection. But the mention of "bindings for native UI frameworks", it was probably running the compiled code in a very tight loop, stressing the runtime. In contrast, Chromium specializes in UI with years of optimization.
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.
Been a while since I worked on it but I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io AFAIR.
I’ve been writing Go for the past 4 years, and I’d strongly suggest avoiding Stainless for auto-generating Go SDKs. Some of the issues I’ve run into:
- Awkward package naming (e.g., githubcomdedaluslabsdedalussdkgo)
- Methods with unnecessary complexity, including excessive use of reflection for JSON handling
- Other codegen quirks that make the SDK harder to use and maintain
From experience, I’d recommend either using another code generator or hand-writing the Go SDK for a cleaner and more idiomatic developer experience.
I’ve been working remotely for YC startups for the past 3.5+ years, and I completely agree. I went from being the quietest person in the room to someone who often ends up rambling on most calls. Remote work has not only given me the space to speak my mind - and sometimes even find answers to my own questions - but also the opportunity to learn so much from my colleagues.
One thing I’ve learned from seriously using AI agents for mundane coding tasks is: never ask them to do anything that involves deleting stuff. Incidents like these only reinforce that belief.
If you use an agent they can do whatever they want IMO (caveat: I've never used one), but it's still your job to save and be able to revert the work (git) and to oversee anything involving production.
It's like driving assistants, they feel like they can manage but in the end you are responsible.
I wrote Qt C++ for 7 years as an open source contributor to KDE. This reminds me of QtWidgets’ .ui files—custom XML files following a specific schema. Later, Qt introduced QML, which I personally found unintuitive, and over time I lost interest in Qt altogether. That said, I still think XML for UI definitions makes sense, and it’s understandable that some larger environments continue to use it.
Some of us are still programming in Qt using just C++ and .ui files. Never bothered to switch to QML. I wasn't convinced there were enough advantages to make it worth the effort.
I've been writing a UI framework for experiment automation and small tools using Qt Widgets with Python bindings (https://puzzlepiece.readthedocs.io) and it still works pretty well! I like the API, and it being immediately cross-platform is very useful. It does lack looks on Windows a little imo, but to be honest I'm not opposed to the utilitarian way the apps end up looking.
This weekend I asked Gemini Pro to create a Python Qt app (a serial file sender- something you'd use to send g-code files to a CNC machine or laser cutter). I did most of the dev on Windows but the app will run exactly the same on all 3 main platforms. Eventually I asked Gemini to extract the UI to its own .ui file, which it did. The resulting app worked better than the previous one I had coded myself (handling some various race conditions and other challenging issues much more quickly than me).
If I wanted, I coudl ask gemini to port the app to C++. (Gemini isn't the point here- that's just speeding up what I would have done on my own).
Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines.
Oneleet (YC S22) | Senior Software Engineers | US & NATO Countries | Remote | Full-time | $100k-180k + equity
Oneleet is an all-in-one cybersecurity startup that has built its own Attack Surface Monitoring (ASM), Code Scanner, Device Monitoring, and Compliance Platform. We are growing at an unprecedented pace and working on some very exciting projects.
What we're looking for:
- Senior Software Engineers with experience in our tech stack
- Strong problem solvers who can work independently in a remote environment
- Security-minded developers passionate about building robust, scalable systems (not a requirement)
- Comfortable working during Eastern Time
Tech stack: Go, TypeScript, React, Kubernetes
We offer:
- Competitive salary ($100k-180k based on experience and open to negotiation)
- Equity in a fast growing cybersecurity startup
- 100% remote work
- Company offsites every quarter (past offsites have been in The Netherlands and Italy)
If you're interested in joining our team, please reach out to nafees<at>oneleet<dot>com with the subject line "HN: Senior Software Engineer". Alternatively, you can also apply at https://www.ycombinator.com/companies/oneleet/jobs
Congratulations on the launch! I am interested to know the choice of runtime (in this case - TypeScript) for the implementation of the integrations. What are some reasons that a systems language such as Go was not chosen?
This course single-handedly became the reason for me to clear interviews at all the compiler engineering teams of MANGA (Meta, Apple, NVIDIA, Google, Amazon) companies when I was searching for my first full-time job while completing my Bachelors. My University's (University of Waterloo) curriculum around low-level computing systems was already par excellent, and of'course I was also contributing to open source compiler projects. But this course really helped me answer some of the toughest questions during my interviews!
It's "par excellence", and it feels weird in that sentence structure anyways. A better way to put it would've been "my university has the low level computing systems curriculum par excellence".
Why the bitter ad hominem? What or who hurt you that you can't let people like what they want? Bridging the hardware-software gap is hard, regardless of you appreciating it or not.
Given that your comment has nothing to do with what I said, I’m assuming you misunderstood or are replying to the wrong one?
“Weird comment” isn’t attacking the person (ad hominem) for who they are it’s attacking the action they chose to take. Likewise I don’t see how you took “let them have this one” as not letting people like what they want (granted, the GP comment wasn’t about liking something, it was a failed attempt to flex prior knowledge of this course, interviews at prestigious companies, and knowledge of esoteric language so I’m not entirely sure what you’re even referring to.) My comment didn’t mention “the hardware-software gap” or give any opinion on whatever that is so again..no clue what you’re on about
