[flagged]
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?
LLM Policy for Rust Compiler
11–20 of 94 posts
Re: LLM Policy for Rust Compiler
#12[flagged]
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.
Re: LLM Policy for Rust Compiler
#13[deleted]
Re: LLM Policy for Rust Compiler
#14Re: LLM Policy for Rust Compiler
#15[flagged]
Re: LLM Policy for Rust Compiler
#16Earlier quoted context omitted.
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
Re: LLM Policy for Rust Compiler
#17[flagged]
> 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.
Re: LLM Policy for Rust Compiler
#18Here 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.
Re: LLM Policy for Rust Compiler
#19[flagged]
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.
Re: LLM Policy for Rust Compiler
#20[flagged]
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.