Live data from Hacker News

Zig quits GitHub, says Microsoft's AI obsession has ruined the service

theregister.com

401–410 of 641 posts

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#401

The edit history of the announcement is quite a ride: > [2025-11-27T02:10:07Z] it’s abundantly clear that the talented folks who used to work on the product have moved on to bigger and better things, with the remaining losers eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress [1] > [2025-11-27T14:04:47Z] it’s abundantly clear that the talented folks who used to work on the…

On the previous HN article, I recall many a comment talking about how they should change this, leave the politics/negative juju out because it was a bad look for the Zig community. It would appear they listened to that feedback, swallowed their ego/pride and did what was best for the Zig community with these edits. I commend them for their actions in doing what's best for the community at the cost of some personal me…

Well, no, they still acted based on the original ego/pride, they just changed blogpost to look different.

I mean, reason of "we don't want to be tied with direction MS takes" is good enough, not sure why they felt need to invent reasons and nitpick some near irrelevant things just to excuse their actions

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#403

Earlier quoted context omitted.

On the previous HN article, I recall many a comment talking about how they should change this, leave the politics/negative juju out because it was a bad look for the Zig community. It would appear they listened to that feedback, swallowed their ego/pride and did what was best for the Zig community with these edits. I commend them for their actions in doing what's best for the community at the cost of some personal me…

Well, no, they still acted based on the original ego/pride, they just changed blogpost to look different. I mean, reason of "we don't want to be tied with direction MS takes" is good enough, not sure why they felt need to invent reasons and nitpick some near irrelevant things just to excuse their actions

[dead]

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#404
post #16

Earlier quoted context omitted.

Not spending on maintenance is bad. Not spending on maintenance and spending gobs on something many people don’t want is far worse. It says we have the money, we just don’t give a fuck.

Isn't this SOP of Microsoft since forever? Tons of papercuts which really hurt, and tons of features nobody wants? I think this is the natural outcome of "chasing points" mechanic inside Microsoft.

For my money, the scorpion is halfway across the river and y’all are about to become the frog. I haven’t touched a windows machine in 15 years and I’d really like to continue that streak to the grave. Gaben is working hard to become my new favorite tech person by trying to claw gaming off of the PC. I really hope he wins.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#405
post #52

IMHO, the main advantage of github is that it is an ecosystem. This is a well-thought-out Swiss knife: a pioneering (but no longer new) PR system, convenient issues, as well as a well-formed CI system with many developed actions and free runners. In addition, it is best to use code navigation simply in a web browser. You write code, and almost everything works effortlessly. Having a sponsorship system is also great,…

> a pioneering (but no longer new) PR system having used gerrit 10 years ago there's nothing about github's PRs that I like more, today. > code navigation simply in a web browser this is nice indeed, true. > You write code, and almost everything works effortlessly. if only. GHA are a hot mess because somehow we've landed in a local minimum of pretend-YAML-but-actually-shell-js-jinja-python and they have a smaller or…

I used gerrit a bit at work but any time I want to contribute to OSS project requiring to use it I just send a message with bugfix patch applied and leave, it's so much extra effort for drive by contributions that I don't care.

It's fine for code review in a team, not really good in GH-like "a user found a bug, fixed it, and want to send it" contribution scheme

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#406
post #152

Earlier quoted context omitted.

> The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github I've always done it that way, and never got that feeling.

there's certainly a higher rejection rate for github PRs

correlation, not causation.

Lowest common denominator way will always get worst quality

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#407

Earlier quoted context omitted.

PR#1: dough PR#2: toppings You first send PR#1, then PR#2 on top of the first one. The diff for PR#1 will show dough stuff. The diff for PR#2 will show toppings in relation to dough. People can review them asynchronously. If you merge PR#1, PR#2 will automatically target main (that's where dough went) now. In this arrangement, I use to cross-mention the PRs by number (a link will exist in both). I also like to keep t…

> The diff for PR#2 will show toppings in relation to dough. The problem is the diff for PR#2 will show dough and toppings all mixed together. Unless you go into the commits view, but that's super tedious and it's easy to lose comments in there. It's kind of frustrating because there's very little required to make this work. All you really need is for Github to detect `Depends on #1` like it detects `Fixes #123`, and…

What do you mean by "mixed together"?

PR#2 will show only what changed between dough and toppings.

If you merge it, it will become part of PR#1. You turned the dependency into a single block.

So, if you don't want to mix, you should merge the dependency (dough) first to main (or whatever is your target).

Codeberg probably also supports the same thing, it's a git thing not a GitHub thing. That's why I'm saying it works exactly as expected. Git alone already supports dependencies, and GitHub just follows it.

To block the merge, you can make a workflow that turns PRs with dependencies into drafts. However, as it is a merge from one PR into another, I don't see the reason to. You can easily de-merge them if you need.

From the looks of it, it seems that you are branching at the wrong point, and creating two PRs to main, one of them containing duplicates. That's not what I suggested.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#408
post #318

Earlier quoted context omitted.

> Most devs don’t work at Google or contribute to Google projects, so there is no reason for them to know anything about Gerrit. Most devs have never worked on Solaris, but if I ask you about solaris and you don't even know what it is, that's a bad sign for how competent a developer you are. Most devs have never used prolog or haskell or smalltalk seriously, but if they don't know what they are, that means they don't…

These are all ridiculous shibboleths. I know what Solaris is because I’m an old fart. I’ve never used it nor needed to know anything about it. I’d be just as (in)competent if I’d never heard of it.

[deleted]

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#409
The reason is a bit strange. To me it seems as if Zig is just very opinionated. Personally I think the decision to move to Codeberg was made independently of Microsoft being a problem. I don't dispute that Microsoft is a problem; I just don't see many great alternatives to github either. Gitlab consistently is worse for me as a user.

I think the bigger problem is that these big megacorporations control so much. I find Google even more problematic than Microsoft these days in that regard. AI worsens this problem, but even without AI it already was a problem.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#410
post #167

Earlier quoted context omitted.

Maybe I have low standards given I've never touched what gitlab or CircleCi have to offer, but compared to my past experiences with Buildbot, Jenkins and Travis, it's miles ahead of these in my opinion. Am I missing a truly better alternative or CI systems simply are all kind of a pita?

I don't enough experience w/ Buildbot or Travis to comment on those, but Jenkins? I get that it got the job done and was standard at one point, but every single Jenkins instance I've seen in the wild is a steaming pile of ... unpatched, unloved, liability. I've come to understand that it isn't necessarily Jenkins at fault, it's teams 'running' their own infrastructure as an afterthought, coupled with the risk of bork…

Jenkins was just build in pre-container way so a lot of stuff (unless you specifically make your jobs use containers) is dependent on setup of machine running jenkins. But that does make some things easier, just harder to make repeatable as you pretty much configuration management solution to keep the jenkins machine config repeatable.

And yes "we can't be arsed to patch it till it's problem" is pretty much standard for any on-site infrastructure that doesn't have ops people yelling at devs to keep it up to date, but that's more SaaS vs onsite benefit than Jenkins failing.

Post reply on HN