gopiandcode (u/gopiandcode)

gopiandcode commented on Humanity is stained by C and no LLM can rewrite it in Rust kirancodes.me/posts/log-s... · Posted by u/gopiandcode

akagusu · a month ago

Rust definitively became a cult. Humanity runs on C and C runs on devices that Rust devs can't even imagine they exist, but they want humanity to bend the knee to the god Rust. This madness needs to stop.

gopiandcode · a month ago

If it has become a cult, it's become a cult that has infiltrated so far as DARPA - see their TRACTOR program (https://www.darpa.mil/research/programs/translating-all-c-to...)

I think couching the success and excitement around rust to ideology or a "cult" as you say is somewhat digging your head into the sand. There are concrete facts and results. Rust is empirically producing levels of memory safety that humanity did not think was possible with software at scale. This is truly groundbreaking.

gopiandcode commented on Humanity is stained by C and no LLM can rewrite it in Rust kirancodes.me/posts/log-s... · Posted by u/gopiandcode

davydm · a month ago

Rust is cool. A great idea, if a little hard to wrap a grug-brain like mine around (I've tried, and will try again, I'm sure)

BUT

There are plenty of programs written in C which require no rewrite, do what they're supposed to, and have been doing what they're supposed to for decades. Yes, it's possible to write C code with "heisenbugs" and it's harder to do so in Rust - and that's a good thing. But if it works, it doesn't need fixing, so calling C a "stain" is a little over-dramatic. Continue with the ports, continue to use Rust - especially now, as the pace of development is (imo) faster than 2 decades ago, and the one thing that speed almost guarantees is mistakes - having a compiler catch those for you (especially if you can understand the output!) is great. Requiring total conversion of all C projects to Rust is... cultish? I guess to be expected - the author has had pain in the past, alleviated by Rust, and so they will spread the good word about their savior, but I see a lot of conversation in this realm which is all-or-nothing (both ways - C or Rust), and I think those arguments miss the points:

1. Reliability - use what's reliable to write new stuff; if old stuff is already reliable, and simple enough to check, focus elsewhere - there's too much to rebuild it all, so focus on what actually needs attention 2. Functionality - use what works (program-wise). Going "ew, written in C" gets you nowhere. On this line, I'd really appreciate an "ez mode" for Rust where errors are displayed in language that someone not living in the Rust world for months can grok. I'm not alone here. 3. Kindness - there's no need to go on crusades in the name of a language. All software is flawed in some way, including that golden turd you wrote in Rust. Got no bugs? Someone will be missing a feature. Got heaps of features? Someone has a bug. This world would be a lot nicer to live in if people could just be kind. Instead of "C is trash", perhaps "We got a lot of shit done in C, but Rust helps us to make better software, so let's go!".

Calling one of the greatest inventions in programming history a "stain" is egotistical at best, shining hubris at worst (seriously! without it, no linux, no GNU, and heaps of other things that just don't get made, or are made in something like FORTRAN or COBOL).

Also, shut up and eat your vegetables, and get off my lawn. :D

gopiandcode · a month ago

So to clarify, the crusade to rewrite things in Rust is not my fight. To be honest, I'm more a third party watching from the sidelines. There seems to be big institutional interest in replacing C with Rust. Not for ideological reasons. Just for plain economic ones. Rust code is breaking industry standards of memory safety/bug density/review time. I link it in the article, but for example, darpa has a recent big grant program, TRACTOR: Translating All C to Rust (https://www.darpa.mil/research/programs/translating-all-c-to...).

My article was more a commentary aimed at the efforts towards doing that. In some sense arguing that there are some foundational formal deficiencies currently that mean that it's not even clear what success would be. I guess I don't really take a position on the value of rewriting things into Rust, aside from adopting the views of these existing programs as some prelude.

gopiandcode commented on Humanity is stained by C and no LLM can rewrite it in Rust kirancodes.me/posts/log-s... · Posted by u/gopiandcode

almosthere · a month ago

Technically in a few years LLMs may be good enough to ensure that even C code is bug proof by making sure every unchecked write is checked. Every write to a buffer has some constraint. That or it just ports things to rs

gopiandcode · a month ago

w.r.t the first point, so ideally you wouldn't want to do that because it'd incur a heavy runtime performance. Rust's memory analysis allows eliminating those kinds of memory bugs without having to check writes at runtime.

w.r.t the second point, I talk a bit about that in the article itself -- the fundamental problem right now is that there's no real formal way of even stating what it means to correctly translate a program from C to Rust. We could maybe have a smart LLM that translates things to Rust, but would you trust it without tests? or ideally a proof of correctness? what properties should we test? etc.

gopiandcode commented on Why Lean 4 replaced OCaml as my Primary Language kirancodes.me/posts/log-o... · Posted by u/gopiandcode

anentropic · 5 months ago

TIL... I didn't realise that Lean was usable(?) for 'actual programming' rather than just math proofs etc

gopiandcode · 5 months ago

oh yep, it's definitely more than usable for 'actual programming' beyond just maths proofs.

Things like:

- bindings to godot (https://github.com/kiranandcode/lean4-godot)

- advent of code (https://github.com/kiranandcode/lean-aoc)

- ffi bindings to constraint solvers (https://github.com/kiranandcode/cleango/)

Obviously a slightly biased selection here, but the key point is to clarify that it's more than feasible to use it for real programs that do all sorts of non-mathy stuff.

gopiandcode commented on LLMs pose an interesting problem for DSL designers kirancodes.me/posts/log-l... · Posted by u/gopiandcode

furyofantares · 6 months ago

I notice I am confused.

> Suddenly the opportunity cost for a DSL has just doubled: in the land of LLMs, a DSL requires not only the investment of build and design the language and tooling itself, but the end users will have to sacrifice the use of LLMs to generate any code for your DSL.

I don't think they will. Provide a concise description + examples for your DSL and the LLM will excel at writing within your DSL. Agents even moreso if you can provide errors. I mean, I guess the article kinda goes in that direction.

But also authoring DSLs is something LLMs can assist with better than most programming tasks. LLMs are pretty great at producing code that's largely just a data pipeline.

gopiandcode · 6 months ago

Arguably it really depends on your DSL right? If it has a semantics that already lies close to existing programming languages, then I'd agree that a few examples might be sufficient, but what if your particular domain doesn't match as closely?

Examples of domains that might be more challenging to design DSLs for: languages for knitting, non-deterministic languages to represent streaming etc. (i.e https://pldi25.sigplan.org/details/pldi-2025-papers/50/Funct... )

My main concern is that LLMs might excel at the mundane tasks, but struggle at the more exciting advances, and so now the activation energy for coming up with advances DSLs is going to increase and as a result, the field might stagnate.

gopiandcode commented on LLMs pose an interesting problem for DSL designers kirancodes.me/posts/log-l... · Posted by u/gopiandcode

NathanKP · 6 months ago

Good to see more people talking about this. I wrote about this about 6 months ago, when I first noticed how LLM usage is pushing a lot of people back towards older programming languages, older frameworks, and more basic designs: https://nathanpeck.com/how-llms-of-today-are-secretly-shapin...

To be honest I don't think this is necessarily a bad thing, but it does mean that there is a stifling effect on fresh new DSL's and frameworks. It isn't an unsolvable problem, particularly now that all the most popular coding agents have MCP support that allows you to bring in custom documentation context. However, there will always be a strong force in LLM's pushing users towards the runtimes and frameworks that have the most training data in the LLM.

gopiandcode · 6 months ago

Oh that's a great blog post and a very interesting point. Yep, I hadn't considered how LLMs would affect frameworks in existing languages, but it makes sense that there's a very similar effect of reinforcing the incumbents and stifling innovation.

I'd argue that the problem of solving this effect in DSLs might be a bit harder than for frameworks, because DSLs can have wildly different semantics (imagine for example a logic programming DSL a la prolog, vs a functional DSL a la haskell), so these don't fit as nicely into the framework of MCPs maybe. I agree that it's not unsolvable though, but it definitely needs more research into.

gopiandcode commented on LLMs pose an interesting problem for DSL designers kirancodes.me/posts/log-l... · Posted by u/gopiandcode

Mathnerd314 · 6 months ago

Python is just a beautiful, well-designed language - in an era where LLM's generate code, it is kind of reassuring that they mostly generate beautiful code and Python has risen to the top. If you look at the graph, Julia and Lua also do incredibly well, despite being a minuscule fraction of the training data.

But Python/Julia/Lua are by no means the most natural languages - what is natural is what people write before the LLM, the stuff that the LLM translates into Python. And it is hard to get a good look at these "raw prompts" as the LLM companies are keeping these datasets closely guarded, but from HumanEval and MBPP+ and YouTube videos of people vibe coding and such, it is clear that it is mostly English prose, with occasional formulas and code snippets thrown in, and also it is not "ugly" text but generally pre-processed through an LLM. So from my perspective the next step is to switch from Python as the source language to prompts as the source language - integrating LLM's into the compilation pipeline is a logical step. But, currently, they are too expensive to use consistently, so this is blocked by hardware development economics.

gopiandcode · 6 months ago

mhhm yes yes. There's a thread of discussion that I didn't quite chose to delve into in the post, but there is something interesting to be found in the observation that languages that are close to natural language (Python being famous for being almost executable pseudo-code for a while) being easier for LLMs to generate.

Maybe designing new languages to be close to pseudo-code might lead to better results in terms of asking LLMs to generate them? but there's also a fear that maybe prose-like syntax might not be the most appropriate for some problem domains.