I feel like encapsulation and composition are in strong tension, and this is one place where it boils over.
I've written a decent bit of Rust, and am currently messing around with Zig. So the comparison is pretty fresh on my mind:
In Rust, you can have private fields. In Zig all fields are public. The consequences are pretty well shown with how they print structs:
In Rust, you derive Debug, which is a macro that implements the Debug trait at the definition site. In Zig, the printing function uses reflection to enumerate the provided struct's fields, and creates a print string based on that. So Rust has the display logic at the definition site, while Zig has the logic at the call site.
It's similar with hash maps: in Rust you derive/implement the Hash and PartialEq trait, in Zig you provide the hash and eq function at the call site.
Each one has pretty stark downsides:
Zig - since everything is public, you can't guarantee that your invariants are valid. Anyone can mess around with your internals.
Rust - once a field is private (which is the convention), nobody else can mess with the internals. This means outside modules can't access internal state, so if the API is bad, you're pretty screwed.
Honestly, I'm not sure if there is a way to resolve this tension.
EDIT: one more thought: Zig vs Rust also shows up with how object destruction is handled. In Rust you implement a Drop trait, so each object can only have one way to be destroyed. In Zig you use defer/errdefer, so you can choose what type of destructor runs, but this also means you can mess up destruction in subtle ways.
> Zig vs Rust also shows up with how object destruction is handled.
I often hear critiques of Drop being less efficient for anything Arena-like, where batch destruction would be better, and holding that as the reason defer is a better approach. What is not mentioned there is that there's nothing stopping you from having both. In Rust you can perform batch destruction by having additional logic (it might require control of the container and its contents' types for easiest implementation), but the default behavior remains sane.
That's fair, since you can leak the box. I will say though it's not as ergonomic as defer, as defer handles all exits from the scope, where it's trickier to juggle destructors. Though on further thought, I suppose the arena can have Drop.
Here I'm able to swap out std.MultiArrayList's backing to be backed by virtual memory, and correctly clean it up. I'm not sure you can really do that with Rust, barring making custom data structures for everything.
Is this really that big a downside? It encourages good APIs.
The alternative of everything being public is the kind of feature that quickly becomes a big disadvantage in larger systems and teams, where saying “just don’t footgun yourself” is not a viable strategy. If there’s a workaround to achieve some goal, people will use it, and you end up with an unmaintainable mess. It’s why languages whose names start with C feature so prominently on CVE lists.
There are always corner cases where you might need to do something differently.
I had three memorable cases in my career:
1. Python 2.6x had a a stdlib bug where windows event logging did crash the process when the user had some rights set differently. Fix submitted but for the meantime we simply overwrote the private function and could ship.
2. Also python: scikit-learn had a primitive "print everything" strategy, but we need to get it into a logging framework. We overwrote their print wrapper and could ship.
3. In C#, a third party lib insisted on dumping a result to a file. We used reflection to get that as a stream.
All three are not ideal - but I think having escape hatches is important. I also think private/public is overrated. Having it as a signal is ok. Forbidding access to privates is too strong.
Three cases in your career doesn't sound like a strong counterargument to me.
I agree that escape hatches can be a good idea, though. But they should be very controlled, e.g. requiring annotations in the code, something that can be reported on by automated tooling and that can't just be done inconspicuously.
The problem is it only takes one bad or incomplete API needed for your specific use case. I ran into this a lot when I used cpal. For example, the data stream enum type (i16, u8, f32, etc) didn't have Hash or Eq derived, so I had to create a wrapper class for the data stream type. But, the type was marked non exhaustive, so I wouldn't be able to tell if my wrapper would get out of sync with theirs. It was a pain to work around.
In other cases, I couldn't work around, so I had to vendor some things. I ended up implementing my own graph library, because the existing one wouldn't let me reach into change some invariants for undo/redo. Which I mean, fair enough if that's what's needed, but it's a real pain to reimplement something because the API was incomplete. And of course, now if something from another library needs petgraph, I'd have to convert my graph to its graph.
So yes, in theory, if we had great APIs this wouldn't be a problem. Unfortunately, APIs are always a work in progress, and sometimes need escape hatches in order to send values between libraries.
I'm working on an interpreter right now, and I'm considering adding JIT support in the future. Are there other blog posts like this, or deep dives that talk about how to implement and tune a JIT?
My main high-level advice would be to have an extensive set of behavioral tests (lots of scripts with assertions on the output). This helps ensure correctness when you flip on your JIT compilation.
You'll eventually run into hard to diagnose bugs - so be able to conditionally JIT parts of your code (per-function control - or even better, per-basic block) to help narrow down problem areas.
The other debugging trick I did was spit out the full state of the runtime after every instruction, and ensure that the same state is seen after every instruction even w/ JIT enabled.
> The need for and relationships between concepts in calculus, logarithms and trigonometry were a recurrent problem for me.
Oh my gosh, this was me growing up! I loved tinkering with electronics and programming, but I kept bumping against my lack of knowledge wrt more advanced math topics. I usually hacked around it, or more often just switched to a different project.
Now that I'm taking calculus, I feel like I always have a corresponding application for each topic we cover. It's very exciting!
> Now that I'm taking calculus, I feel like I always have a corresponding application for each topic we cover. It's very exciting!
Mathematical concepts need not necessarily have any practical or real-life applications (pure mathematics), but it's a worthy pursuit on its own. However, every maths concept we learn outside of specialized mathematics courses have some application (applied mathematics). That's how these courses are designed.
It's funny when some people lament that much of the mathematics they learned at school or uni/college have no real-life applications! I wonder what they think about why they learned it. It also shows a big problem with math education and pedagogy. Many people are sailing without a destination in mind, hoping that they'll just hit some land in the future. The academic practice of mathematics has turned into the drudgery of endless symbolic manipulation.
But at the same time, people like you who lean into creativity, hit the limits of their mathematical knowledge early. For them, the problem isn't that the mathematics they learned have no applications. It's that they don't know where to look for the mathematics they need. Here is the failure of math education. If everyone was taught about the different branches of Mathematics, how they relate to each other and where they're applied, I can guarantee that many students will learn those on their own before they're formally introduced to them. That would enable the talented and interested students to shape their own destiny.
> Mathematical concepts need not necessarily have any practical or real-life applications (pure mathematics), but it's a worthy pursuit on its own.
I guess I always had a sense that this was true, but taking a formal proofs class has really opened my eyes to how true this is. I'm actually planning on doing abstract algebra because I've enjoyed proof writing a ton!
> It's that they don't know where to look for the mathematics they need. Here is the failure of math education.
This is a really interesting space imo, because I did try teaching myself calculus through 3blue1brown, who has super cool visualizations, but also isn't rigorous enough to apply it to complicated problems. On the other end, I also tried Khan Academy, but found it too abstract and hard to follow.
Perhaps that was just since I was 14 at the time, and now I'm better at symbolic reasoning. Yet, there's something so enticing about visualization, that I wish there was a way to have the rigour of set theory with the intuitiveness of visualization (that call is a big reason I love the work that dynamicland.org and folk.computer are doing right now).
One other thing, it might be worthwhile having the spec fresh in the LLM's context by downloading it and pointing the agent at it. I've heard that that's a fruitful way to get it to refresh its memory.
What is the state of the art in regards to how neurons learn over time? Do existing neuron models account for that? Being trapped, unable to learn anything, sounds terrible.
tbh that's not a helpful thing to say. I think a more productive thing would be to ask "What model are you using?" "Are you using it in chat mode or as a dedicated agent?" "Do you have an AGENTS.md or CLAUDE.md?"
I've also been underwhelmed with its ability to iterate, as it tends to pile on hacks. So another useful question is "did you try having it write again with what you/it learned?"
> I think a more productive thing would be to ask "What model are you using?" "Are you using it in chat mode or as a dedicated agent?" "Do you have an AGENTS.md or CLAUDE.md?"
In my case I'd have to say "Don't know, whatever VS Code's bot uses", and "no idea what those are or why I have to care".
The reason I ask about what model is I initially dismissed AI generated code because I was not impressed with the models I was trying. I decided if I was going to evaluate it fairly though, I would need to try a paid product. I ended up using Claude Sonnet 4.5, which is much better than the quick-n-cheap models. I still don't use Claude for large stuff, but it's pretty good at one-off scripts and providing advice. Chances are VS Code is using a crappy model by default.
> no idea what those are or why I have to care
For the difference between chat mode and agent mode, chat mode is the online interface where you can ask it questions, but you have to copy the code back and forth. Agent mode is where it's running an interface layer on your computer, so the LLM can view files, run commands, save files, etc. I use Claude in agent mode via Claude Code, though I still check and approve every command it runs. It also won't change any files without your permission by default.
AGENTS.md and CLAUDE.md are pretty much a file that the LLM agent reads every time it starts up. It's where you put your style guide in, and also where you have suggestions to correct things it consistently messes up on. It's not as important at the beginning, but it's helpful for me to have it be consistent about its style (well, as consistent as I can get it). Here's an example from a project I'm currently working on: https://github.com/smj-edison/zicl/blob/main/CLAUDE.md
I know there's lots of other things you can do, like create custom tools, things to run every time, subagents, plan mode, etc. I haven't ever really tried using them, because chances are a lot of them will be obsolete/not useful, and I'd rather get stuff done.
I'm still not convinced they speed up most tasks, but it's been really useful to have it track down memory leaks and silly bugs.
Heh, I'm a college student, so I can't help with that...
You could also try Gemini 3 pro with Gemini's CLI which is free, though it's not as good at using tools. But, it sounds like you're not interested, which is fine!
Just please don't continue to argue with finer points if you're not interested. I've done my best to engage with your points, but I get the sense that it doesn't matter what I say.
I am curious though, why do you feel so strongly about LLM products?
I should note that I'm not the same person that you were talking to you the chain. So I hope we're not mixing conversations and people. I don't think I've said that much in this chain, so I can't answer much.
But sure:
>why do you feel so strongly about LLM products?
Personally, I work in games. So pretty much everything in the discourse of LLMs and Gen AI has been amplified 5x for me. The layoffs, the gamers' reaction to stuff utilizing AI, the impact on hardware prices, the politics, etc.
Theres a war of consumers and executives, and I'm trapped in the middle taking heat from both. It's tiring and it's clear who to blame for all of this. I want all of this to pop so the true innovation can rise out, instead of all the gold rush going on right now.
Also,game code is very performance sensitive. It's not like a website or app where I can just "add 5 seconds to a load time" unless I'm working on a simple 2D game, nor throw more hardware to improve performance. Even if LLMs could code up the game, I'd spend more time optimizing what it makes than it saved. It simply doesn't help for the kind of software I work with.
I have worked in games in the past, and currently work in games-adjacent. I'm sympathetic to the concerns you've mentioned, especially given how controversial it is (the recent reveal of DLSS5, which I find directionally interesting but executed poorly, is but one of many examples.)
From speaking to my friends in the industry, it seems like uptake for code is happening slowly, but unevenly, and the results are largely dependent on the level of documentation, which is often lacking. (I know of a few people using AI for (high-quality!) work on Godot, and their AIs struggle with many of the implicit conventions present in the codebase.)
With that being said, I would say that LLMs have generally been quite the boon for the (limited) gameplay work that I have done of recent. Because the cost of generation is so cheap [0], it is trivial to try something out, experiment with variations, and then polish it up or discard it entirely.
This also applies to performance work: if it's a metric that the AI can see and autonomously work on, it can be optimised. This is, of course, not always possible - it's hard to tell your AI to optimise arbitrary content - but it's often more possible than not, especially if you get creative. (Asking it to extract a particularly hot loop out from the code it resides within, and then optimising that, for example: entirely feasible.)
I think there are still growing pains, but I'm confident that LLMs will rock the world of gamedev, just like they're doing to other more well-attested fields of programming.
Yeah, that sums up a lot of my thoughts with AI c. 2026.
I do take some schedenfreude knowing that AI training also struggles with the utter lack of documentation here. That may be a win in and of itself if this paradigm forces the games industry to properly care for tech writing.
>Because the cost of generation is so cheap [0], it is trivial to try something out, experiment with variations, and then polish it up or discard it entirely.
Well, that's another thing I'm less confident about. The cost is low, for now. But we also know these companies are in loss leader mode. It'll probably always be cheap for a company to afford agents, but I fear reliance on these giant server models will quickly price out ICs and smaller work environments.
That might be something China beats us too. They seem to be focusing on optimizing models that works on local machines out of necessity, as opposed to running tens of billions of dollars of compute. My other big bias is wanting to properly own as much of my pipeline as possible (to the point where my eventual indie journey is planning around OS tools and engines, despite my experience in both Unity and UE), and current incentives for these companies don't want that.
Crap, you're right. I swear, tiny usernames is both a boon and a curse...
> Personally, I work in games. So pretty much everything in the discourse of LLMs and Gen AI has been amplified 5x for me. The layoffs, the gamers' reaction to stuff utilizing AI, the impact on hardware prices, the politics, etc.
> Theres a war of consumers and executives, and I'm trapped in the middle taking heat from both. It's tiring and it's clear who to blame for all of this. I want all of this to pop so the true innovation can rise out, instead of all the gold rush going on right now.
That makes a lot of sense. I've been pretty fed up with the hyperbole and sliminess, and I can't imagine how difficult it is to be squeezed between angry gamers and naive and dense executives.
When you say "true innovation", is that in terms of non-AI innovation, or non-slimy AI innovation? I guess I personally still believe that LLMs are useful, but only as another tool amongst many others.
I'm also a big believer in human centered UX design, and it's kinda sad that the dominant experience is all textual.
> Also,game code is very performance sensitive
It does seem like game programming is the last bastion of performance, at least in terms of normal hardware, since the game has to go to the consumer's hardware. The "silver bullet" mentality drives me a little crazy because it clearly doesn't work in all situations.
Anyways, I don't know if this response really has a point, but I wanted to at least acknowledge your experience.
>When you say "true innovation", is that in terms of non-AI innovation, or non-slimy AI innovation?
A bit of both. Similar to other tech investment, all the gaming centric accelerators are looking for is AI pitches. Makes me wonder what innovations thr past few years have been overlooked in lieu of the Ai Gold Rush.
But I can see the long term (likely 5+ years out) potebtial of Ai as well. Once we stop using it as a means to steal from and remove artists, I can see all kinds of tedious problems with assets that Ai can accelerate. Generative fill is a glimpse of a genuinely useful tool that helps artists instead of pretending to be an artist itself.
Can it eventually write performant code? Maybe. The other big issue is that 1) a lot of code isn't online to train on and 2) a lot of that code is still a mess to process, with little standards to follow. Maybe it can help with graphics code (which is much more structured) in the near future.
Agreed was a bit rough. Yes they are not great at iterating and keeping long contexts, but you look at what he’s describing and you have to agree that’s exactly the type of problem llm excel at
Shouldn’t have to baby step through the basics when the author is clearly not interested in learning himself
> Shouldn’t have to baby step through the basics when the author is clearly not interested in learning himself
I'd rather assume good faith, because when I first started using LLMs I was incredibly confused what was going on, and all the tutorials were grating on me because the people making the tutorials were clearly overhyping it.
It was precisely the measured and detailed HN comments that I read that convinced me to finally try out Claude, so I do my best to pay it forward :)
I totally agree, and myself have gone through that cycle.
But the guy is being adversarial and antagonistic. Its a 2 way street, sometimes you have to call people out on their BS because I'm not seeing someone argue in good faith, but rather pretending some superior knowledge because hes working on a esoteric protocol like people here don't know how packet headers work
I don't read it as superiority, perhaps bitterness would be the closest word to what I'm reading.
> sometimes you have to call people out on their BS
That's true, but I think that it's often much later than what some people would consider enough. Someone can be bitter, and still have good points. It's very dangerous to preemptively dismiss points, because it means that I won't listen to anyone who disagrees with me. I'm willing to put in the work to interpret someone's response in a productive light because there's often something to find.
There's a framework that I work within when I'm in a discussion. There's three elements: arguments, values, and assumptions. An argument is the face value statements. But those statements come from the values and assumptions of the person.
Values are what people consider most important. In most cases, our values are the same, which is good!
The biggest difference is assumptions. For example, one assumption I have is that free markets are the best method we have to lift individuals out of poverty. This colors how I talk about AI. Another person might assume that free markets have failed, and we need to use a different approach. This colors how they would view AI. So we'll completely talk past each other when arguing AI, because it's more of a proxy war of our assumptions.
>Shouldn’t have to baby step through the basics when the author is clearly not interested in learning himself
Okay. Whip up your favorite model and report back to us with your prompts. I'm pretty anti-AI, but you're going to attract more bees with honey than smoke.
Wouldn't you need to restart a process anyways if there's a security update? Sounds like you'd just need to kill all the VMs, start up the base again, and fork (but what do I know).
Honestly even if they didn't publish the whole paper, if there was just a page that was a table of all the replication studies that were done recently, that would be pretty cool.
I believe Rust is mainly being used for driver development, which seems a great fit (there's so many people of different skill levels who write Linux drivers, so this should help avoid bad driver code being exploited). It may also end up in the core systems, but it also might not fit there as well.
I've written a decent bit of Rust, and am currently messing around with Zig. So the comparison is pretty fresh on my mind:
In Rust, you can have private fields. In Zig all fields are public. The consequences are pretty well shown with how they print structs: In Rust, you derive Debug, which is a macro that implements the Debug trait at the definition site. In Zig, the printing function uses reflection to enumerate the provided struct's fields, and creates a print string based on that. So Rust has the display logic at the definition site, while Zig has the logic at the call site.
It's similar with hash maps: in Rust you derive/implement the Hash and PartialEq trait, in Zig you provide the hash and eq function at the call site.
Each one has pretty stark downsides: Zig - since everything is public, you can't guarantee that your invariants are valid. Anyone can mess around with your internals. Rust - once a field is private (which is the convention), nobody else can mess with the internals. This means outside modules can't access internal state, so if the API is bad, you're pretty screwed.
Honestly, I'm not sure if there is a way to resolve this tension.
EDIT: one more thought: Zig vs Rust also shows up with how object destruction is handled. In Rust you implement a Drop trait, so each object can only have one way to be destroyed. In Zig you use defer/errdefer, so you can choose what type of destructor runs, but this also means you can mess up destruction in subtle ways.
reply