Gotta sell yourself to someone in this world. There’s no sense in demeaning someone about it.

Unfortunately, some of us are stuck in a country which is a Microsoft shop, which makes it next to impossible to get into a Linux job - especially an entry-level one (these are basically non-existent where I live). I've even considered moving to a place where Linux jobs are a thing (Europe), but that would mean learning the local language first and also already having sufficient professional Linux experience (no one would hire a foreigner for an entry level role when they could just hire a local).

So unless you've got any bright ideas, I'm stuck in this Microsoft job till someone comes up with some magical Linux roles, or I start my own Linux-based company and twiddle my thumbs because there's no customers...

> I feel that if you need to lie to people because of money

Then your beef is with capitalism, not Github/MSFT.

> Isn't that an accurate definition of what "loser" generally means?

"Loser" is a catch-all taunt that bypasses empathy. But certainly they might be 'in a losing situation', which is an important distinction.

> Except for the "disabilities" part, which is problematic to classify

Disability in this context is something intrinsic to the person (e.g., physically, mentally) that makes the employment process substantially difficult to engage with.

In addition to disability, difficulty can also arise do to any prejudice that might be levelled against them (e.g., ageism, sexism, junior vs senior, skin color, language skills, country of origin), as well as visa consideration, financial situation, etc. There's so many things that affect the risk calculus of changing jobs.

The engineers at github are getting paid $300k/year at SWE3 to do their job. I don’t think they lost at life.

Why bring people down so hard? That is really solid money and you can provide for a family, retire in your 40s, and it is work that does not destroy your body.

> lost at life

It's so refreshing to read such a truly philosophical insight.

GitHub: 60% of the time, it works every time.

As someone who is intimately familiar with GitHub’s data models, I wouldn’t say that replacing it is so technically trivial.

But even then, you are right that that the moat of social cachet and implicit trust is still more valuable than the moat of technical implementation.

True eventually, but not today

But to determine its merit a maintainer must first donate their time and read through the PR.

LLMs reduce the effort to create a plausible PR down to virtually zero. Requiring a human to write the code is a good indicator that A. the PR has at least some technical merit and B. the human cares enough about the code to bother writing a PR in the first place.

It's absolutely possible to use an LLM to generate code, carefully review, iterate and test it and produce something that works and is maintainable.

The vast majority of of LLM generated code that gets submitted in PRs on public GitHub projects is not that - see the examples they gave.

Reviewing all of that code on its merits alone in order to dismiss it would take an inordinate amount of time and effort that would be much better spent improving the project. The alternative is a blanket LLM generated code ban, which is a lot less effort to enforce because it doesn't involve needing to read piles and piles of nonsense.

I think most people are in complete agreement.

What people don't like about LLM PRs is typically:

a. The person proposing the PR usually lacks adequate context and so it makes communication and feedback, which are essential, difficult if not impossible. They cannot even explain the reasoning behind the changes they are proposing, b. The volume/scale is often unreasonable for human reviewed to contend with. c. The PR may not be in response to an issue but just the realization of some "idea" the author or LLM had, making it even harder to contextualize. d. The cost asymmetry, generally speaking is highly unfavorable to the maintainers.

At the moment, it's just that LLM driven PRs have these qualities so frequently that people use LLM bans as a shorthand since writing out a lengthy policy redescrbiing the basic tenets of participation in software development is tedious and shouldn't be necessary, but here we are, in 2025 when everyone has seemingly decided to abandon those principles in favor of lazyily generating endless reams of pointless code just because they can.

Banning all LLM code doesn't mean they see things in binary terms like that. There is nuance between "all code must have 100% test coverage" and "tests are a waste of time", for instance, but that doesn't mean a project that adopts one of those policies thinks the middle ground doesn't exist.

I can't imagine being someone like Andrew, or any BDFL of a popular open source project, and having to deal with folks like this. Imagine posting a timed output of your compiler on a thread about a similar language's slow compiler and having someone cite this as bad behavior.

Anyway, the clear absurdity of this particular post aside, it's not OK to call other people monkeys. I make no statement on the quality of their engineering. But they're people! I'd hope to see a quiet dignity from the Zig folks here. They've done so much excellent work, and I'm sure it's frustrating to see what software can be and then have it sharply laid against what software often is. But kindness is always the way.

Thanks to everyone involved with Zig for their work and love of software!

It's completely fine for someone working on a programming language that is useful for some of the same things as Rust to compare that language to Rust, including in ways that make the language not seem as good. Indeed, this is useful information for someone who is using Rust and is considering using Zig (or vice-versa), or who is new to both languages and trying to figure out which is better for their use case.