Please at least pretend to read the article before posting something like that.
HN user
markusw
Independent software consultant for cloud-native Go apps & AI engineering. Also electronic musician, street photographer, glitter enthusiast, and minimalist.
Find me at markus@maragu.dk
I like to think it’s a gopher. :D
This is so good and so fun! :D
Hi, I'm the author of GAI. I'm glad that you are happy with it! I'm using it a lot myself, both for own and client projects, but I wasn't sure if anyone else was. :D
I'm actually trying to build it out in a way so that gateways aren't necessarily necessary. Cost and token tracking happen through OpenTelemetry. Fallbacks and retries are handled through the new “robust” package, and I have other plans as well. You're always welcome to file issues in the repo for things you'd like to see but aren't there yet. :-)
Oooh, I didn't know that.
I think you had a post about marimo notebooks at some point? I think they would be better suited for that. Their representation is just Python, they can run as scripts, and they have native HTML output. But of course, it only works for Python.
That's actually one of the things that has kept me from using Claude Code web (that, and I often need a Chrome browser for the agent). But they must be working on it.
I saw an MCP I've set up on claude.ai show up in my local Claude Code MCP list the other day, it seems inevitable that there will be skills integration across environments as well at some point.
I guess it would still make sense to have "demo" and "browser-use" skills, so that the agent can reach for them proactively? I always try to remove as much friction as possible for myself, one little bit at a time.
Oh, I hadn't seen that one either, thanks for sharing. Here I am still using the Chrome Devtools MCP like a caveman. :D
If you're coming from the Python world, definitely. I find `go install github.com/simonw/rodney@latest` equally easy. :D Although you need the Go tooling installed, of course. But so much agree, Go is great for CLIs!
I’d rather say you can use skills to do RAG by supplying the right tools in the skill (“here’s how you query our database”).
Calling the skill system itself RAG is a bit of a stretch IMO, unless you end up with so many skills that their summaries can’t fit in the context and you have to search through them instead. ;)
What I've done in a project once is use Purchasing Power Parity: basically, there's an index for purchasing power, and you adjust your pricing based on that. It's implemented in some major payment platforms, like Gumroad: https://gumroad.com/help/article/327-purchasing-power-parity
Thank you for sharing the youtube links in particular! It's nice to get some background info and intent for interesting libraries.
For Go, something like gomponents [0] or Templ [1] would fit that. (Disclaimer: I wrote gomponents.) I even have a Datastar integration now. [2]
It's a frontend framework and a backend SDK in multiple languages, for SSE and more.
Agreed about the Postgres export!
For sqlite, I would recommend "sqlite3 app.db '.backup backup.db'" though, if that's an option. Guaranteed consistent!
No worries. :-) Thank you for your follow-up, kind stranger on the internet.
Sure, you are correct! But I've already learned about pglite and sqlite-vector from the comments here alone. So if one reads the article AND the comments, I hope it's a net-positive for you, too, even if the article alone didn't give you anything.
And if not, I hope you didn't spend too long reading. :-)
Yeah, totally agreed. An embedded Postgres would be sweet (see pglite elsewhere here in the comments, looks interesting).
I am so tempted to benchmark some more… :D Would be great to get some numbers on this, super interesting.
Note: The last paragraph was about in production, not tests. :-)
Uuuuh, that looks super interesting! I hadn't heard of that. Thank you for sharing!
Yeah, basically the same here, except it's Caddy in front instead of Traefik.
So you do periodic backups, not incremental on every write or something (read replica-like)?
It's important to me to not lose any data once committed if at all possible.
(For testing, I've sped everything up by running migrations on `template1` and every test gets a random database name. Works wonders.)
Ah, I thought I recognized your username from a Github URL. :D Thank you for your contributions in the SQLite & Go space!
I had no idea that was possible. I'll keep that in mind if I need a similar workflow. DuckDB is awesome. :D
Oh, interesting! But that's more of a desktop application now, right? I was thinking of web servers when writing the article, but I can see how that's not totally clear. :-)
Yeah, totally agreed. I'll have to look into that. I've really enjoyed the stability of SQLite, down to the file format.
The biggest one is latency. Network latency will almost always be orders of magnitude bigger than I/O latency. There's a whole class of problems that goes away when latency becomes very small.
Interesting! I'm going to look into that. :-) Thank you for sharing.
While I really like DuckDB, I wouldn't use it for OLTP workloads.
I'm curious, when do you want to treat your Postgres like SQLite? :-) That's basically the opposite of what I was thinking of in the article.