It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways:
> The following are allowed.
> Asking an LLM questions about an existing codebase.
> Asking an LLM to summarize comments on an issue, PR, or RFC...
Like seriously, what's the point of explicitly allowing this? Imagine the opposite were true, you weren't allowed to do this - what would they do? Revert an update because the person later claimed they checked it with an LLM?
The Linux policy on this is much superior and more sensible.
> 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.
They should make FullstackLang. It compiles English in .md to machine code that can directly run on the specialized hardware it designs for it that you have to 3d print at runtime. Every program gets its own custom hardware. Composability and reuse be damned. Pay the token masters for every thought you have
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.
That's an ambitious conclusion, and not as overly so as some may think.
But I believe it is not the reason Rust adopted this policy, I think they just have a more basal and subjective dislike of AI irrespective of whatever truth you may have just cited.
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.
> I expect soon we will see Rust forks with a pro-LLM policy
I sure hope so. I expect the end result will disprove the following:
> The Rust team will never be able to catch up to them
The AI jackasses have been braying in this key for going on a few years now, and there hasn't been one single time any of this breathless noise has resulted in something meaningfully superior. It's time to put up or shut up. Enough bullshit talk. If you can vibeslop a better Rust (or whatever), JFDI and leave everyone behind.
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?
As someone who's vibecoding my own self-hosted language (via a typescript to c++ transpiler and bootstrap), I can tell you mainline commercial models like Opus 4.7 aren't quite there yet. I'm getting 10KB source files balloon into 80MB outputs for now.
The main problem is that the the problem space is vast and highly interconnected, the LLM needs to reason about the entire language every time it suggest an architectural change, but it can't, so it suggests local changes that make sense to me - a language hobbyist - then runs into much more difficult problems down the road.
Maybe Mythos with a lot of (competent) human hand-holding and pre-design can do it.
Here are the actual policies, not a comment:
https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol...
It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways:
> The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC...
Like seriously, what's the point of explicitly allowing this? Imagine the opposite were true, you weren't allowed to do this - what would they do? Revert an update because the person later claimed they checked it with an LLM?
The Linux policy on this is much superior and more sensible.
Does the policy fix the issue of many low quality PRs being submitted? Unlikely.
Will it fix a related but different problem? Likely.
> 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...
> ## 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.
They should make FullstackLang. It compiles English in .md to machine code that can directly run on the specialized hardware it designs for it that you have to 3d print at runtime. Every program gets its own custom hardware. Composability and reuse be damned. Pay the token masters for every thought you have
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.
That's an ambitious conclusion, and not as overly so as some may think.
But I believe it is not the reason Rust adopted this policy, I think they just have a more basal and subjective dislike of AI irrespective of whatever truth you may have just cited.
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.
> I expect soon we will see Rust forks with a pro-LLM policy
I sure hope so. I expect the end result will disprove the following:
> The Rust team will never be able to catch up to them
The AI jackasses have been braying in this key for going on a few years now, and there hasn't been one single time any of this breathless noise has resulted in something meaningfully superior. It's time to put up or shut up. Enough bullshit talk. If you can vibeslop a better Rust (or whatever), JFDI and leave everyone behind.
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?
As someone who's vibecoding my own self-hosted language (via a typescript to c++ transpiler and bootstrap), I can tell you mainline commercial models like Opus 4.7 aren't quite there yet. I'm getting 10KB source files balloon into 80MB outputs for now.
The main problem is that the the problem space is vast and highly interconnected, the LLM needs to reason about the entire language every time it suggest an architectural change, but it can't, so it suggests local changes that make sense to me - a language hobbyist - then runs into much more difficult problems down the road.
Maybe Mythos with a lot of (competent) human hand-holding and pre-design can do 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.