This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
AI & open source
What do you think about LLM's impact in software development?
Inspired by recent events in open source:
Bun's LLM-assisted rewrite
The Bun project was translated from the Zig programming language to Rust, mostly by LLM. This task usually takes months-to-years by hand (e.g. Rust to Zig rewrite), but with the LLM it took 11 days. Its success is debatable: the code isn't idiomatic Rust, and lines-of-code increased 67%, which suggests it will be harder to maintain, but it works (passes the thorough existing test suite), and the maintainer says it's going well in a blog post that provides more details.
In response, Zig's maintainer wrote a scathing blog post personally criticizing the Bun maintainer credited for the rewrite ("[he] was already writing slop well before he had access to LLMs"). Zig's maintainer is known for blunt strong opinions: he previously moved Zig off GitHub and the announcement was rewritten twice to be softer on GitHub employees.
Earlier, the Ladybird web browser was also rewritten in Rust mostly by LLM. This got less attention and controversy, probably because it was announced better, and the previous language was C++ so they got more sympathy (2-hour video on why C++ sucks).
Rsync's LLM-assisted bugs
Rsync's maintainer got accused of "vibe fuck[ing] up this software", and the discussion got very heated. He explained he has been using LLMs a lot because he's getting lots of vulnerability reports (see below). An AI-assisted analysis concludes the LLM did introduce bugs, although not more than the usual amount.
LLM slop contributions are overwhelming open source maintainers
Many projects are seeing a massive influx of low-quality contributions by inexperienced software developers and bots, heavily relying on AI. This has caused some to stop accepting any outside contributions, while others have added strict LLM contribution policies (see below).
Example: an LLM managed to implement an entire big feature, albeit incorrectly. The file headers also credit random people who it presumably stole code from, thankfully(/s) the LLM concluded there are no copyright violations.
Serious LLM-discovered vulnerabilities are also overwhelming maintainers
Among the slop contributions are actual vulnerabilities discovered with the help of the latest LLMs like Mythos. There's a vague background threat that open-source libraries will become too dangerous to use, but LLMs can also find closed-source vulnerabilities, so it's unlikely.
Cal.com has made their core codebase private and announced "open source is dead", but others point out this probably won't help them, and AFAIK this hasn't become a trend.
curl ended its bug bounty program because of an "explosion in AI slop reports", but still accepts reports and admits they have improved because LLMs have become good at finding vulnerabilities. Although Mythos only found one benign one, because curl is one of the most hardened codebases that exists. Still, legitimate (maybe-issue) reports have increased causing more work for the maintainers, so they're taking a vacation this month.
"Vulnerability Reports Are Not Special Anymore", written by a former security lead, explains that the recommended process to handle them has changed due to LLMs
Open-source LLM contribution policies
Due to the aforementioned slop contributions and/or general ideological reasons, many projects have banned LLM usage entirely, while others require it to be disclosed. Big list. Highlights:
Misc
Picrocrypt's maintainer quits open source because of LLMs: "I want to do something actually meaningful and innovative with my time and life, not command Claude like I'm speaking to a child who forgets something every ten minutes and makes an oopsies every twenty before breaking down every hour."
We mourn our craft: senior developer laments hand-writing code becoming obsolete.
The LLM Critics Are Right. I Use LLMs Anyway. This guy outright admits what most people quietly do: criticize LLMs while using them.
My opinions
For reference: I'm under 30 and have been writing code for most of my life. I've written open-source projects, although they're not popular enough to get LLM contributions. Today I work in formal methods (theoretical computer science). I've always expected my future to involve creating software.
I am sad and worried that software development is changing. I enjoy working with code directly and making it (opinionatedly) well-designed, writing prompts is less intuitive to me and it's harder to control the design. I worry if most of my time spent learning to code better has been wasted, or even my entire Computer Science career.
But software development is much more than writing code, and my specialization is much more than software development. Although I've intrinsically enjoyed it, to me, writing code has always ultimately been a means to an end. And now with LLMs I write code much faster and easier. I also still write lots of code directly, LLMs (even Fable/Sol) can't fully automate my work at least yet.
As I wrote before, in the long term I'm neither optimistic nor pessimistic about AI, but I think it's inevitable and most people should learn how to use it to their advantage. I think it should be possible for those who really despise LLMs to continue to do things manually, there should be a market for "hand-coded" software etc., but they will be at a disadvantage.
I share Linus's opinion that AI is a tool, clearly useful but can be misused or misapplied. I believe its future (at least near term) is for boring uncreative tasks. For example, right now LLMs excel at straightforward (not idiomatic) translation and research, but struggle with high-level design. They also suck at art (no good examples except shallow memes, this is my experience elsewhere) and creative writing. I believe AI's future shouldn't and probably won't be creating art, because humans intrinsically enjoy it and make it very specific to their personalities; but it will make tools that humans use for art.
Lastly, I believe that ideally everything digital would be free and its creators would be paid another way. This means I have no issue with LLMs training on open-source, except they also trained on copyleft (GPL) code, they should be open-source and open-weights themselves.
When I look at what AI has been doing to the emulation scene, I think it has been a net positive. You have some emulators like Yaba Sanshiro and Ymir where the devs have embraced it and game compatibility/feature development has skyrocketed. Sega Saturn has always had mediocre emulation and now it is rapidly improving.
Even for emulators where the devs don't want to accept AI code into the main codebase, people are creating PRs/forks with features that have been requested for years. You can now create a custom version of melonDS with built-in shaders, RetroAchievements, a Vulkan renderer for better Mac compatibility, and texture/sprite layer scaling. All a technical user needs to do is ask their copy of Claude/Codex to glue it all together. The end result might be a bit buggy, but emulation has always been buggy.
I can understand why maintainers are annoyed by these PRs, since they are essentially being asked to take on the maintenance of vibe-coded features. However, I think people should start seeing the PR tab on GitHub as more of an "optional feature list" where you just pick and choose whatever you want.
I believe the end result of this will be an increasing number of forks. You will have projects that are known as well-tested/battle-hardened, people will build AI-assisted forks on top of them, and some features that prove their worth will be merged back into the base project. In other cases, where a project never merges AI-created features, maybe because the devs don't want the maintenance burden or hate AI, most of the new development will likely happen in forks, and eventually one of those forks will become the version of the software most people use. From a user's point of view, the point of software isn't to be an artisanal work, the point is that it accomplishes a task.
I mostly agree with your points, except
Anyone completely vibe-coding a PR should submit a regular GitHub issue, since the maintainers could vibe-code it themselves, but more likely will have a usable implementation. A vibe-coded PR for a big feature can’t be merged without potentially making the codebase unmaintainable, so it’s really just an issue with a working example.
Creating a fork with the vibecoded change and linking it in the GitHub issue (for maintainers to get hints from and other users in the meantime) is preferable and good.
More options
Context Copy link
More options
Context Copy link
I think an equilibrium will be found (effort, human attention, bug fixes, value delivered, etc.). At my workplace, I did an analysis (after the VP of Ops blew up at the number of bugs since Claude adoption on my team) and I discovered the number of bugs introduced per release (bugs found after and due to release) has remained the same if not less, but because devs are so much more productive, we are releasing faster (+ delivering more features) and so the total number of bugs increase.
AI bears are too bearish, AI bulls are too bullish. And delivering immense value does not mean immense (or any) profit either. Buffet famously wrote "if a far-sighted capitalist had been present at Kitty Hawk, he would have done his successors a huge favor by shooting Orville down" because of how airlines famously destroy investor money.
Personally, AI means I can split up my time and participate in this forum instead.
More options
Context Copy link
Personally, I'm very bearish on all this. I think the buff LLMs give to serious contributors are minimal, while the buff LLMs give to spammers are... well, the largest buff they've received since the advent of the internet itself.
I think the effect of this is going to be competent people who were once enthusiastic and cared about software will say "Alright, that's enough. I'm out."
I know firsthand the buffs LLMs give at least on some projects are not minimal: simple "boilerplate"-y tasks, like translation (which is surprisingly common, e.g. implement this algorithm from a paper into code) and reification (e.g. mocks and tests).
Also, the latest LLMs have been discovering vulnerabilities and lower bounds to unsolved problems, and I suspect they will also discover novel optimizations, all which seem to rely on machine's ability to brute-force and reason unlike humans.
Like the internet, maybe they're a net negative in the long term, maybe in the short term due to projects overwhelmed by slop. But (moreso than crypto) they have some serious use-cases so can't be dismissed entirely.
More options
Context Copy link
More options
Context Copy link
Recently, I have tried to use LLMs to add features to open source projects.
Making an LLM write a PR which I would be happy to attach my name to is actually hard work. Sure, the agentic loop will generate code which does the job, but then I need to check corner cases. At the moment, I am still trying to figure out if there is not a neater way to implement what I want with less overhead, after all I do not want to settle the project with more technological debt than required.
On the other hand, I could never be arsed to write tests, and this is something where I do not care too much about code quality. If two tests could be combined in one to save a couple of lines, who cares. Even if there is the odd bug in a test case, this is still no worse than no test case.
Documentation is also something the LLMs have much more patience for than I do. Though I will need to think more carefully of how to name my examples when specifying the feature because these names tend to make it into the documentation.
And of course, there is a lot of code which does not need to be optimized for being maintainable. I have seen PhD students use LLMs write utilities which would seriously impress me (given my baseline expectations) if they were hand-written.
Of course, how much maintainability matters depends a lot on one's timelines. Still, submitting PRs full of AI slop with the excuse "don't worry about tech debt, the AGI will clean up the code really soon" seems like really bad style for interacting with human-maintained projects.
More options
Context Copy link
They almost certainly trained on AGPL code even, so by that argument, all users of them should have access to the source.
More options
Context Copy link
It will be strictly worse in all cases, for all users, all developers, all maintainer, and all licence holders for the foreseeable future unless there is a massive improvement in the tools. They are good enough to make things that are just bad enough to be an enormous pain in the ass, especially when people who think they know a lot more than they do are using them.
WITH THE MASSIVE EXCEPTION OF: It is wild to tell the robot to write me a little piece of shit that does some shitty little task where i don't care how it works and it doesn't need to touch anything. productivity app providers in shambles, etc etc.
There are definitely some stupid developers harming projects with LLMs by adding loads of unmaintainable spaghetti slop, but "strictly worse in all cases" is strictly wrong.
LLMs aren't capable of fully structuring a project on their own, but they're more than capable of implementing a well-encapsulated algorithm or throwaway script. Also, many real-world codebases are already spaghetti, but it's adequate especially for small projects: for example Undertale and Balatro, all of Undertale's dialogue is in one switch statement and Balatro has this monstrosity among many more bad design decisions. Would the median LLM-assisted developer write worse?
More options
Context Copy link
If AI programming was so awful for users and developers, nobody would be paying tens of billions of dollars for it.
Statements by the utterly deranged! I guess lots of people might be getting emotional about self-driving cars, car accident lawyers for instance or race car enthusiasts... The same goes for AI programming but that's no excuse to let it cloud judgement.
Here's a fact that sounds fake but isn't: the best AI developer (Anthropic) had less revenue than Ebay last fiscal year.
Yes, it was roughly $5B in 2025 to Ebay's $11B, also interestingly the best guess for Anthropics revenue in June 2026 was also $5B. Things are moving quickly and Anthropic is projected to have ~$60B in revenue over 2026 with error bars as low as $45B and as high as $80B. Putting it in the class of Goldman Sachs, Intel and IBM as far as revenue is concerned. And well, the straight lines on graphs interpretation makes this year to year change pretty interesting.
Is that with GAAP accounting?
Of course not, but neither is the comparison to ebay. There aren't audited numbers so we're all estimating based on available information.
"You really think a startup would do that? Just go on the internet and tell lies about their revenue!?"
I'm not the one who originally tried to make some point about what the speculative revenue tells us about Anthropic.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Going a little further back, in Jan 2024 Anthropic had $87 million ARR, by May 2026 they were at $47 billion ARR
Some have questioned this accounting, whether ARR is representative of realized revenue over the whole year. We shall have to wait for the IPO for more detailed accounting. But it seems likely that Anthropic is the fastest growing company in history.
Yeah, I am very interested in the IPO. OpenAI lost nearly 40 billion last year and may be undershooting its goals this year, which I don't think bodes well for the US frontier labs.
But Anthropic might not be fated to the same destiny as OpenAI - for one thing, it explicitly kept its hands away from the advertising cookie jar.
OpenAI may indeed be undershooting in ads. But do we really think the ad market for chatbots is a mere $5 billion? What does that even mean? At what point in time?
A lot of emotive language in the article...
If I go to the front page of Futurism, I find these article headlines about AI:
The only time when AI is good is when it's bad for US companies it seems.
If AI psychosis is so significant that it deserves a whole category of Futurism articles about it, surely that indicates there is some significant advertising power in AI, some ability to change minds? Only the technology hasn't been fully developed yet. And what about the google AI summary at the start of nearly all searches? There are ads above, below and within it. There are all kinds of effects going on, revenue shifting between Google Adsense and Search. I think it's a lot more complicated and a lot less one-sided than Futurism would have us think.
I am not OpenAI's top guy, I think the company is a negative force in the world and AI development is an extremely serious matter with the gravest possible implications for humanity. But this totally negative view that some outlets push is a distortion.
Case in point, the nearly 40 billion loss for OpenAI. That's true from a certain perspective but a good chunk of it is an accounting loss from the shift from non-profit to for-profit company, moving control around. That shift is reprehensible but means the 'true' financial loss is closer to $10-20 billion.
Where is the headline about AI disproving the Jacobian conjecture the other day? That's roughly Fields Medal worthy in mathematics, albeit of little practical relevance. These systems are extremely capable but that doesn't fit the narrative that the media wants. Journalists are extremely threatened by AI, as are media companies. Why would I want to look up articles and read them (let alone pay a j**rnalist!) when I can just ask an AI about OpenAI's losses? Why would a journalist want to get a real job when they could instead try to hyperstition an AI bubble into existence and stick it to their hated class enemies? Not all journos... but many.
I agree with Shrike on the other points, but to clarify a misunderstanding:
While very impressive, nobody is claiming that a counterexample to the Jacobian conjecture for N > 2 would have merited a Fields Medal.
Daniel Litt, probably one of the most AI-involved mathematicians right now, agrees that it would have been a notable accomplishment for a mathematician, but not anything close to a Fields Medal worthy achievement.
https://xcancel.com/littmath/status/2079091534159298769
Litt is almost certainly correct that "Fields Medal" is overselling it, but I think "very impressive" is still underselling it. This was roughly a top-50 open problem in mathematics, one famous for attracting flawed "proofs". A restricted version of the conjecture had been open for nearly a century before being proven. The full conjecture was open for over 80 years. One of the most successful 21st century number theorists had his math career derailed by spending his PhD on the Jacobian conjecture with unimpressive results.
I think my biggest reason for epistemic caution here is that this wasn't a case of "AI disproving the Jacobian conjecture", it's a case of "AI led by a Princeton math PhD disproving the Jacobian conjecture", and I haven't yet seen which half of that team was responsible for which ideas in the derivation. From a quick glance at Alpöge's dissertation and senior thesis, I guess he seems to be more of an Algebraic-geometry guy than an algebraic-Geometry guy, but he still seems to be comfortable with the sorts of algebraic geometry tools that were likely used to derive his example. It's possible that Fable did most of the heavy lifting and Alpöge's critical contribution was "being an Anthropic employee with unlimited Fable access", but it might not be a total coincidence that he's not a number theorist or a topologist or something.
More options
Context Copy link
More options
Context Copy link
My personal belief has actually been that the online ad market is inflated, so chatbots not having a high ad ceiling wouldn't surprise me.
True, there was some weird accounting there. What strikes me is that they made $13 billion but spent $7.5 billion on cost of revenue - inference, most likely - and nearly $6 billion in advertising. Or in other words, their business was not profitable before you factor in R&D and training.
I do think this is true, at least partially - I think that journalists were souring on Silicon Valley before AI kicked off, so some of them are going to be biased against it. But I also do think that OpenAI (and Anthropic) are more than happy to dangle substantially false narratives to promote their businesses - and these narratives flatter the interests of investors. In particular, I think that people underappreciated the massive difference between software and AI - the cost of providing software is vastly lower than that of providing compute. But I think there was insufficient appreciation of that with AI, although I do think that is now changing.
This is relevant insofar as I absolutely think investors could be wrong.
souring? They've openly hated Silicon Valley for a very long time.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Oh. RIP. "You were supposed to be the chosen one", or something.
Maybe it's my eternal grumpy old "real programmers should write in..." fart eyes biasing me, but every single major project written in Rust that I have tried so far turned out to suffer from the same problem as major projects written in Python and JavaScript did before: it doesn't crash, but it sucks in more subtle ways that make me think that (1) if the language didn't prevent that, it would probably crash every 5 minutes and (2) if it did that, its developers and defenders would at least realise how bad their program is. It's strange because when the "it's memory safe and allows you to focus on the important things!!!" language was Python/JS, the obvious theory to explain this was that the language enables incompetent programmers who are not actually up to the task of engineering big pieces of software; but Rust is not even particularly easy to write, and arguably harder than C++ (unless you fully commit to the early-2000s high corporate obnoxious_template_factory<namespace::bullshit_factory<allocator_factory<...>,...>> style). Still, the filter fails. Maybe the missing puzzle piece is just the AI: it has no trouble emitting walls of lifetime sludge that passes the compiler, but is no better at big-picture decisions than the Python script kiddie, all the while its script-kiddie-in-mindset handler looks at it and figures that because it is Rust and it runs, the program generated is definitionally beyond reproach.
This has been going on forever. What, you want to use assembler? Kids these days can't even be bothered to remember their opcodes!
The truth is that we have a larger demand for software developers than our pool of people who can write raw x86, asm, C, and even Python.
Obviously there is a correlation between competence and choice of language. If I have a field where half the pre-prints are written in LaTeX and half the pre-prints are written in Word, I would likely think "Uh-Oh" when I open a pre-print and see Arial.
Still, sub-par programmers can write sub-par code in any language you give them. I have seen physicists without a CS background trying to write C++, and generally go please for the love of God just use Python already.
Personally, I did ignore Python for my first decade of programming -- no Ce-sque syntax, indentation matters, much less dense than Perl were enough to convince me that it is obviously not a cool kid language.
Later I came around. There are tasks where it is the right tool for the job. And if you want to self-express, you can always
import functoolsor modify the methods of an object on the fly. (And yes, sometimes you run into cases where Python's "lol, don't worry about the implementation details" approach leads to stuff the programmer would not have expected, hiding details is a lossy process.)More options
Context Copy link
What's a concrete example of sucking "in more subtle ways"?
The most recent example I can think of is Zed, a "work with LLM agents" IDE written in Rust that has been getting a lot of traction (and seems to be the only way around to do this with a GUI if you don't want to touch Electron). I gave it about two days' college try since I'm on the market for a new IDE (after CodeLite got enshittified with a recent update). Specific examples of suck about it:
Quiet or inexplicable failures. If it doesn't like the way the LLM it connects to formats something, it either leaves you with an unactionable error message ("missing field 'path' in tool call") or outright does nothing (such as when it doesn't like the structured text format it gets back from the LLM it connects to for its "smart autocomplete" feature - a state that is indistinguishable to the user from "I failed to connect", "the suggested completion is empty" and "the model is still working"). To debug any of these things, you have to get the raw JSON data it received out of an undocumented sqlite file, and guess what the expected schema is, because that is also undocumented. (It's hard to figure out even from looking at the source, because the JSON data seems to be fed into the handling Rust class by some weird metaprogramming magic rather than an explicitly defined format.)
Sometimes parts of it, like the LSP integration, just stop working until you restart it. Again, no visual indication of failure state, the feature just doesn't fire anymore.
It tries to do something clever with pending edits, but there is no coherent underlying model. A lot of LLMs clearly assume that they can keep drafting and re-drafting an "edit file" tool call, like submit one that says "add a line saying X between the line that says A and the line that says B" and then follow up with "add a line saying X and a line saying Y between A and B". The latter fails because for the purpose of that tool the state is now A\nX\nB, but if the model tries to read the file again to get a consistent picture it still only reads A\nB.
Clearly there is lots of internal code duplication, resulting in non-orthogonal config duplication. There are separate configurations for the "agentic" LLM connection and the "autocomplete" LLM connection, supporting a slightly different subset of protocols, with slightly different design choices e.g. about whether you give the top-level URL of the API endpoint or the most specific one.
There is no build system integration whatsoever (even though this is the sine qua non that distinguishes an IDE from a fancy text editor), but the lede is buried about this. I get the sense that they want to have this eventually, but are just not too excited to work on it, while not wanting to pay the marketing cost of outright saying "we are not ready for prime time yet".
There is debugger integration, which is supposed to be able to do fancy modern things like letting you see variable values by hovering the variable in the source as you debug. This works about 10% of the time, again with no indication when it fails.
All of this hints at a level of engineering that, if it were C/C++, I'm sure would result in a program that is unusable due to segfaulting all the time, with a reputation to match. In Rust, it instead just keeps running, slowly piling the frustration on you, while the developers psychotically add one shiny new feature after the other and leave the occasional bug reports about the above to rot without a response (because who cares about one user's unverifiable report that some asynchronous thing didn't appear? It's not like they can bring receipts in the form of a stack trace, because there was no crash).
In my experience, subpar C++ code that has issues such as the ones you mention but doesn't segfault most of the time is the rule, not the exception. Chromium or VSCode are full of this shit. And hobby projects like Ladybird would become shit too if they had to deal with real world complexity over time. Hell C++ itself is a huge mess. Rust's main argument is that at least now messes aren't full of easily preventable security problems and races.
I get the want to have strong crash signals, I run into this issue quite a bit in my work, but to be fair Rust critics also hand-wring about the existence and widespread use of
unwrapwhen it's meant to create exactly the signal you are talking about here. There's no winning because no language is going to make subpar engineering good.I'm really suspicious of the tendency that seems to be emerging to pass the buck of how terrible at its job Software Engineering has been to LLMs and blame them for all the slop, when really they're just reproducing the mounds of subpar code flesh and blood people wrote by the bushel. But if that's the direction things are going anyways, the natural fix is formal verification, and Rust was just a light step in that direction.
More options
Context Copy link
In fairness, Zed is a new project, furthermore every failure you've described I've encountered some analogue in early (C++/TypeScript) VSCode (quiet failures, random things stopping, IDE edits corrupting source, duplicate config, build system was pasting JSON into the config that runs a shell script, debugger was a buggy mess).
I didn't even know VSCode contained any C++. GitHub says 96% typescript, which for this purpose is just another one of the languages that hide the badness of bad programs while also hindering their improvement by not offering the gold standard "stop what you are doing and fix this" signal that is the core dump.
Matter of fact, VSCode still sucks even now.
(I do think interpreted and "memory-safe" languages have a place in network-facing code, where a memory mismanagement crash is actually worse than general shittiness because it also often means the internet can execute arbitrary code on your machine. For localhost@localdomain computing, though, give me SIGSEGV over the constant slow demoralisation and gaslighting from software that is deniably bad any day.)
I think you do have a point that C and C++ projects are less likely to have "bad program" bugs like silent failures, because C and C++ developers must be competent enough and spend enough time to avoid fatal and hard-to-detect crashes. But I think anyone that competent devoting that much time would write comparable quality code in a more forgiving language. Maybe the version of Zed written in C++ wouldn't have its issues, but the version of Zed written in C++ doesn't exist, because a production-grade entire IDE is already ambitious, writing it entirely in C++ would be too overwhelming. Even for Microsoft, hence why VSCode outside its core is TypeScript.
Microsoft also wrote and maintains (and seemingly occasionally mostly rewrites) Visual Studio proper, though, and there are many other production-grade IDEs written in C++. Sublime Text, afaik, is C/C++ and has more than feature parity with Zed; CodeLite and Code::Blocks both are C/C++ and are also not lacking particularly much (though the latter is also kind of buggy and the former became enshittified in what seems to have been an overambitious rewrite). Rust is really not easier or faster to write, even if you suffer from a peculiar disease that makes you introduce memory-related bugs at a much higher rate than anything else.
The point I'm converging on is that C/C++ actually makes the Github community-driven development model easier, precisely because it makes bugs so apparent that you don't get away with tech debt. Perhaps the synthesis of my views and those of Rust acolytes is something like that there are multiple abstraction levels of "badness", and failures at each of them happen to correlate decayingly with failures at the higher levels. At level 0 you have local failures of consistent memory management, of the type the Rust borrow manager catches. At level 1 you have macroscopic failures of logic, including a big number of ones that turn out to involve the flow of data ownership around your program and may result in characteristic double-free or null-pointer errors of the type that crashes under specific circumstances to the surprise of the programmer. At level 2 you have even more macroscopic failures of program design, such as a fundamentally inappropriate modularisation of your program that causes you to repeat yourself, or not exposing a sensitive and fragile process (such as Zed's tool call parsing) that really ought to be exposed for diagnostics. Rust's compiler flags level-0 failures really well, thereby exposing and forcing the programmer to deal with level-1 failures; but it turns out level-1 failures, if not suppressed, are a good way to expose level-2 failures, so Rust actually increases the number of unaddressed level-2 failures. (In concrete terms, being flooded with Github bug reports that contain actual crash stack traces winds up forcing the developers to deal with level 2 if they want to stop the flood.)
Visual Studio is a better IDE on Windows for some projects like .NET, VSCode targets more OSs and languages/frameworks.
Sublime Text doesn't have feature parity with Zed without plugins, which are written in Python. Here's a comparison on Zed's website, which is obviously biased but still true.
To a programmer trained in both I think this is true, but there are still two major benefits: it's more fun, and it guarantees zero undefined behavior if following basic rules (which is important for security, apparently even in an IDE because of supply-chain attacks). Meanwhile, they can write Rust code that is high quality like C++ (e.g. doesn't silently fail) as long as they plan ahead like C++ effectively requires them to. And even though C++ effectively requires planning ahead and Rust doesn't, C++ doesn't really encourage it, so I don't think it's less likely they would in Rust ("requires" = for a while your code compiles and runs OK, but eventually it randomly crashes in ways that are a nightmare to debug, and by then it's too late).
C++ doesn't make memory safety bugs apparent, often undefined behavior bugs (like race conditions) only trigger in rare circumstances.
But your main point, I also don't think C++ makes "bad code" bugs like silent failures more apparent than any other language. Rust does require more level 1 bug-fixing in exchange for eliminating level 0 bugs, but level 2 bugs are addressed completely outside of code, most commonly by planning a feature before writing any code, so the time and effort spent wrangling the borrow checker shouldn't affect them.
Most C++ projects on GitHub are better I think primarily because 1) developers who manage to ship C++ are experienced and skilled enough to avoid those bugs, while less experienced developers give up and/or choose other languages, and 2) projects are usually written in C++ if they're well-speced or exist in other languages, experimental projects are usually written in higher-level languages.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
VSCode might suck, but I still prefer using it (and a ton of plugins) for java development over using Eclipse.
I wish I could get an IntelliJ license at work, but it is not to be.
If you're willing to pony up for your own personal license (which is much cheaper than what JetBrains charges enterprise customers) the license explicitly allows you to use it at work:
https://sales.jetbrains.com/hc/en-gb/articles/207240855-Can-I-use-my-personal-license-at-work-and-at-home
and
https://sales.jetbrains.com/hc/en-gb/articles/206544399-Can-my-company-use-my-personal-license
That's nice of JetBrains, but my employer explicitly does not allow bringing your own software.
More options
Context Copy link
You also get a discount the longer you subscribe. My all products license costs me ~20€ per month right now.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Rewrites are something LLMs appear to excel at. I've done a few already and the results have been amazing. Simple stuff like rewrite one off Python scripts in C++ so they use 1/10th the space and time to larger 'port this ancient codebase to Rust' stuff have all been fruitful. The fact that there's no library for whatever doesn't matter, the LLM can just bang one out in any other language.
They work well when there's an existing battery of unit tests but even in spots where the coverage has been weak, sitting down with the LLM and contriving tests to gain confidence has been a real unlock.
It begins to suggest the code itself is not really the value. The value is in the specs, the protocols, the tests, the API. Everything in between can get conjured up as needed.
I've seen some really obnoxious slop submitted to open source projects and I get the kneejerk backlash, but as a maintainer myself I start to get annoyed when people open issues that an LLM could have solved immediately.
More options
Context Copy link
I actually like full bans on paper. Not because they will work, but because if someone dumps something low quality that has the smell of AI, you point at the rules and don't engage further.
For people who do good work and use AI as part of it, it can be a don't ask, don't tell sort of situation. And it's also a not-so-subtle reminder not to paste a wall of ai slop into the comments section.
This is something I truly don't understand. Why do people who clearly aren't bots on reddit still keep writing their posts and comments with AI when it provides no value for them or the readers (and will get the posts removed)?
I think it's a similar question to "why do people who clearly know the difference still don fake Prada/Gucci/Rolex apparel". To a lot of people, not being able to "write good" is a lifelong source of feelings of inferiority. AI posting both offers the promise that they can finally get some of the respect that the verbally gifted command (whether justifiedly or not) for themselves, and a bit of a sense that they are getting their cheeky revenge on the system that was keeping them down.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Another I'd like to point out is WINE. WINE already had a strict policy prior to LLMs in that contributors could not have previously worked on Windows at Microsoft, could not have ever so much as looked at any Windows source code leaks, and could not so much as even looked at the source code for ReactOS (a project for making an open source Windows clone) in case any contributors to that project ever worked on Windows at Microsoft or ever looked at a Windows source code leak.
This stance by Codeweavers (the maintainers of WINE) is because they fear their entire project (and therefore their entire business) being shut down by litigation from Microsoft. It's interesting to me that they still see copyright of LLM-generated code as potentially making their project no longer qualify as clean room reverse engineering, while the rest of the industry has effectively pretended that copyright no longer exists even though LLMs can produce the code of open source projects (or the entirety of a Harry Potter book) verbatim: https://arxiv.org/abs/2601.02671
I'm curious if there's going to be a big lawsuit at some point that completely upends LLMs due to copyright issues that will scare a lot of companies that were previously on the "LLM all the things" train.
One major reason for clean room is that when trying to reimplement a fully-compatible alternative, it's inevitable that some of the code will end up very similar to the original, or even the same. By using clean room, you can establish the creation of an entire new copyright on the work even if it's the same. It's like if two photographers take the exact same photo at the exact same time they each own their own copyright to their respective copies.
On the other hand, for something to be considered infringing in general, it actually has to be shown as a derivative work in the first place. Meaning it has to look similar to the existing work. You can argue abstractly that AI is a plagarism machine, but unless you can point to the part that was stolen (which has happened on a few occasions in the past, but not many) then the courts will tell you to pound sand.
More options
Context Copy link
There was a big controversy over chardet's relicencing, which led to this satirical website claiming to sell delicencing any open source project through clean room implementation by LLMs.
I think there is going to have to be a reckoning. Some confrontation that settles whether copyright is dead letter or not. One might think it's ridiculous to try and attempt to regulate the technology to enforce these norms and totally impractical, but that is what happened with the internet, with the mixed results we know of today.
The main difference I see is that this time, the AI companies are setting a red carpet for the regulators whereas the internet companies were a little bit more circumspect originally. I remember all the hand-wringing about the DMCA, but eventually the Facebooks and the Googles were all too happy to have their section 230 special status.
I think the topline kind of misses the nuance of the situation. If you looked at the code the change wasn't really a refactor or rewrite of the original thing, but basically an entirely new vibe coded package wearing the skin of the old one. I think it's in very poor taste to do that because it's going to break the users, but legally I think there's a decent argument that it's not a derivative copyrighted work.
Is it even possible for LLMs to do clean room implementation of code that, if it is a popular open source library, must have been in their training data? Or rather, since they don't have personhood, can you, in a clean room implementation, use tools that have been made using the very thing you're claiming you have no exposure to?
In a funny twist of fate, it may end up that the only way to protect yourself from having your licence stripped is actually to publicize your code. But really we have not the faintest clue how judges will see it.
There are 2 factors here:
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
WINE specifically is in a bit of a 'Caesar's wife must be above reproach' situation: there's a lot of possible futures where Microsoft wants to crush them, they're absolutely critical for mainstream Linux success, and even if they're in the free-and-clear legally, they have to be able to believably tell users that they'll be clear-and-free legally.
There's definitely groups interested in trying to bring copyright lawsuits, including some that have settled, but they're mostly limited to the input side. Getting a hook in on the output side seems naively like it would be rougher, especially given the gimmicks that the authors of that paper have to put in, but something something Musk Cross The Delaware.
This seemed more true in the early 2000s, when the desktop ruled supreme and most desktop software used the Win32 API.
These days, decidedly less so. Most software seems to be based on some toolkit which offers cross-platform support. Desktops lost a lot of relevance to both mobile and web apps. Antitrust bureaus are just waiting for Microsoft to try to sue WINE. (Well, the EU at least. The current US administration would probably be ok with them doing whatever as long as the bribes kept coming.)
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link