[amluto]

> GitHub is not perfect but I don't think it's "degraded faster" at all. It's _grown_ faster.

It’s grown in a way that degraded it and that required actual effort. For example:

- The fancy new diff viewer frontend that barely works. Someone wrote that code — it didn’t happen by itself.

- The unbelievably buggy and slow code review frontend (which is surely related to the diff frontend) was added complexity that did not need to happen. Its badness has nothing to do with how many users use it. It’s just bad in a no-scaling-involved way.

- GitHub actions. It’s … bad. I suppose there wasn’t a predecessor that was better.

> And it's had to expand into the AI field, which is not an incremental thing like "hey let's launch a new feature or better dashboards."

No, it did not have to expand into the AI field. A competent AI-free GitHub Core that could have an optional AI layer on top would have worked just fine if not dramatically better than the current mess.

(I say this as a paying user who will probably cancel soon. The Copilot reviews are kind of nice, but they’re not any better than a third-party system, and I’m getting sick of GitHub not working. Plus, the repos I’ve already migrated off of GitHub get to have nice non-AI things like gasp service accounts.)

[AlphaSite]

I knew a guy who worked on it tell me actions is just literally a fork from Azure Devops. Which is why it never really fit into GitHub.

[kdazzle]

I have heard this also. I still find it wild that Azure DevOps had that feature long before GitHub

[ragall]

> GitHub actions. It’s … bad. I suppose there wasn’t a predecessor that was better

There might not have been a predecessor, but it's been obvious for at least a decade that GHA are a very poorly designed programming language, yet nothing was done to improve. They introduced Github Apps that solve many of the issues with Actions, but that requires deploying a service and aren't anywhere near the ease of use of Actions.

[Simran-B]

Isn't it a dumbed down version of Azure Pipelines?

[ragall]

It depends on whether its authors were aware of Azure Pipelines and used them as a source of inspiration. Perhaps.

[amluto]

Amusing new observation due to today’s outage [0]: apparently GitHub never bothered to do the obvious optimization to the /pulls page: when you load it with the default “is:pr is:open”, they seem to be depending on their heavyweight search service, despite the fact that their normal API can enumerate open PRs just fine (and probably at dramatically lower cost to them). Sometimes the common case of a webpage should be simple instead of a relying on something fancy.

[0] Which has been ongoing for hours but hadn’t started when I wrote my comment. https://www.githubstatus.com/incidents/x69zbgdyfzg0

[kryogen1c]

> It’s grown in a way that degraded it

Im an outsider and a layman, so this might be totally off base, but...

The way I hear people talking about github reliability doesnt sound like scaling problems to me. If you drive 20 miles every day but then decide to drive 2000 miles and run out of gas, thats a problem of scale. If you drive 2000 miles and your engine explodes, thats a problem of design.

Maybe their design problems are being made evident because of sudden scale, but they're still design problems.

[IanCal]

I think the fair side of this is that you have to make tradeoffs when you design things. Scaling problems are design problems, but whether they were mistakes or not really depends on how predictable that scaling was.

Car analogies are typical, so I'll add in there.

My car can take the four of us, and we can load it up with things from the shops. I can put a bunch of heavy tins of food in there, or some DIY things, but if I put several tons of stones in the boot it'll totally fuck it up.

Is that a design problem?

Not really, it's a relatively cheap regular car, and it failed at a certain scale.

It would be a design problem if it were a flatbed truck, despite it being the same scaling that showed the problem.

Making my car resilient enough to take that weight would require tradeoffs that would either make it worse for other jobs I want it to do or at least add significantly to the cost.

This is similar in engineering software systems too, you can make it handle scaling up better, but this can require a much more complex architecture that may make it slower at smaller scales. It can make it more complicated to work with, add additional risks of failure as well.