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

1–10 of 94 posts

Re: LLM Policy for Rust Compiler

#6

Post by giancarlostoro »

7e wrote: post #5

[flagged]

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.

Re: LLM Policy for Rust Compiler

#7

Post by ares623 »

7e wrote: post #5

[flagged]

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?

Re: LLM Policy for Rust Compiler

#8

Post by nmg »

> ## 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

Re: LLM Policy for Rust Compiler

#10

Post by voidhorse »

lifthrasiir wrote: post #9
ares623 wrote: post #4

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.

Post reply on HN