> This policy is intended to live in Forge as a living document, not as a dead RFC.
Oh... I can’t say for certain who wrote it, and I won’t make any definitive claims - personally, I tend to think it was probably mostly written, or at least conceived, by a man - but this sort of phrase… I get a nervous twitch every time I see it, even though it’s actually quite a clever rhetorical device. Hell... Maybe I just need a break; I don’t know, since I’m starting to see LLMs everywhere...
But one of the reasons they switched was because the compiler upstream for the original language they used, Zig, wouldn't accept slop contributions they wanted to make for Bun perf. What will they do when they need to try to push a slop contribution upstream to rust?
At this point they will probably just fork yet again and maintain some vibe compiler.
The poor Rust team is outgunned: they are getting PRs of great complexity. They can't even tell if the code is good or not. LLMs can generate really good code and they can generate very poor code. Most of the code I've seen is actually pretty good, but featureful and complex, and humans don't have the brainpower to understand it all.
The Rust team needs LLMs to adjudicate LLM-generated code properly, but they can't afford them (there is no money in OSS) and they are afraid of being put out of a job. Thus this Luddite policy.
I expect soon we will see Rust forks with a pro-LLM policy, and if those forks have AI agents reviewing PRs, the main Rust repo. will soon be irrelevant and all development of any note will happen on the forks, as they accelerate in quality and features exponentially. The Rust team will never be able to catch up to them.
The term scope creep comes to mind. Programming languages do not need to grow exponentially 24/7, its okay to let it grow slowly and stay mature and secure. If Rust were too bleeding edge, the safety promises would corrode over time. I think a better use of some of those PRs is to focus on crates as proof of concepts for things that could benefit Rust if it were included either in the standard library, or just available as a crate you can use for programmer ergonomic reasons.
Rust is already well past 1.0. At best an LLM could discover a vulnerability (and the human using it can file a patch) or can help a human improve ergonomics.
LLM delusion is insufferable. If all it takes is tokens to make a significantly better in programming language in logarithmic time why hasn't anyone done it?
> This policy is intended to live in Forge as a living document, not as a dead RFC.
Oh... I can’t say for certain who wrote it, and I won’t make any definitive claims - personally, I tend to think it was probably mostly written, or at least conceived, by a man - but this sort of phrase… I get a nervous twitch every time I see it, even though it’s actually quite a clever rhetorical device. Hell... Maybe I just need a break; I don’t know, since I’m starting to see LLMs everywhere...
[delayed]
> ## Other organizations
> These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.
This section is an extremely useful reference
Github just won't respond at all.
Oh no where is Bun gonna be ported to next?
Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.
But one of the reasons they switched was because the compiler upstream for the original language they used, Zig, wouldn't accept slop contributions they wanted to make for Bun perf. What will they do when they need to try to push a slop contribution upstream to rust?
At this point they will probably just fork yet again and maintain some vibe compiler.
The poor Rust team is outgunned: they are getting PRs of great complexity. They can't even tell if the code is good or not. LLMs can generate really good code and they can generate very poor code. Most of the code I've seen is actually pretty good, but featureful and complex, and humans don't have the brainpower to understand it all.
The Rust team needs LLMs to adjudicate LLM-generated code properly, but they can't afford them (there is no money in OSS) and they are afraid of being put out of a job. Thus this Luddite policy.
I expect soon we will see Rust forks with a pro-LLM policy, and if those forks have AI agents reviewing PRs, the main Rust repo. will soon be irrelevant and all development of any note will happen on the forks, as they accelerate in quality and features exponentially. The Rust team will never be able to catch up to them.
The term scope creep comes to mind. Programming languages do not need to grow exponentially 24/7, its okay to let it grow slowly and stay mature and secure. If Rust were too bleeding edge, the safety promises would corrode over time. I think a better use of some of those PRs is to focus on crates as proof of concepts for things that could benefit Rust if it were included either in the standard library, or just available as a crate you can use for programmer ergonomic reasons.
It doesn't really read like a Luddite policy.
Rust is already well past 1.0. At best an LLM could discover a vulnerability (and the human using it can file a patch) or can help a human improve ergonomics.
LLM delusion is insufferable. If all it takes is tokens to make a significantly better in programming language in logarithmic time why hasn't anyone done it?
Would love to see that happen, personally. All this power being held back by red tape. We need to unleash the beast.
What do you think is stopping anyone from starting a fork right now? Is it a licensing issue?
Attention issue. They are desperate.