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

11–20 of 626 posts

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

#11

Post by flatline »

I also enjoy coding! It’s fun. It’s also only about 10% of my job as a software developer, and I can and do use an LLM for it whenever I can find an opportunity. The author is a professor. Not to disparage that perspective, but she paints a picture of the joys of programming that are overshadowed in environments where you are actually building real world robust systems with clueless users, vague requirements, shifting budgets and priorities, etc.

As to why not use C, or assembly, it’s not just about the code, but the toolchains. These require way more knowledge and experience to get something working than, say, Python - although that has its own rather horrible complexities with packaging and portability on the back end of the code authoring process.

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

#12

Post by stargrazer »

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…

To go along with this, the ACM has a recent article on Automatically Translating C to Rust. It gets into the challenges of 'understanding code and structure' so that the end result reflects the intent of the code, not the actual execution paths.

https://cacm.acm.org/research/automatically-translating-c-to...

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

#13

Post by qudat »

Espressosaurus wrote: post #10

It doesn't have problems with undefined behavior, memory safety, or especially thread safety? That has not been my experience when using Codex, Composer, Claude, or ChatGPT. Things have just gotten to the point over the last year that the undefined behavior, memory safety, and thread safety violations are subtler and not as blindingly obvious to the person auditing the code. But I guess that's my problem, because I'm…

You just tell it the problem and it'll fix it. It's almost never been an issue for me in Zig.

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

#14

Post by bildiba »

I started reading this out of curiosity, thinking: that's such a far fetched thought, I'm curious about what the author wants to say. I think he makes a good point about execution vs. readability, and the actual need for the latter, drawing analogies to earlier abstractions. I'm still skeptical about low level language generation (tbh, letting an LLM handle memory at this point of maturity feels scary to me.. leaks etc)... But overall very interesting writeup and many points that I agree with.

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

#15

Post by abnercoimbre »

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

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

#16

Post by guywithahat »

> why not do it in C?

A legitimate point, there are lots of performance and fine grain changes you can make, and it's a simple, common language many people use. Perhaps we could realize some of these benefits from a simple, fast language.

> Or hell, why not do it in x86 assembly?

A terrible take imo. This would be impossible to debug and it's complex enough you likely won't see any performance improvements from writing in assembly. It's also not portable, meaning you'd have to rewrite it for every OS you want to compile on.

I think there's an argument that if machines are writing code, they should write for a machine optimized language. But even using this logic I don't want to spend a bunch of time and money writing multiple architectures, or debugging assembly when things go wrong.

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

#17

Post by pathartl »

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…

I think it's a pretty good point. I've been using LLMs for .NET and the output is generally pretty good.

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

#19

Post by epgui »

There’s a nugget of an idea in there, even if I disagree with most of it.

But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important.

LLMs can never / should never replace verifiability, liability, or value judgment.

Post reply on HN