peterldowns

I just read The Invention of Morel and can recommend it — unsettling, and smart. In general the approach of reading authors who were beloved by or respected by or inspirations for the authors we remember today (Borges in this instance) is quite fruitful.

Thank you for these!

Industrial history and the history of precision manufacturing is extremely exciting to me. This is an excellent overview and the animations — while not quite as smooth as https://ciechanow.ski/ — add to the experience.

If you liked this blog post, you may enjoy the book “English and American Tool Builders" by Joseph Wickham Roe.

Great concept and nice demo site! It's kind of interesting to me what the Jev model is ambiently aware of and what it isn't. For instance, this query comes back as safe:

    -- fails if any rows exist in the table since the new column
    -- is not null and also has no default value.
    ALTER TABLE users ADD COLUMN status text NOT NULL;

That's like, one of the most common mistakes ever when it comes to database migrations. Gemini/ChatGPT/Claude all flag this immediately and can offer improvements.

I bring this up not because it's a gotcha but because I wonder how you think about the utility of rules-based classifiers like this. At a certain point, if you need to extend your rules engines with tons of edge cases like this, why not just ask a true LLM? Or, have you considered extending your default ruleset with generated rules — maybe point an LLM at use-the-index, other db docs, or just ask it to expand the ruleset based on its own knowledge?

We hadn't seen that post before --- very similar, but completely independent.

Reasonable suggestions, but we've mostly published our action as reference for others. I'd suggest forking or creating your own setup-go action and implementing whatever behavior you'd like. Nothing wrong with either idea!

What made you just start posting on HN? Welcome and thanks for the links!

Thanks for reading :) Broken down by key idea:

- 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: this is 100% worth upstreaming. I believe there are existing requests and PRs about this. Up to you guys to implement however you see fit.

- Allowing "always update the cache": also a good idea to enable as an option, very important for non-open-source teams that are trying to maximize cache hit rate.

- Allowing "trim the cache": if you're going to allow always updating the cache, probably a good idea.

But the "always update" and "trim" cache changes combine to have a lot of risks regarding cache poisoning that might be bad for open source projects. Lukas may have a different opinion or more to say on this front.

How did this new account `vertigoruntime` get three posts on the front page, all in the last day?

- This post

- The DeepMind Institute https://news.ycombinator.com/item?id=49727659

- Mistral X Mozilla: Private, Multilingual AI Browsing https://news.ycombinator.com/item?id=49723408

based on their account submission history they have a 25% hit rate (!) Seems very, very weird.

Good question — we'd be happy to submit a PR, but it's not clear to me that they'd be interested. Some background:

- Our approach writes new cache entries all the time. This can get expensive, and is a pretty big change in behavior from how actions/setup-go works today.

- The current actions/setup-go strictly caches dependencies and ignores the build and modules cache. Our approach could be considered a breaking change.

- actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably very risky and slow to happen. At this point I'd bet that we see no change, ever, in behavior.

Additionally there are a few relevant issues/prs that have been ignored for years so I'm not optimistic about contributing upstream. Frankly what we've done is write a very small bit of glue code that is likely most effective as a reference for teams writing their own custom caching actions that fit their exact needs:

- https://github.com/actions/setup-go/pull/426

- https://github.com/actions/setup-go/issues/630

- https://github.com/actions/setup-go/issues/395

- https://github.com/actions/setup-go/issues/596

That said we'd be happy if someone used our code and found it valuable! Lukas put a ton of effort into cleaning up my initial version, added the cache trimming, etc. We depend on this for all of our jobs and use it every day and think it's quite good.

Hey everyone, one of the authors here. This is a "small" improvement that has saved us a LOT of developer time over the last few months. It's actually quite crazy to me that the default actions/setup-go simply does not work well if you want to have more than one golang action running at the same time.

The blogpost has a lot of technical details, but you can also just read the code and try it yourself:

https://github.com/cloudx-io/setup-go

But why not Zanzibar?

This is awesome. Does the demo run fully client-side? This is at least as good as my current solution (Preview.app -> Tools -> Remove Background), I generally pre-crop so it's not too hard to get just the object I care about.

As a Pennsylvanian I think this is idiotic and I completely blame the press, who have breathlesslly amplified baseless negative claims. Such as that datacenters are somehow bad for the environment, have negative impacts on water supply, will raise energy and water rates for residential customers, etc.

I HATE that this is somehow becoming a culture war issue.

The idea is that it's like Github but it stays up even as your commit/CI frequency increases. As a customer I'm stoked and looking forward to fully switching over as that's exactly what I want.

I feel stuck on Github until the next generation of forges (I assume Linear is working on one too, and the Pierre guys, and there's probably more) are ready. When it works, I'm actually a huge fan of Github. It just doesn't work reliably and it's a huge operational risk to not be able to freaking deploy. We'll most likely switch to self-hosted GHE in the near-term while continuing to evaluate alternative forges — Forgejo, Gitlab, Gitea, Sourcehut, aren't appealing enough to switch.

Can't wait for the Graphite/Cursor alternative (Origin) to become available. Actions being down for an hour in the middle of the US East workday is crazy. It's super frustrating to be an enterprise customer of Github, seems like we don't get any dedicated resources or additional stability. At this point our only option is self-host github enterprise or move away.

We built our first version of our in-app agent with opencode, but we're probably going to switch to Pi. Fundamentally, Pi is the shape of the thing that should exist, and it's awesome to see that it works. Very satisfying to my engineering brain. Been having fun with ohmypi as my personal harness, but going to switch over to pi soon and just mess around with it until it works the way I want. The idea of completely personalized software is so cool and now that it's finally possible I am having so much fun.

Possibly — but then you need a cowfs everywhere you run your tests. Templates are already really fast. Give it a shot and lmk if it’s faster!

Yup! If you keep your laptop on, failing dbs are investigable on tmpfs too — works fine for debugging a few tests in a loop, just can’t run the tests, sleep the computer, have lunch, and come back.

Just want to say thank you, Brandur, for checking out pgtesdb and benchmarking it so thoroughly. I’m pleased that it performs so well and I’m going to throw some tokens and brainpower at potentially implementing a cleanup+reuse+pool of successful dbs instead of always tearing them down.

Some confusion in the threads below —

pgtestdb is just a primitive for “give my test a clean db, fast.” With your postgres running on ramdisk, I don’t think there’s any faster way to make a clean and fully migrated db — and your migrations only run one time, no matter how many test processes you have operating concurrently or how many tests are in parallel within those processes.

You can actually combine it with test transactions, you’re totally allowed to do anything you want with the db! It just so happens that it’s fast enough (in my experience) to Just Give Every Test Its Own Database, for quite a large number of tests.

Really cool upside of AI is enabling experiments like this one that previously would have been prohibitively time consuming. Thanks again, Brandur.

Back in highschool, simulating different elevator algorithms was one of the projects I implemented during my CS class. It wasn't for the class — AP CS did not require anything like actual programming — but it was a fun project.

A cool connection is that a spinning-disk hard drive (HDD) is actually kind of like one really long elevator, just wrapped around a spindle instead of perfectly vertical. The SCAN algorithm is actually a disk-scheduling algorithm!

https://en.wikipedia.org/wiki/Elevator_algorithm

Just want to say thank you to Brandur for doing such a cool experiment. Last year I actually explored the River test suite to understand how they made it work so quickly — he's understating it when he says their implementation is "gold standard."

I'm both surprised and excited to hear that pgtestdb, out of the box, can give anyone a ~nearly as fast experience.

Going to have to throw some tokens at pooling... very interesting idea.

Thank you, Brandur!

Always wondered this. Must have been tried and not worked?

Keep following this line of thought and you'll end up in the same territory as Nick Land. If you haven't read already, the xenosystems blogs would probably be quite interesting to you.

"completely" in my experience

Yes, we know. Good teams increase the likelihood of success with AI code generation the same way they increased the likelihood of success during hypergrowth: better infra, better devops, better internal abstractions/frameworks/building-blocks/golden-path-tooling that make the "easiest" way the "best" way to do antyhing. Otherwise, you get bogged down in garbage and everything breaks and catches on fire forever.

I'm a huge fan of Charity Majors and the quoted line in the next tweet in the thread is one of our team's rules, too:

> Every AI output has to have a human owner. If you don't want your name on it, it's probably not good work.

What kind of cpu/memory do the vms get? Is there a way to define the template that's used, so I can say to a new team member, log in to boxes.dev and all the repos and tools are already there for you? And where do you get the machines, can we bring our own? The orchestration layer and product experience ticks all the boxes for me but where Codex, Claude, and Cursor have fallen down for me in the past is:

- slow and outdated vms

- horrible/no way to standardize environments for my team

- no way to bring our own compute to help resolve these issues ^

I've decided to no longer post here after the incredible amount of spam I started receiving, both in terms of direct email submissions as well as unqualified and outright fraudulent applications to my application tracking system.

By fraudulent I mean: fake resumes, names stolen from real developers who work at well-known companies but either don't have a linkedin/portfolio or do have a linkedin/portfolio without a profile picture. So easily impersonated by a scammer.

It is a real shame, but this thread is now being scraped by plenty of other sites and bad actors.

Inbound hiring for remote teams is basically cooked at this point, signal is completely hidden in the noise. Curious if anyone else has had this experience or if it's just me?