Hey Shubham, I can still see the API keys in https://www.runanywhere.ai/web-demo, FWIW. A simple proxy of the request from the frontend to your own API and then to the vendor API would solve this. Also recommend rate limiting on the same. Happy to help if you need further assistance.
Seems like you are leaking an ElevenLabs API key in your web demo. The OpenAI completions endpoint also has the API key in the request header but that seems to already be revoked and is returning a 401.
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.
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.
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.
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.
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.
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.
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!
This is going to be my daily driver to schedule our team meetings, great work! A feature request would be to give me the option to input the time apart from the existing slider input.
That is my bad. There is no implication for the index position as such. Whenever a file changes/updates, the prefix is matched with the procs object and if it matches, the respective processes restart.