Live data from Hacker News

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

stephenramsay.net

481–490 of 626 posts

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

#481

Earlier quoted context omitted.

Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works. It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.

Rust does not have manual memory management, and its type system also has the property that if your program compiles it probably works, IME.

I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.

So...yeah.

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

#482

Earlier quoted context omitted.

It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.

No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does. Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference. The list of things it can do for you is massive, even if you don't have it write a single line of code. Yet the counter argument is like "bu..…

I am not even a software engineer but from using the models so much I think you are confined to a specific niche that happens to be well represented in the training data so you have a distorted perspective on the general usefulness of language models.

For some things LLMs are like magic. For other things LLMs are maddeningly useless.

The irony to me is anyone who says something like "you don't know how to use the LLM" actually hasn't explored the models enough to understand their strengths/weaknesses and how random and arbitrary the strengths and weakness are.

Their use cases happen to line up with the strengths of the model and think it is something they are doing special themselves when it is not.

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

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

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

Every language with a GC drastically reduces the chance of memory errors.

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

#484

Earlier quoted context omitted.

There are a wide number of small problems for which we do not need bridges. As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.) Or, using the Jira API to extract the s…

Absolutely. But the person I replied to seemed to be talking about a task agenda for their professional work, not a todo list of bespoke little weekend hobby hacks that might be handy "around the house".

You assume they were talking about a single product. at my job there is essentially endless amounts of small tasks. We have many products and clients we have many internal needs, but can't really justify the human capital. Like I might write 20 to 50 Python scripts in a week just to visualize the output of my code. Dead boring stuff like making yet another matplotlib plot, simple stats, etc. Sometimes some simple animations. there is no monstrosity being built, this is not evidence of tagging on features or whatever you think must be happening, it's just a lot of work that doesn't justify paying a bay area principal engineer salary to do in the face of a board that thinks the path to riches is laying off the people actually making things and turning the screws on the remaining people struggling to keep up with the workflow.

Work is finite, but there can be vastly more available than there are employees to do it for many reasons, not just my personal case.

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

#486
Vibe coding should be done in Python, and probably only in Python.

If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all.

Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collection, the forgiving syntax, the interpreted nature: these create a sandbox where vibe coded solutions can fail safely. A buggy Python script throws an exception. A buggy C program gives you memory corruption or security holes that show up three deployments later.

The question isn’t what language should AI write. It’s what problems should we trust to vibe coding. The answer: problems where Python’s safety net is enough. The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.

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

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

If it needs that many rules, why use AI at all? Linters pre-exist AI, don't cost money, and don't boil the oceans. Look at Shellcheck. It turns a total newbie into a shell master just by iteration.

The people you write to don't want or just can't code.

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

#488
post #329
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.

Idiomatic Rust prevents many classes of logic errors. Just having proper sum types eliminates many (perhaps most) common logic errors.

Idiomatic Java too.

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

#489

Earlier quoted context omitted.

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

Every language with a GC drastically reduces the chance of memory errors.

But if you use managed laguages you can't feel superior like when coding in Rust.

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

#490

Earlier quoted context omitted.

> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software devel…

Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or m…

> I'm considered old here, in my mid 30's,

The 30s is the first decade of life that people experience where there are adults younger than them. This inevitably leads people in their 30s to start saying that they are "old" even though they generally have decades of vigor ahead of them.

Post reply on HN