So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?

▲

f33d5173 2 hours ago | parent | next [-]

Rust is a significantly more mature language. Adoption of zig has to be done on the assumption that the language will significantly improve as your project evolves, and if those improvements don't agree with your project's goals you're in something of a lurch. Rust is basically finished and adopting it has to be done on the assumption it won't change very much. I don't know what their initial logic for adopting zig was, but I think porting to a more mature language was inevitable, unless by some miracle zig happened to rapidly mature in exactly the direction they wanted,

▲

petre 3 hours ago | parent | prev | next [-]

C obviously.

	▲	wg0 3 hours ago \| parent [-]
		I was hoping bash because why not. It's AI that has to work and maintain anyway and Anthropic employees aren't limited by 5 hour 7 days limits anyway I suppose.

▲

postepowanieadm 2 hours ago | parent | prev | next [-]

Perl

▲

echelon 3 hours ago | parent | prev [-]

Rust is legit one of the best languages to "vibe code" in.

The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.

▲

J_Shelby_J 14 minutes ago | parent | next [-]

Downside: CC and Codex will write, compile, and fix in a loop until it has a monstrosity rather than designing something smarter.

▲

wg0 3 hours ago | parent | prev | next [-]

This could be a subjective feeling with no real data to back it up.

People say same about Go as well that it's type system and limited feature set makes it the best AI friendly language but there too, it just seems like a hunch rather than a proven fact.

▲

treyd 2 hours ago | parent | next [-]

The thing is that this argument doesn't work with Go because its type system (and the whole language, really) is much less expressive and compiler gives a lot less feedback to the LLM. So it tends to have to write more unit tests and do more cycles of testing (and spend more tokens) to get it right.

▲

wg0 2 hours ago | parent [-]

The argument about type system is absurd anyway. The types in a program aren't a universal vocabulary that the LLM would already know about like the words of English language. They are unique to each program and domain so an LLM can't be better at it.

Let me elaborate further - it's like the proficiency of LLMs in writing English vs writing Sawahili or Kurdish.

The types of a program are like Swahili or Kurdish etc even worse because those languages still have sizeable chuck on the Internet and digital archives but types of a program are very specific to it.

	▲	treyd 2 hours ago \| parent [-]
		Studies have shown that natural human languages are all more or less equally expressive in terms of bits per second while speaking. There's lots of different ways they can be structured but they tend to follow common rules that have been well-characterized by linguists. They can be used to describe formal mathematical statements, but are not rigorously formal languages themselves. Programming languages, in contrast, are constructed and vary much more in their designs. They are formal languages, making them closer to math than spoken language. LLMs being able to describe concepts more thoroughly and precisely through more expressive semantics obviously makes some languages more suitable than others. The type system of a language is just one aspect of it that allows the language to provide guarantees to the LLM (and the user) about correctness of the code it's writing. I am not speaking about specific types in specific programs. I am talking about the ability to describe complex constraints that LLMs (and humans) end up using to make writing correct code easier and more productive. Some programming languages absolutely are more effective at this than others, and that's always been true even before LLMs.

▲

Onavo 3 hours ago | parent | prev [-]

If we are gonna go down that rabbit hole, then the natural conclusion is Haskell.

	▲	boxed 2 hours ago \| parent [-]
		Which seems pretty reasonable tbh. Claude Code is amazing with Elm in my experience.

▲

nvader 3 hours ago | parent | prev [-]

Excellent comment.

As a downside, the compile time is somewhat offset once you're using agents (and especially parallel agents) anyway. Since all of your edits cost a round-trip API call to a third party server, you can accept a slightly slower compile step.