I suppose Go programs are slower than the equivalent thing in C or C++, but I'm not sure that's a very relevant comparison in most cases today (how many new things being written would choose those languages).

Obviously it's not easy to move the whole language of a big codebase, but I feel a lot of this stuff (fiddling with GC, JITing, type hints, and I'm dubious about the free-threading stuff) tries to take Python somewhere it isn't really good at, and if that's what you want, you really want a different language.

Not familiar with Zig but AFAICT `inline for` is about instructing the compiler to unroll the loop, whereas `template for` means it can be evaluated at compile time and each loop iteration can have a different type for the iteration variable. It's a bit crazy but necessary for reflection to work usefully in the way the language sets it up.

Because ARM nodes save you a bit of money (they're cheaper but a bit slower, maybe you end up saving 20-30%) but the move isn't trivial for many tech stacks. When you try it you find you have some Python dependency with a C bit that doesn't have an arm wheel, or your browser automation can't run Chrome on those nodes (there isn't a linux/arm64 build of it). If you're using Go you can cross-compile, although it will likely fail without explicitly disabling cgo, and do you know what the consequences of that are?

Basically it very often ended up being more trouble than it was worth.

Chrome seems to be ~404MB installed on here; that is conspicuously missing from the comparisons here to Docker containers which do account for more or less the complete runtime.

Cheap money went away which caused companies to start asking hard questions about productivity and how much those dedicated managers were contributing.

Having said that, I really can't believe that either Trump or Starmer will give a shit about this, especially given the recent friction in that relationship.

I do think it's just an awkward problem to solve though, because it essentially devolves to needing to run the entire system somewhere else, which is why every system I've seen like this ends up being trial-and-error.

M series Macs are still very much a work in progress. I'm typing this on one, in Linux, so plenty of things work, but not for example USB-C output to an external display, and a lot of the processor power level / suspend stuff is still not fully there so battery life is quite a bit worse, especially when suspended. I think the situation is rather worse on the latest generation hardware, too.

With that set, I wasn't proposing a set of totally independent services to be grouped together, I was talking about a set of things that I think represent pretty core services for Github users. If Git is dragging the rest of those down, fine; PRs are useless without it. In fact it is worse than some but it's not the worst of that group, and it is still a lot better then the dregs of Actions and Copilot.

Having said that, the numbers are of course terrible, two nines on a couple of things and one on everything else would be bad for a startup, it's an utter embarrassment for a company that's been doing this over a decade.

What I would like to see is a combined uptime for "code services", basically Git+Webhooks+API+Issues+PRs, which corresponds to a set of user workflows that really should be their bread & butter, without highlighting things you might not care about (Codespaces, Copilot).

My wrists, conversely, are fine, but I suppose I rarely use it in a 'classic' desk position that would cause that.

Yes, agreed on that. I'm not sure I'm clear how this really helps that; I suppose it's a frontend that they don't have, but there are a bunch of those already.

It doesn't seem to help them control the _actual_ AI, i.e. the model, which still has to come from somewhere.