In that same budget, PDOT spent $56M on streets, signs and streetlights, before you even consider the $242M spent on "asset management" - which appears to generally be capital improvements; i.e., rebuilding roads [2, page 509].

I don't care what fraction of that wear and tear is due to buses, it's not remotely close. And in any case, by the same fourth-power law, private 18-wheelers do astronomically more damage than buses.

And yes, PDOT makes revenue back from some of those things, so it's not all straight from the city general fund, but it doesn't matter in any practical way. They don't have revenues broken down as far as I'd like on that budget - there's one big $89M line item for "charges for services", which appears to include parking meters as well as tram fare - but the vast majority of their budget still comes from taxes plus "intergovernmental" sources (aka state and federal money, aka taxes).

[1] https://www.gpmetro.org/wp-content/uploads/2025/01/2025-Oper... [2] https://www.portland.gov/budget/documents/fy-2025-26-city-po...

State and local governments spend a truly obscene amount of money building and repairing roads, and set aside a nauseating amount of publicly owned land to serve as roads, street parking, and parking lots. Those of us who don't frequently drive get some benefit from the roads, sure, because of the efficiencies of shops needing deliveries and whatnot, but not anything close to proportional to what drivers get out of it. And we accept this as the default way that things should be, whereas we assume that public transit needs to "pay for itself".

Absorbing bursts is one purpose for a queue, but often not the only or even most important one. Other reasons include:

Correctness reasons:

* Providing a durable history of requests that were sent

* Creating at-least-once semantics for important (e.g. financial) data

Scaling reasons:

* Allowing a shuffle between producer and consumer to change shard/key affinity (can be done with direct RPCs, but would need extra library support)

* Pipelining variable-cost requests so that consumers can self-rate-limit and stay optimally loaded

The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.

My favorite not-super-accurate mental model of what's going on with attention is that the model is sort of compressing the whole preceding context into each token. So the word "tell" would include a representation not just of the concept of telling, but also of what it is that's supposed to be told. That's explicitly what you don't want to cache.

> So if I were running a provider I would be caching popular prefixes for questions across all users

Unless you're injecting user context before the question. You can have a pre baked cache with the base system prompt, but not beyond that. Imagine that the prompt always starts with "SYSTEM: You are ChatGPT, a helpful assistant. The time is 6:51 ET on December 19, 2025. The user's name is John Smith. USER: Hi, I was wondering..." You can't cache the "Hi, I was wondering" part because it comes after a high-entropy component (timestamp and user name).

* You can use gazelle to auto-generate Bazel rules across many modules - I think the most up to date usage guide is https://github.com/bazel-contrib/rules_go/blob/master/docs/g....

* In addition, you can make your life a lot easier by just making the whole repo a single Go module. Having done the alternate path - trying to keep go.mod and Bazel build files in sync - I would definitely recommend only one module per repo unless you have a very high pain tolerance or actually need to be able to import pieces of the repo with standard Go tooling.

> a beefy VM to host CI

Unless you really need to self-host, Github Actions or GCP Cloud Build can be set up to reference a shared Bazel cache server, which lets builds be quite snappy since it doesn't have to rebuild any leaves that haven't changed.

...but why? You're begging the question.

If you can automatically update everyone including running their tests and making any necessary changes to their code, then persisting two versions forever is a waste of time. If it's because you can't be certain from testing that it's actually a safe change, then fine, but note that that option is still available to you by copy/pasting to a v2/ or adding a feature flag. Going to a monorepo gives you strictly more options in how to deal with changes.

> You literally wouldn’t be able to keep track of your BOM in version control as it obtains a time component based on when you built the service

This is true regardless of deployment pattern. The artifact that you publish needs to have pointers back to all changes that went into it/what commit it was built at. Mono vs. multi-repo doesn't materially change that, although I would argue it's slightly easier with a monorepo since you can look at the single history of the repository, rather than having to go an extra hop to find out what version 1.0.837 of your dependency included.

> the version that was published in the registry

Maybe I'm misunderstanding what you're getting at, but monorepo dependencies typically don't have a registry - you just have the commit history. If a binary is built at commit X, then all commits before X across all dependencies are included. That's kind of the point.

But also, you're conflating code and services. There's a huge difference between libraries that are deployed as part of various binaries and those that are used as remote APIs. If you want to update a utility library that's used by importing code, then you don't need simultaneous deployment, but you would like to update everywhere to get it done with - that's only really possible with a monorepo. If you want to update a remote API without downtime, then you need a multi-phase rollout where you introduce a backward-compatibility mode... but that's true whether you store the code in one place or two.

We used Bazel to maintain the dependency tree, and then triggered builds based on a custom Github Actions hook that would use `bazel query` to find the transitive closure of affected targets. Then, if anything in a directory was affected, we'd trigger the set of tests defined in a config file in that directory (defaulting to :...), each as its own workflow run that would block PR submission. That worked really well, with the only real limiting factor being the ultimate upper limit of a repo in Github, but of course took a fair amount (a few SWE-months) to build all the tooling.

> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.

It specifically doesn't mean "using an LLM as a code assistant". It definitely doesn't mean asking the LLM questions about code which you'll then use to write your own code. Those are LLM-assisted activities, and it's totally fine if you're using the LLM that way. But it's not what the term "vibe coding" means. "Vibe coding" is giving up on any pretense that you're in control, and letting the LLM take the wheel. It's fun for getting quick projects done, but it's also now becoming a distressingly common practice for people who literally do not know how to program in order to get a "product" to market.

The energy question is this: going from a 100kmh-due-north momentum to a 100kmh-due-south momentum via slowing, stopping, and accelerating again clearly takes energy. You can also switch the momentum vector by driving in a semicircle. Turning around a semicircle takes some energy, but how much - and where does it come from? Does it depend on how tight the circle is - or does that just spread it out over a wider time/distance? If you had an electric train with zero loss from battery to wheels, and you needed to get it from going north to going south, what would be the most efficient way to do it?

> The requirement is also that developers will request the signal. No scoping to developers that have a reason to care?

I don't see that requirement. Here's the sum total of the developer's responsibilities (emphasis added):

> A developer with actual knowledge that a user is a child via receipt of a signal regarding a user’s age shall, to the extent technically feasible, provide readily available features for parents to support a child user with respect to the child user’s use of the service and as appropriate given the risks that arise from use of the application, including features to do all of the following:

> (A) Help manage which accounts are affirmatively linked to the user under 18 years of age.

> (B) Manage the delivery of age-appropriate content.

> (C) Limit the amount of time that the user who is 18 years of age spends daily on application.

It would be nice if it had specific carve outs for things that aren't expected to interact with this system, but it seems like they're leaving it up to court judgment instead, with just enough wiggle room in the phrasing to make that possible.

If your application doesn't have a concept of "accounts", then A is obviously moot. If you don't deliver age-inappropriate content, then B is moot. The only thing that can matter is C, but I'd expect that (a) nobody is going to complain about the amount of time their kids are spending on Vim and (b) the OS would just provide that control at a higher level.

This seems... not terrible? The typical counter-argument to any "think of the children!" hand-wringing is that parents should instead install parental controls or generally monitor what their own kids are up to. Having a standardized way to actually do that, without getting into the weirdness of third-party content controls (which are themselves a privacy/security nightmare), is not an awful idea. It's also limited to installed applications, so doesn't break the web.

This is basically just going to require all smartphones to have a "don't let this device download rated-M apps" mode. There's no actual data being provided - and the bill explicitly says so; it just wants a box to enter a birth date or age, not link it to an actual ID. I'm not clear on how you stop the kid from just flipping the switch back to the other mode; maybe the big manufacturers would have a lock such that changing the user's birthdate when they're a minor requires approval from a parent's linked account?

That said, on things like this I'm never certain whether to consider it a win that a reasonable step was taken instead of an extreme step, or to be worried that it's the first toe in the door that will lead to insanity.

The current holder of that domain is using it to host a single page that pushes anti-vax nonsense under the guise of fighting censorship... but also links to the actual PuTTY site. Very weird mix of maybe-well-meaning and nonsense.