Live data from Hacker News

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

stephenramsay.net

391–400 of 626 posts

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

#391
post #238

Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, th…

The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist. The converse is that if vibe codi…

My bet is that it will be good enough to devise the requirements.

They already can brainstorm new features and make roadmaps. If you give them more context about the business strategy/goals then they will make better guesses. If you give them more details about the user personas / feedback / etc they will prioritize better.

We're still just working our way up the ladder of systematizing that context, building better abstractions, workflows, etc.

If you were to start a new company with an AI assistant and feed it every piece of information (which it structures / summarizes synthesizes etc in a systematic way) even with finite context it's going to be damn good. I mean just imagine a system that can continuously read and structure all the data from regular news, market reports, competitor press releases, public user forums, sales call transcripts, etc etc. It's the dream of "big data".

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

#393
post #170

Earlier quoted context omitted.

I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hatin…

> Speaking of vibe coding in archaic languages Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)

If we take the most popular programming languages and look at what their reference (or most popular) implementations are written in, then we get:

  C++: JavaScript (V8), Java, C#

  C: Python, PHP, Lua, Ruby

  Self-hosted: Go, Rust
Far from archaic indeed. We're still living in the C/C++ world.

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

#394
Does anybody else feel that vibe coding only works in Python JavaScript, and maybe Go? It seems like once you get more esoteric than that everything goes out the window. Zig code is laughable. I can't get LLMs to write a single cogent function in OCAML, things break catastrophically at 10 LOC. I haven't seen anybody else describe this experience.

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

#395
post #339

Earlier quoted context omitted.

How does the LLM get all the required knowledge about the domain and the product to ask relevant questions?

Give it access to the codebase and a text file with all relevant business knowledge.

Man ... if there were a text file with "all relevant business knowledge" in any job I've ever worked, it would have been revolutionary.

I'd say 25% of my work-hours are just going around to stakeholders and getting them to say what some of their unstated assumptions and requirements are.

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

#396
post #354

Earlier quoted context omitted.

Binary bits are also a language. A structured language that transistor-based computers execute into some result we humans find valuable. Why wouldn't a model be able to write these binary instructions directly? Why do we need all these layers in between? We don't.

Because the learned function to generate binary code is likely more complex than that for Python. I admit I can't say for sure until we try it. If someone were to train a model at the same scale on the same amount of raw binary code as we do these models on raw language and code, would it perform better at generating working programs. Thing is, it would now fail to understand human language prompts. From what I know…

Why would you think its more complex? There are less permutations of generating transistor on/off states than there are all the different programming languages in use that result in the exact same bits.

Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture? Maybe it can be, maybe there are other ways of doing it that are better. The AI model architecture is not the focus of the discussion. It is the possibilities of how it can look like if we ask for some computation, and that computation appears without all the middle-men layers we have right now, English->Model->Computation, not English->Model->DSL->Compiler->Linker->Computation.

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

#398

Earlier quoted context omitted.

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 I'm 62, and I'm not old yet, you're just a kid. ;-) Seriously, there are some folks here who started on punch cards and/or paper tape in the 1960s.

I played with punch cards and polystyrene test samples from the Standard Oil Refinery where my father worked in the early 70’s and my first language after basic was Fortran 77. Not old either.

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

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

technically true but so what? https://security.googleblog.com/2025/11/rust-in-android-move... That team claims that not having to deal with memory bugs saved them time. That time can be spent on other things (like fixing logic errors)

That time can be spent on solving rust type puzzles

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

#400
post #393
post #170

Earlier quoted context omitted.

> Speaking of vibe coding in archaic languages Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)

If we take the most popular programming languages and look at what their reference (or most popular) implementations are written in, then we get: C++: JavaScript (V8), Java, C# C: Python, PHP, Lua, Ruby Self-hosted: Go, Rust Far from archaic indeed. We're still living in the C/C++ world.

I thought Rust still used LLVM (a C++ project) for the backend, did they already switch to Cranelift?
Post reply on HN