Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM Policy for Rust Compiler

github.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: LLM Policy for Rust Compiler

#51

Post by sheept »

noobermin wrote: post #30
voidhorse wrote: post #10

Earlier quoted context omitted.

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.

Is there a citation for this? This was my suspicion but it's quite amazing if this was the actual reason for the bun spectacle

No, they've explicitly denied it.[0] However, they do regularly dig at how much faster their fork is[1][2] that they can't merge because of Zig's AI policy.

[0]: https://x.com/jarredsumner/status/2051600118886138262

[1]: https://x.com/bunjavascript/status/2048427636414923250

[2]: https://x.com/jarredsumner/status/2053050239423312035

Re: LLM Policy for Rust Compiler

#52

Post by ZeroGravitas »

tick_tock_tick wrote: post #42

Some of these are just straight up unhinged. > Using an LLM to discover bugs, as long as you personally verify the bug, write it up yourself, and disclose that an LLM was used. What are they going to do go back and reject a bug if someone later admits they found it with an LLM? Honestly they and most other project would probably be better off just ignoring the situation until norms start developing.

They're trying to avoid a Boy Who Cried Wolf situation.

If they get swamped with 100 bugs that turned out, after they investigate them to be hallucinations then it's likely they will ignore or lose in the noise a real bug.

A llm generated bug that pretends it was a human created bug would be trying to abuse that presumption of validity, and therefore considered a dick move.

Re: LLM Policy for Rust Compiler

#53

Post by dgellow »

davesque wrote: post #36
mw888 wrote: post #18

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 serio…

It feels telling that it reads like university course guidelines.

What do you mean?

Re: LLM Policy for Rust Compiler

#54

Post by dgellow »

staticassertion wrote: post #39

This policy is straightforward and shouldn't be particularly controversial (I'm sure it will be bikeshedded to death though). It basically bans the obvious stuff ("don't just drop LLM generated comments onto PRs") and allows the important stuff like LLMs writing code so long as you disclose. edit: Wow people did not read the policy. It's literally just "if you use an LLM you are responsible for it, we will reject low…

The discussion thread in the PR is also interesting to got through, lots of people concern in the HN discussion are already well discussed there

Re: LLM Policy for Rust Compiler

#55

Post by dgellow »

staticassertion wrote: post #41
lifthrasiir wrote: post #9

Earlier quoted context omitted.

Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.

> even when the rust-lang/rust repository itself largely forbids vibe coding. This policy does not seem to forbid vibe coding?

I read it as a hypothetical

Re: LLM Policy for Rust Compiler

#57

Post by bcjdjsndon »

MaulingMonkey wrote: post #26
mw888 wrote: post #18

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 serio…

> Like seriously, what's the point of explicitly allowing this? Explicit permission can be useful to preemptively cut off some questions from well meaning people who, acting in good faith, might otherwise pester for clarification (no matter how silly / "obvious" it might otherwise be), or get agitated by misconstruing an all-banned list as being an overly verbose "no LLMs ever" overreach. > It's in-line with the 'nan…

> If you're steeped deeply enough in that NDA-preserving culture, a reminder that you've switched contexts might help when common sense proves uncommon.

What?

Re: LLM Policy for Rust Compiler

#58

Post by bcjdjsndon »

davesque wrote: post #35
vintermann wrote: post #28

Earlier quoted context omitted.

> Like seriously, what's the point of explicitly allowing this? I would have LOVED if the university course I took last winter had this. I had to take a very paranoid attitude to what was allowed. What they're trying to avoid is a lot of unnecessary conflict with zealous anti-AI people calling for your exclusion for admitting to doing these things. There are people who would ban this too.

So then the Rust maintainers are going to give you an F on your report card?

Try using allman braces and see how far you get on a basic issue like that

Re: LLM Policy for Rust Compiler

#59

Post by lifthrasiir »

staticassertion wrote: post #41
lifthrasiir wrote: post #9

Earlier quoted context omitted.

Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.

> even when the rust-lang/rust repository itself largely forbids vibe coding. This policy does not seem to forbid vibe coding?

It does in the narrower sense of vibe coding (as opposed to more general agentic coding, which is also called vibe coding from time to time...).

> Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure.

Vibe coding (in its original meaning) would have hard time arguing it's of high quality.

Post reply on HN