Agents are pretty savvy with the `go doc` and `go list` builtins, especially if you nudge them!
177 karma · joined February 14, 2016
Precise and very clearly written.
The relevant question here is whether you want open-weight models — projects like Open Athena — to remain or become competitive in the same range of specialties.
I don't understand the contrast you're drawing. Harness design and benchmarking are major aspects of vibe coding (and solving math problems with LLMs, for that matter); I would go so far as to say harness design and benchmarking are the more intellectually serious aspects of vibecoding. Fernando is definitely aware of them as well. These just aren't meaningful substitutes for the intellectual work being diminished.
Like with all things CI, your mileage will vary according to where you write your code and what the code does.
> - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache [...]
I'd actually go further: this may be a sensible default behavior.
"Always update the cache" can get expensive, but it's a neat one; "trim the cache" is definitely necessary if you enable this in a moderately active repository in our experience.
If you want really out-there ideas: rather than storing and loading the full cache monolithically, you could use a GitHub-specific GOCACHEPROG and Go-specific cache service to load only the active items. The pruning problem goes away because accretion is cheap. In theory, parallel jobs could actually share this joint cache. (This may not be a realistic initiative at GitHub.)
If you can raise feedback with your colleagues —
- The docs and settings for Actions Cache limits are really hard to navigate; at some pointed we desperately wanted to pay GitHub more money for more cache, but couldn't figure out why we were capped.
- Bulk-data endpoints for Actions performance would be a boon for optimization projects like this. I wind up either scraping `gh run` (slow) or setting up a GitHub App to collect perf data through webhooks (initially tedious, has to be continuously available).
All this aside — actions/setup-go is a pretty well-considered default and an essential part of writing Go on GitHub; ty for your work maintaining it!
- WillAbides/setup-go-faster speeds up the Go toolchain setup (literally installing Go)
- cloudx-io/setup-go uses the slower actions/setup-go toolchain setup, but changes cache strategy so your `go test` and `go build` steps do less work
Those strategies are compatible. I hadn't heard of setup-go-faster — thanks for putting me on to it.
If you're deciding between one or the other, it'll probably come down to which inefficiency predominates in your codebase (i.e. how many tests you have, how quickly they run, and how much real churn there is in your test package build graph).
The trick was to run back over our git history and calculate, for each commit,
1. The test package Go cache keys at that point
2. The GitHub actions/cache keys constructed by actions/setup-go and cloudx-io/setup-go respectively
Once you have these mappings, you can
1. Pick some arbitrary HEAD commit
2. Model which prior GitHub cache blob would be loaded under each action
3. Compare the test package Go cache keys in that loaded blob against those for HEAD to determine which test packages would run vs. skip
Might write this up in greater depth sometime soon.
It only gets a brief mention, but the cache-pruning change was an interesting one. Cache accretion happens in the default actions/setup-go too, but dramatically increasing the number of cache-writes for cloudx-io/setup-go made it an actual issue.
As the cache grows, so does the time it takes to load it from GitHub's actions cache... and that grows until it's a significant time-suck in CI. We prune with basic mark-and-sweep.
Digging deeper, the pluggable `GOCACHEPROG` (introduced in Go 1.24) is a really useful tool. Shimming the normal cache logic for measurement, for example. In theory this should also be attractive for remote caching.
That's exactly what I did to learn River — implementing simple apps and testing their execution with pgtestdb: https://github.com/lukasschwab/river-playground
The starter skeleton was LLM-generated and not quite perfect, but discovering the coding agent's mistakes was satisfying in its own right.
And then claim is attributed right there:
> The hands-down highlight was the talk by Erik Schluntz: Vibe coding in prod.
> Among other things, he drew an analogy between LLMs and compilers.
There's one in the Musée des Arts et Métiers in Paris — blew my mind!
[^1]: https://en.wikipedia.org/wiki/Cloud_chamber
Edit: turns out people make these at home all the time. Sick!
> If `url` [optional] links to where you’re talking about a thing, then `external_url` links to the thing you’re talking about.
I'd be shocked if Atom/RSS didn't have equivalents.
This kind of "repost"-ish behavior may just be obscured in the tools people use to construct feeds, so they remain obscure features of the standards. The designers had syndication in mind, very much like what you're describing — ingesting feeds, reprocessing/mixing/extending them, and exposing the result as another feed.
- NetNewsWire was slick, but wouldn't work on my phone.
- Feedbin was excellent, but eventually I decided to do some subscription cost-cutting.
- Miniflux worked fine, but 1) I found it a pain to set up with remote hosted Postgres and 2) it burned through the Neon free-tier usage limits in a couple days.
So I built one myself and run it on a Raspberry Pi home server.
Made a great little weekend project. The feed standards are known quantities, so a little AI assistance with boilerplate goes a long way.
Deciding you need a new feature and just adding it is refreshing — e.g. I wanted a "read it later" feature like Feedbin's (something missing from Miniflux), and now I have it.
I think of Jeffrey Pfeffer's "social contagion" arguments a lot — first with regards to layoffs[^1], but increasingly also to RTO policies and tracked AI use.
It seems very unlikely execs (esp. in small organizations) are taking the time to read and seriously evaluate research about RTO or AI and productivity. (Frankly, it seems much less likely than them doing serious modeling about layoffs.) At some point, the "contagion" becomes a matter of "best practices" — not just a way to show investors what you're doing, but part of the normal behavior shareholders expect.
Bleak if true!
[^1]: https://news.stanford.edu/stories/2022/12/explains-recent-te...
I wind up feeling grateful for simple interfaces, especially the ones disseminated in the standard library.
It's up to the podcast producers to decide for/against distributor-exclusivity, determining whether OC has to use YouTube Music.
> The vast majority of folks don't know that they have a choice, let alone that they should find/choose an app.
That's... fine. What matters is whether they do have a choice if they go looking for one — again, that's up to podcasters, not up to Google.
Nothing in this announcement indicates YouTube Music will attempt to control distribution. YouTube might give exclusive content a try (a la Spotify), but — to your point — that won't be a "podcast" in the strict client-agnostic-syndication sense.
As long as podcast creators are publishing mp3s to RSS/Atom feeds, YouTube Music is just another podcast client (like Google Podcasts was) which you're free to avoid.
In one respect this consolidation makes more sense than the Play Music → YouTube Music switch: many podcasts cross-post episodes as YouTube videos and audio-only feeds. If YouTube collates those feeds and lets users select between modes while maintaining a unified "already watched/listened" list... hey, that reflects how podcasts distribute/monetize in practice.
The YouTube Music app was a dismal replacement for Google Music, and never regained features for managing one's own library of uploads. Of course, that's not a problem for podcasts; episodes are already syndicated.
All that said, this still bodes poorly.
Captchas are certainly not foolproof, but they up the difficulty of running a huge number of phony accounts while having a minimal impact on normal Twitter usage.