Fascinating. I would appreciate a post with examples, not just prose. It helps to put things in a more grounded reality.
Why you hate on prose? This article has been a joy to read, unlike a lot of the other slop on the internet.
I love prose.
If you're going to vibe code, why not do it in C?
421–430 of 626 posts
Re: If you're going to vibe code, why not do it in C?
#422LLMs have single handedly turned the hardest part of this job into entire job. The hardest part of this job is troubleshooting, maintaining and developing on top of an unfamiliar code base. That's not a new experience for anyone who has lived the production code life. One of the first production engineers I was tutored under used to love to say, "the code should tell you a story."
I love C. I came up on C. But C does not tell you a story. It tells you about the machine. It tells you how to keep the machine happy. It tells you how to translate problems into machine operations. It is hard to read. It takes serious effort to discern its intent.
I think any time you believe the codebase you're developing will have to be frequently modified by people unfamiliar with it, you should reach for a language which is both limiting and expressive. That is, the language states the code intent plainly in terms of the problem language and it allows a limited number of ways to do that. C#, Java (Kotlin) and maybe Python would be big votes from me.
And FYI, I came up on C. One of the first senior engineers I was tutored by in this biz loved to say, good code will tell you a story.
When you're living with a large, long lived codebase, essenti
Re: If you're going to vibe code, why not do it in C?
#423At some point in a career, one begins to encourage people to try replacing you and your team. Mostly, senior people become aware they are not there as some sort of fungible office decoration. Just do it... call the Managers bluff... the worst outcome is the team finds a better firm with someone smarter.
It was Schadenfreude watching the CEO's son (LLM guys) implode a public-facing production server ( https://en.wikipedia.org/wiki/Dunning-Kruger_effect .)
Slop content about slop code is slop recursive. Languages like C are simply very unforgiving to amateurs, and naive arbitrary code generators. Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
Vibe coders usually offer zero workmanship, and are enamored with statistically salient generated arbitrary content. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
Re: If you're going to vibe code, why not do it in C?
#424Earlier quoted context omitted.
Can these claims back themselves up with a study showing that over a large population size with sufficient variety, sourced from a collection of diverse environments, LLM output across a period of time is more reliably correct and without issue when outputting Rust? Otherwise this is nothing but unempirical conjecture.
Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!" Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably). https://security.googleblog.com/2025/11/rust-in-android-move... I'm n…
Actually it's the classic "inductive reasoning has to meet a set of strict criteria to be sound." Criteria which this does not meet. Extrapolation from a sample size of one? In a context without any LLM involvement? That's not sound, the conclusion does not follow. The point being, why bother making a statistical generalization? Rust's safety is formally known, deduction over concrete postulates was appropriate.
> it would be very surprising if the situation were completely reversed for LLMs
Lifetimes must be well-defined in safe Rust, which requires a deep degree of formal reasoning. The kind of complex problem analysis where it is known that LLMs produce worse results in than humans. Specifically in the context of security vulnerabilities, LLMs produce marginally less but significantly more severe issues in memory safe languages[1]. Still though, we might say LLMs will produce safer code with safe Rust, on the basis that 100,000 vibe coded lines will probably never compile.
Re: If you're going to vibe code, why not do it in C?
#425Honestly, I think this is a valid viewpoint, but perhaps C is too low level. The bottleneck in generating code with LLMs tends to happen at the validation step. Using a language that has a lot of hard to validate footguns isn't great.
While I am not a big fan of Rust, the philosophy is likely useful here. Perhaps something like it, with a lot of technical validation pushed to the compiler, could actually be really useful here.
Getting rid of the garbage collector with no major increase in human cognitive load might actually be a big win.
Re: If you're going to vibe code, why not do it in C?
#426[deleted]
Re: If you're going to vibe code, why not do it in C?
#427I agree that coding is more fun than vibe coding, right up until you have a massive refactor that is super repetitive and no fun to author, but an LLM can do it in no time flat. Even if an IDE can help with the refactor, there are cases where they can't. And anyways, if you're working with a codebase you understand but are not super familiar with, then vibe coding is incredibly productive, though, well, you'll spend much more time reviewing what the LLM did, so maybe not quite that productive (unless you count on others to do your review, but that's not very nice, and it will show).
Re: If you're going to vibe code, why not do it in C?
#428> But if you look carefully, you will notice that it doesn’t struggle with undefined behavior in C. Or with making sure that all memory is properly freed. Or with off-by-one errors. Doubt. These things have been trained to emulate humans, why wouldn't they make the same mistakes that humans do? (Yes, they don't make spelling errors, but most published essays etc. don't have spelling errors, whereas most published C c…
There are some misconceptions here.
It's incorrect to think because it is trained on buggy human code it will make these mistakes. It predicts the most likely token. Let's say 100 programmers write a function, most (unless it's something very tricky), won't forget to free that particular function. So the most likely tokens are those which do not leak.
In addition, this is not GPT 3. There's a massive amount of reinforcement learning at play, which reinforces good code, particularly verifiably good (which includes no leaks). And also a massive amount of synthetic data which can also be generated in a way that is provably correct.
Re: If you're going to vibe code, why not do it in C?
#429If you're going to vibe code on legacy code, use the languages used there. If you're going to vibe code something new, then I recommend Rust. There are few cases where I would vibe code something brand new in C, mainly when building a library I'm going to need to use from other C programs.
Re: If you're going to vibe code, why not do it in C?
#430> Or hell, why not do it in x86 assembly?
It is not portable to computers other than x86. It is one of the reasons I do not use x86 assembly much even though I have a x86 computer; I prefer C. It is not about vibe coding.
> I suppose what I’m getting at, here, is that if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. You read it here first.
Someone told me that two companies (one of which is Google) were working on such a thing, although I do not know the details (or if they were correct about that), and I do not know whether or not it resembles what is described in that article.
I do not use LLM myself, although I have seen a few examples of it. I have not seen very many so the sample size is too small, but what I have seen (from simple example programs), the program works although it is not written very well.