If a human reads code, and then reproduces said code, that can be a copyright violation. But you can read the code, learn from it, and produce something totally different. The middle ground, where you read code, and produce something similar is a grey area.
Bad analogy, probably made up by capitalists to confuse people. ML models cannot and do not learn. "learning" is a name of a process, when model developer downloads pirated material and processes it with an algorithm (computes parameters from it).
Also, humans do not need to read million of pirated books to learn to talk. And a human artist doesn't need to steal million pictures to learn to draw.
> And a human artist doesn't need to steal million pictures to learn to draw.
They... do? Not just pictures, but also real life data, which is a lot more data than an average modern ML system has. An average artist has probably seen- stolen millions of pictures from their social media feeds over their lifetime.
Also, claiming to be anti-capitalist while defending one of the most offensive types of private property there is. The whole point of anti-capitalism is being anti private property. And copyright is private property because it gives you power over others. You must be against copyright and be against the concept of "stealing pictures" if you are to be an anti-capitalist.
For property to give you power, you need to concentrate lot of it, or own something expensive or exclusive. That's what capitalists do: a capitalist owns an expensive lathe, and you don't so you have no choice but to work for the capitalist on capitalist's terms (you can replace lathe with GPU farm for more modern analogy).
Owning a song, a book or a picture doesn't give you much power by itself.
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...
They could also just be people with bills to pay who are maybe faced with—by some accounts—a very challenging employment market. Or maybe due to disabilities they find the process of finding new work difficult or impossible.
That is fine, but they adopt or delegate corporate opinions onto others. I feel that if you need to lie to people because of money, your job is not honest. (I don't mean you; I mean people who need to do this because otherwise they may lose their job etc...)
Except for the "disabilities" part, which is problematic to classify, wouldn't your description broadly fit the word "losers"?
EDIT: I don't understand the downvotes. It's not a value judgement on Github employees, it's about the meaning of the word "loser". Go back to your teenage years. What's a loser? Someone, often through no fault of their own, keep being in a bad situation, having the "short end of the stick". What characteristically makes them losers is that they lack the audacity to snap out of it.
Isn't that an accurate definition of what "loser" generally means?
> 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.
Github is migrating from their old infra to Azure. Doing migrations like that is hard, no matter who you are. And from a business and engineering perspective I think it makes sense to leverage the economies of scale of Azure instead of GitHub running their own boxes.
Anyone being forced to use Azure has, at least temporarily until they can find a new job, lost at life, not necessarily through any fault of their own. The poor souls probably also have to use Teams.
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.
Spending your life working on making things worse (and knowing it) is pretty demoralizing. I know many people who have made the decision to take a pay cut or just quit when they realize that’s their job.
Sometimes those people aren't realizing that they're making things worse, they're just in a depressive spiral and can't see the other end, or see how much good is still being generated while other things are temporarily worse, or see that different tradeoffs have been made to make things worse in some ways and better in others. Just as people can delude themselves that they're always making a positive impact, people can delude themselves that they're making a negative one. The latter tends to be more costly, though, which can sure be annoying to those with a bias for a more cynical or pessimistic outlook...
Trying to ascribe positive/negative impact to strangers isn't usually a useful exercise, even if you have enough data to make a solid case. It can be cathartic -- imagine a different world where programmers making things worse would screw off and go do something else that's not programing! (I have a similar imagining, like of a world where programming is done by those who love it even outside of work -- even though I've worked with and helped hire excellent engineers who only treated programming as a job, they weren't my favorite to work with, and some were very much not excellent.) The best you can hope for is to trigger some self-reflection, and I do think that's important on an individual level. It's better to not make the world uglier, if you notice yourself doing so, and it's not just a distortion of your thinking, then you should probably stop, do something else, or figure out if it's at a level that you can compensate. A Richard Stallman quote I like:
"The straightforward and easy path was to join the proprietary software world, signing nondisclosure agreements and promising not to help my fellow hacker....I could have made money this way, and perhaps had fun programming (if I closed my eyes to how I was treating other people). But I knew that when my career was over, I would look back on years of building walls to divide people, and feel I had made the world ugly."
The absolute state of Github is that I use it dozens of times a day and it works flawlessly, for free, with intermittent outages.
Microsoft is doing more with Github than I can say for most of their products. I won't go to bat for the Xbox or Windows teams, but Github is... fine. Almost offensively usable.
Also, there have been increasing reports of open source maintainers dealing with LLM generated PRs: https://news.ycombinator.com/item?id=46039274. GitHub seems perfectly positioned to help manage that issue, but in all likelihood will do nothing about it: '"Either you have to embrace the Al, or you get out of your career," Dohmke wrote, citing one of the developers who GitHub interviewed.'
I used to help maintain a popular open source library and I do not envy what open source maintainers are now up against.
> GitHub seems perfectly positioned to help manage that issue, but in all likelihood will do nothing about it
I genuinely don't understand this position. Is this not what Github issues bots were made for? No matter where your repo is hosted, you take the onus of moderating it onto yourself.
Downtimes are an issue, it's why I jokingly mentioned it. Besides that I'm without gripe. Make Github a high-nines service and I'll keep using it until the wheels fall off.
My thinking as well. If people don’t like Microsoft, the last place to start their quixotic adventure would be GitHub.
I don’t use Azure or Windows. At work I push against Teams and actively try to persuade customers not to use Microsoft products. The reason isn’t even ideological - most of the time their products suck and the dev support is bad. VScode may be an exception, I’ll give them that.
Given the trajectory of Microsoft products it stands to reason Github’s future is uncertain. Also Git is ultimately a hosting platform that any competent software shop can recreate; the people behind the platform matter more than the platform itself.
So you are ok with 2FA, right? If you contribute code there.
Now - what if you are not ok with it? What can you do?
> Almost offensively usable
I think you conflate two points here. One is how useable github is. The other is: control. At which point are you no longer ok with what a private company does? This is not solely about Microsoft alone by the way.
Yes. Are you not? It's one of the most effective measures to prevent a whole class of supply chain attacks. On Github the 2FA is also flexible enough to allow non-hardware passkeys, so you can choose a privacy preserving option with good UX.
...so far... but the problems are noticeably increasing in frequency, especially in Github Actions, and most of those don't show up on the status page because they are so random (eg restart the ci pipeline and it works) It feels exacty like Github is slowly rotting from the inside and I guess the reason is that everybody is forced to work on pointless AI features so there's nobody left doing actually important feature and maintenance work.
> they are dispirited clock-punchers who don't care about their craft.
Interestingly that is synonymous with losers according the definition of it in gervais principle. Which weirdly makes being called a loser less of an insult. (More like realist)
I’m sure this isn’t directed at everyone that works at GH, but it would have been more tactful to fault the people making decisions. Those frustrations are real though.
"I also strongly believe that you should not be proud of working for Microsoft, and particularly on GitHub for the last 5 years. I truly am sorry but you need to be called out."
A blanket ban on LLM-generated code is a completely reasonable position. If someone couldn't be bothered to write the code, why should anyone else bother to read it, let alone merge it?
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.
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.
Usually I hate quoting "laws" but think about it. I do agree that it would be awesome if we scrutinize 10+k lines of code to bring big changes but its not really feasible is it?
> A blanket ban on LLM-generated code is at least arguably a reasonable policy.
No, I don't think it is. There's more nuance to this debate than either "we're banning all LLM code" or "all of our features are vibe coded".
A blanket ban on unreviewed LLM code is a perfectly reasonable way to mitigate mass-produced slop PRs, but it is not reasonable to ban all code generated by an LLM. Not only is it unenforceable, but it's also counterproductive for people who genuinely get value out of it. As long as the author reviews the code carefully before opening a PR and can be held responsible, there's no problem.
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.
A blanket ban is really the only sensible thing to do so that no time is wasted for both sides (contributors know upfront that there's no point trying to get an AI-generated PR accepted - so they won't waste time creating one, and project maintainers don't waste time reviewing what might be broken AI slop - even if some AI generated PRs would be acceptable from a quality point of view).
When there's a grey zone then there will be lots of pointless discussions like "why was this AI-generated PR accepted but not mine" etc etc...
Perhaps you misunderstood my comment. I'm not advocating for vibe-coded AI-generated PRs, and I do think that blanket banning them is pretty reasonable for the reasons you stated.
However, I don't think that banning all AI-generated code is reasonable. Having an LLM generate a couple of functions or a bit of boilerplate in an otherwise manually coded PR should not invalidate it from being accepted if it's helpful.
Given my own experience working on compiler stuff with LLM, I'd say it's a very good decision.
LLMs jump at the first opportunity to use regex for EVERYTHING instead of doing proper lexing/parsing, for example. You need to repeatedly tell it not to use regex. In the end you might as well hand write your code, because you actually know how it works, unlike a clueless LLM.
No wonder they moved to Codeberg. Those kinds of projects tend to do the ol' move to Codeberg for whatever reason. If I had to put an analogy to it, Codeberg is like Kick and Github is like Twitch.
More seriously: I probably wouldn't have called every single current employee of GitHub a "loser", but more because I think truly cool people don't define themselves by where they happen to work at any given time. I'm sure the vast majority of people at GitHub are just tech employees trying to earn a living and don't particularly care whether the Zig guy thinks they're cool or not. What actually matters is that GitHub is a big centralized platform run by Microsoft for their own ends, and it's good to be free of it.
Holy shit, some people in the Zig community are toxic af. By extension, this means the community itself has issues it needs to face.
Not only have some of these folks - including the creator - been shitting in Rust threads, but here they're in here shitting on the awesome engineers at Github for no reason at all.
Good god.
edit: this is written by Andrew, the creator. The culture is rotten from the head.
Their "VP of Community" wrote this in 2020: https://kristoff.it/blog/addio-redis/ I didn't come across it until 2022. Still, particularly that and other writing from him and others convinced me the Zig community is full of goobers. That's not so bad, I have my tastes in immature humor and can sometimes be a goober too, but the application in that post's clearly-marked over-the-top skit still is just bizarre and doesn't encourage me to interact with them. To be more fair to the author and the community though, especially with respect to this GitHub migration, his more serious writing is better: https://kristoff.it/blog/the-open-source-game/ (2021). Some nice things said about Rust and the Rust community, even. In that he outlines a core position of "software you can love" being what he wants to create and inspire people to create, and how tents like "big tech" and "open source" don't really cater to that. The migration off of GitHub is predictable in the sense that GitHub stopped being something a lot of people loved a while ago -- of course some still love it, this tent creates obvious tension. (Though I don't know that Codeberg is any better and worthy of love. A few libraries I use have migrated to it and it seems fine at least, though them using Anubis is annoying and I've gotten the fail page of "Internal Server Error: administrator has misconfigured Anubis." a number of times. It does not spark joy in me.)
someone called some indeterminate anonymous corporate group of people who actively participate in enshittification of a product “losers”. you call that specific private individual “rotten”.
Read this entire thread. There are over two dozen links with Andrew's own words and bullying behavior provided by other commenters.
This is only the billionth time he's said something like this. He's apologized for it in the past and said he'd change, but it clearly didn't stick.
He's a jerk and a bully like Linus.
This is the guy setting culture at Zig, which is undoubtedly why five people responded to me in this thread with homophobic remarks. His community feels emboldened to do that.
When your leader breaks the Code of Conduct and attacks people, it probably feels like a safe space for all sorts of hatred and vile behavior.
Totally toxic.
Andrew has had a chance to read this thread by now. He's had a chance to reflect on the awful things people have said. Ball's in his court.
This implies Zig culture is being poisoned by Andrew.
He's the leader, and everyone looks to him. If he behaves like an asshole, and few people call him out or hold him accountable, everyone else thinks that's okay. You then see other members of the community behaving in a similar manner.
Toxic culture breeds toxic behavior and people.
You don't see other open source communities doing this.
Like I said, "rotten from the head". The idiom is appropriate.
wow, and you’re still defending yourself with a lecture on how your words should be interpreted in such good faith. in this situation. and, to add to that, comparing to two dictators who separate children from their parents and close people in labour camps.
keep believing you fit the moral standard and insight to emotional nuance to impart your judgments onto others.
And a tu quoque without even knowing my opinion on the matter and calling me an enabler for calling out the irony of your responses, hiding your personal aggressiveness behind a veil of moral superiority. I will refrain from continuing on this thread, good luck with this pain you carry, I hope you find something positively creative to alleviate it.
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.
In what way is the tone of the linked messages not appropriate? Rust is a programming language, not a sacred object. It's fine to say that a different programming language does something better than it, regardless of whether or not you're the developer of that language.
To be clear I like Rust and use it frequently and have for about as long as it's been publicly released, whereas I have only played around a little bit with Zig and I suspect I won't like it as much as Rust even when it's feature-complete. But I don't like seeing an attempt to enforce a social norm that it's wrong to point out shortcomings of Rust, especially when it's aimed at people doing the interesting and valuable work of exploring other areas of the systems programming language design space that Rust is not doing.
Ziglang is a small organization supported by donations, Microsoft is one of the largest companies in the world. If anything, they're punching up.
Calling people losers isn't classy, but if I were a well-paid Microsoft employee I'd laugh all the way to the bank that some community funded purist called me that. If it's supposed to be bullying he isn't very good at it.
Hmm, that seems plausible, yeah. It's unfortunate munchler didn't say something like that. But it seems like now people on HN are dogpiling on this Andrew guy? I imagine he'll feel the same way reading this thread, won't he? Surely there's a solution for bullying other than more bullying?
Regardless, it's hard for me to imagine that many readers will find great intellectual interest in a long thread about what a terrible person Andrew is.
It is verification of attendance, specifically, that "endorses the culture of cheating... telling students they can't be trusted, and turning into yet another cheating challenge/task"? If not, what is fair game for verification, in the pursuit of finding students of integrity?
Finding students with integrity is hard now, because the culture is already full of poo.
But one starting point is to communicate that you expect and require integrity, explain what that means, and then expect it. Trying to make metrics or tests or whatever to detect, rate, rank, etc. it just turns it into a game, like the same load of poo.
Though here is one thing you can do. Explain that you expect integrity, and then watch the students raise their hands and ask how they will be tested on this. You say it's expected. Back and forth a few times, until eventually some of them start crying, and then their heads explode, because they can't figure out how to game that. Those students sadly were too far gone.
Then, after that first semester of integrity culture, some of the students who didn't explode will cheat, and they will be expelled with the fury of an angry god, and everyone on campus will know why. News stories will be written, word will spread, college guides will be updated. The next batch of applicants after that will have fewer cheaters than before, and will have disproportionately attracted students who aspire to integrity and who wouldn't have known to apply to this school before the news.
A school with an honor code that students and faculty take seriously wasn't that newsworthy decades ago, but it's news now.
> Explain that you expect integrity, and then watch the students raise their hands and ask how they will be tested on this. You say it's expected. Back and forth a few times, until eventually some of them start crying, and then their heads explode, because they can't figure out how to game that.
This assumes that the students are untrustworthy and the faculty/institution are ultimately trusted. In a world in which that is not true (such as the world that produces the article we're commenting on), and students sometimes encounter problems due to unclear expectations or vague criteria that are not the student's fault, it is not unreasonable for people to ask questions whose goal is to find out the actual non-vague criteria to avoid unpleasant surprises.
By way of one of many examples: many excellent classes encourage students to talk about assignments with each other, as long as the work they turn in is their own. Now consider what happens if a student accustomed to such a policy encounters a class taught with a different policy, where that policy has not been made clear in advance.
Honor codes and integrity are excellent things to enforce. Transparency and crystal-clear criteria are also excellent things to enforce. Not to allow gaming the system, but to ensure the system doesn't game anyone.
> This assumes that the students are untrustworthy and the faculty/institution are ultimately trusted.
True. This proposal requires expecting and requiring the faculty to have integrity.
And you really need the college/university as a whole to commit to this, not just isolated professors, partly so that there can be no confusion by students.
(Some battle-scarred faculty and grad students could tell speak of entire departments that need to be shut down completely, because the administration and faculty are too far gone. I think you could never do this with one of those departments. You'd only get posturing, and the same arrogant and underhanded behaviors as before, and students would briefly be a little confused, but quickly realize that the old sketchy game-playing is still fully on.)
OK, but it wasn't until functional programming came along that tagged unions were recognized as a natural way to implement sum types, which is how they are used in modern programming. The old idea of a "variant" has pretty much faded away.
Thank you for explaining this. I didn't even realize this was an Avalonia project until you pointed it out. I like Avalonia (and love .NET in general), but I think the messaging on this needs a lot of work. Avalonia is creating unnecessary cognitive dissonance by emphasizing MAUI, which is a competing project after all.
This is what mystifies me about this announcement. Avalonia already works fine on Linux, allowing anyone to build a cross-platform .NET GUI application.
MAUI is supposed to be a wrapper around native widgets. The fact that they had to use Avalonia under the covers to get it to work on Linux seems to defeat the point. (Avalonia is a complete UI toolkit, like Qt or Flutter, that owns the entire stack from XAML to pixels.)
> Instead of writing the type directly, we're calling pickType and using the type returned. The typechecker evaluates pickType True at compile time, sees it equals Nat, and then it knows you're saying myNat has type Nat.
But how does the compiler evaluate `pickType True` at compile time? Does the typechecker contain an interpreter for (some subset of) the language? It seems potentially circular for a compiler to invoke functions defined in the code that it's compiling.
Yes, the compiler contains an interpreter for the entire language, not just a subset. It is circular as you rightly point out, but there's no contradiction here.
Typically the interpreter limits itself to only evaluating pure functions or functions that do not perform any kind of IO, but in principle this restriction is not necessary. For example Jai's compiler allows completely arbitrary execution at compile time including even downloading arbitrary data from the Internet and using that data to make decisions about how to compile code.
The compilers for Zig, D, Nim, and perhaps other languages contain an interpreter for the whole language that can run at compile time. It's not circular--compiling code and executing code are two quite different things (the interpreter does not contain yet another parser--it works on the AST). You simply can do calculations the results of which can be used in compile-time only contexts such as initializers. The trick in Zig is that the compile-time interpreter supports types as first-class objects, so you can compute types and implement generics this way. In Nim, the interpreter supports computations over the AST. In D, types can be passed as generic arguments, and computed strings can be "mixed in" to the source code and compiled at that point (on-the-fly code generation).
https://en.wikipedia.org/wiki/Bitter_lesson
reply