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

If you're going to vibe code, why not do it in C?

stephenramsay.net

Post reply on HN
Print view View original

141–150 of 626 posts

Re: If you're going to vibe code, why not do it in C?

#141

Post by IshKebab »

jmull wrote: post #49
stared wrote: post #5

There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…

Rust doesn't prevent programs from having logic errors. If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.

> Rust doesn't prevent programs from having logic errors.

Nobody ever claimed that. The claims are:

1. Rust drastically reduces the chance of memory errors. (Or eliminates them if you avoid unsafe code.)

2. Rust reduces the chance of other logic errors.

Rust doesn't have to eliminate logic errors to be a better choice than C or assembly. Significantly reducing their likelihood is enough.

Re: If you're going to vibe code, why not do it in C?

#142

Post by IshKebab »

vbezhenar wrote: post #37
stared wrote: post #5

There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…

Why Rust? Haskell is gold standard here.

I would think Lean and other formal languages are the real gold standard.

But none of them really have enough training data for LLMs to be any good at them.

Re: If you're going to vibe code, why not do it in C?

#143

Post by wizzwizz4 »

unethical_ban wrote: post #132
jmull wrote: post #49

Earlier quoted context omitted.

Rust doesn't prevent programs from having logic errors. If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.

This is objectively wrong. You can't get a gutter ball if you put up the rails in a bowling lane. Rust's memory safety is the rails here. You might get different "bad code" from AI, but if it can self-validate that some code it spits out has memory management issues at compile time, it helps the development. Same as with a human.

> You can't get a gutter ball if you put up the rails in a bowling lane.

Sure you can. It's difficult, and takes skill, but it can be done.

Re: If you're going to vibe code, why not do it in C?

#144

Post by 9rx »

zdragnar wrote: post #117
nialv7 wrote: post #83

Earlier quoted context omitted.

But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.

This thread moved the conversation away from the posted article quite a few messages ago. First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's…

> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.

Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.

But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?

Re: If you're going to vibe code, why not do it in C?

#145

Post by sramsay »

jrochkind1 wrote: post #32
fantasizr wrote: post #27

I've wondered what vibe codings impact is to language development, whereas C vs LISP had their tradeoffs when deciding what to use. If everything is vibecoded (not saying it will be) everything probably normalizes to javascript

That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be? I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)

Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?

None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).

It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.

Re: If you're going to vibe code, why not do it in C?

#146

Post by IshKebab »

doug_durham wrote: post #85
raphlinus wrote: post #71

There's a straightforward answer to the "why not" question: because it will result in codebases with the same kind of memory unsafety and vulnerability as existing C code. If an LLM is in fact capable of generating code free of memory safety errors, then it's certainly also capable of writing the Rust types that guarantee this and are checkable. We could go even further and have automated generation of proofs, either…

Proofs of what? "This new feature should make the 18 to 21 year old demographic happy by aligning with popular cultural norms". This would be difficult to formalize as a proof.

In this context it's proofs of properties about the program you're writing. A classic one is that any lossless compression algorithm should satisfy decompress(compress(x)) == x for any x.

Re: If you're going to vibe code, why not do it in C?

#147

Post by cgh »

crazygringo wrote: post #126
stared wrote: post #5

There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…

That's a really, really interesting point. It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc. Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write. The idea of a la…

That’s what the article is about.

Re: If you're going to vibe code, why not do it in C?

#148

Post by yberreby »

ActorNightly wrote: post #109
markstos wrote: post #105

I have successfully vibe-coded features in C. I still don't like C. The agent forgets to free memory latter just like a human would and has to go back and fix it later. On the other hand, I've enjoyed vibe coding Rust more, because I'm interested in Rust and felt like my understanding approved along they way as I saw what code was produced. A lot of coding "talent" isn't skill with the language, it's learning all the…

> The agent forgets to free memory latter just like a human would and has to go back and fix it later. I highly recommend people learn how to write their own agents. Its really not that hard. You can do it with any llm model, even ones that run locally. I.e you can automate things like checking for memory freeing.

> I.e you can automate things like checking for memory freeing.

Or, if you don't need to use C (e.g. for FFI or platform compatibility reasons), you could use a language with a compiler that does it for you.

Re: If you're going to vibe code, why not do it in C?

#149

Post by TomasBM »

I guess vibe coding is fun as a meme, but it hides the power of (what someone else on HN) called language user interfaces (LUIs).

The author's point is correct IMO. If you have direct mappings between assembly and natural language, there's no functional need for these intermediate abstractions to act as pseudo-LUIs. If you could implement it, you would just need two layers above assembly: an LLM OS [1], and a LUI-GUI combo.

However, I think there's a non-functional, quality need for intermediate abstractions - particularly to make the mappings auditable, maintainable [2], understandable, etc. For most mappings, there won't be a 1:1 representation between a word and an assembly string.

It's already difficult for software devs to balance technical constraints and possibilities with vague user requirements. I wonder how an LLM OS would handle this, and why we would trust that its mappings are correct without wanting to dig deeper.

[1] Coincidentally, just like "vibe coding", this term was apparently also coined by Andrej Karpathy.

[2] For example, good luck trying to version control vectors.

Re: If you're going to vibe code, why not do it in C?

#150

Post by SoftTalker »

abnercoimbre wrote: post #15
bigstrat2003 wrote: post #6

> Vibe coding actually works. It creates robust, complex systems that work. No, it absolutely doesn't. We've seen so much vibe coded slop that it's very clear that vibe coding produces a hot mess which no self respecting person would call acceptable. No idea how you can say this as it isn't remotely true.

The author doesn't appear to ship commercially-viable software and unfortunately it shows. Those of us who do are amused by the essay. The two recent IT catastrophes [0] from Alaska Airlines will continue elsewhere. [0] https://www.seattletimes.com/business/alaska-airlines/alaska...

> Alaska hired the consulting firm Accenture to look for ways to strengthen its system

Now they have two problems....

Post reply on HN