59nadir

Zig has even worse tool support than Odin does, in my experience, and is a worse language than Odin overall, so the ratio of good language to tooling quality issues is lower in Zig.

Mind you, both of these languages are excellent compared to most other languages (there are a bunch of languages I've used that I'm not mentioning here because they're not even really worth comparing with), and there are certainly languages with worse tooling and overall worse outlooks for how to deal with issues. I don't want to give the impression that I dislike either Odin or Zig. They're just competing with C in this comparison, and by my estimation the holistic experience of developing in C is better than in either of them.

Sure, but all of this comes down to "Which reality do we live in and do you want to do the work to get the reality you prefer?". I don't think Odin provides enough of an upside for me to "fix" tooling. If I can get a simpler, even less ambitious language, and I can have my tools just work that way as well, this seems like a pretty winning scenario.

So yeah, it's not that you can't have a debugger that understands all of Odin perfectly, it's more like the reality we do have is one where basically none of them understand Odin perfectly, one has built-in (read-only) support for just slightly better Odin-specific views/functionality, two have read-only support (no interaction with built-in types because they use magic intrinsics behind the scenes and magic syntax) for Odin with custom scripts you have to load and everything else is just looking at C.

I've written Odin for 4+ years at this point, so it's not really as if this is a knee-jerk reaction to initial friction. I've spent the time and at this point I am very certain that I don't want to spend any more time with languages where tools are always bad or leaning towards bad, because I've realized that tools are really much more important to me than the languages themselves. I might even start using a language server again because C has one that's ridiculously fast in comparison to what you get with Odin, and it probably won't crash several times a day as soon as you get over some mild threshold like 25k lines, or a "whopping" 5k line file.

> If you've sworn off actually getting any value from the programming language

I haven't sworn off getting value from programming languages, I've just concluded that most languages are not useful and good enough to make me deal with the problems they have with tooling, complexity and so on over C.

Your suggestion to use assembly may be you trying to be hyperbolic, but I don't think it's nearly as hyperbolic and ridiculous as it'll sound to a lot of people. I personally think I get plenty of value out of the facilities C provides now, especially with later editions, but it may also be that it'd be holistically better to simply write assembly.

Because that's really what it comes down to: The big picture version of a lot of languages are that while the languages themselves may seem like an upgrade, their interaction with debuggers, etc., are not. A concrete example of this in Odin is that debuggers do not work particularly well with tagged unions (tagged unions have concrete integer values for tags in Odin, and the unions are generated anonymously and are not clear regarding which case is which), so whichever upside you have with language support for tagged unions, you'll still pay for it at debugging time. Meanwhile, in C with real enum types as you have in C23, your tag will be whichever enum value you have, i.e. readable and understandable, and your actual union cases will be exactly what you named them.

For just about every feature I like in Odin I have a similar story of where it falls apart with regards to tooling and other things. A "good language" doesn't mean that actually developing with it is any better than developing with an arguably less featureful and "worse" language.

I have been porting our Odin code to C(23) lately because it's better than anything else I've found in terms of language simplicity + tooling quality. 75% of our new code right now is C and in my estimation that'll be 100% in about a month, and we'll likely be done porting ~150 kLoC into a similarly sized C code base.

Even disregarding tooling I'm actually happier writing C than (even) Odin because it's really just a natural end state of changes I'd made to how I write code over the past 7-8 years and what I expect from a language (to not do much, and to not get in the way).

It's hard to compete with the tangibles of writing/using C:

- Somehow it has shorter compile times than everything else still, particularly for release builds?

- Everything that matters (to me) has C bindings.

- All the tools just work and they work well (and a lot of them are made specifically for C anyway).

- The compilation model is actually better, more straight forward and easier to make fast than languages that try to "fix" it, unless you sit there fighting it and overcomplicate it with overwrought build systems. (`make` is better than I used to give it credit for, though).

I think Ada is the only language that could peel my attention away from C at the moment, which is ironic given my "Don't do much, get out of my way" stance. It turns out you can do more if you're sensibly designed, have the right escape hatches and actually provide real, useful features (basically every feature regarding arrays in Ada and their interplay with other features like index types, etc.). Ada is not as easy to port from Odin, though, and Ada would be a much bigger gamble than C in so many ways. We don't mind writing the code we use ourselves (we in fact prefer it), but in Ada a lot of that code would be decidedly alien to how Ada seems to work in many ways.

With that said, I do have an Ada port of a game I was working on that does illustrate a lot of upsides. It's a different possible end state.

P.S. I've tried Zig, I wrote Zig for several years before I started using Odin, it's what got me back to imperative, small, native languages. It's what started this journey back to C.

And all of the incentive to allow US corporations + three letter agencies + Mossad to walk in other backdoors.

That it would've taken you 3-6 months because you're bad at what you do and don't know much. Being 10 times faster and better than 0.05 isn't particularly impressive.

I've only ever gotten sudden chinese (and some other script I couldn't identify) from GPT5.6 Luna via OpenAI. It's a very interesting failure mode.

Most "seniors" nowadays are juniors/mids with time on the job, most of it spent learning not much of note. With that noted I think you're actually right that they do have better judgment than most of those people, probably yourself included.

It's becoming an increasingly bad time to be hosting anything on your own, having to worry about whichever 0-day the clankers are going to find and/or exploit within minutes of it being patched. I'm not sure even nginx is safe in all of this. I used to think there was software that should be basically safe but I'm not sure hosting anything (open-source) yourself anymore (i.e. directly participating in the Internet on a personal level) is a good idea.

Having to go through 3rd party services (and rely on them to stay on top of things) to participate is not fun.

Just find a better place to go. If you have savings, quit this nonsense and start looking for something else while working on yourself.

I just got back to working on a project I like where we don't use any LLMs for code generation because we think it kind of sucks and leads to bad results unless it's for incredibly small contexts (which is usually not worth the prompting).

You're also not as alone as you think in actually liking programming enough to do it by hand even after having used LLMs. There's also the fact that you build more theory up by actually writing the code anyway, so someone who actually wants to know their code base intimitely will always have to write the code.

I think this sounds fantastic, and I welcome all developments in these types of areas where you lean heavily on the hyper-attentive, very fast assistant aspect of LLMs intended to make information more easily searchable, visible and the results more accurate.

I agree that the mismatch between the expectations of OOP as a paradigm and this situation right now feel very similar. I suppose the many billions pumped into selling vibecoding and large-scale code generation via LLMs of other kinds is sort of like the massive amount of money pumped into marketing Java as a viable alternative long before it actually was.

Early Copilot was tab-complete in editors and was honestly the best version of LLM-assisted development I've used, because it was intentionally small in scope, trivial to verify output from at a glance and easy to opt in and opt out of. I have yet to see anything more useful in terms of code generation; very small-scale code generation (think function-level) comes close, but is a lot more tedious.

For analysis, bug hunting, overview and some porting work to popular languages and so on I think the current SotA is fantastic, but they're still very disappointing for code generation past function or small module level.

Cloudflare doesn't even let my browser (qutebrowser) through. Anubis will sometimes sit and ask for ridiculous amounts of work, but at least it's never outright denied access.

I don't share your enthusiasm for the guardrails and I don't believe at all that they accomplish what they're supposedly created for.

I haven't said anything about "good", I just pointed out that there isn't exactly an alternative to Chinese models if censorship and restrictions are regarded as bad for longevity. You can't really do better than the Chinese models for longevity; US models are by far the worst in this regard. So "What about censorship?" is an absolutely hilarious question to ask when Chinese models are presented as an alternative. Yes, what about it? They have less than the obvious alternative from US labs, and where is it you imagine you'll find less censorship?

US models censor and restrict more things than Chinese models by quite a margin.

This is an incomplete and quite superficial view of what is going on out there, in my opinion. I've worked on plenty of projects where the assumption was that since the round-trip to the server is going to take almost 100ms that'll dwarf anything that's going to happen on the server itself, justifying poor choices that lead to potentially adding a whopping 100ms onto that number. These numbers only get larger with a larger perceived "Nothing we can do about it" budget as well, programmers often feel justified in doing just about anything once round-trip time grows, not understanding that they're just adding to an already existing problem.

On top of that: Creating software that isn't outright wasteful in terms of performance isn't even hard, it's just a matter of not doing ridiculously dumb things. The problem I've observed in teams I've worked with is that the majority of programmers don't even know what the dumb things are, and wouldn't know how to even approach making something that's halfway fast.

Since the influx of people who know basically nothing about anything made that part the majority and it became mostly business hype and pretense.

If you can, just avoid ever entering the US at all.

There is no "evidence"; by any reasonable interpretation of that word there would have to be an actual accusation of crime for there to be evidence of one. This was a search predicated on literally no actual basis apart from "we have the right to search your device because we have ultimate power at border passings", essentially just a fishing expedition.

This also doesn't even get to the more important point: If you don't have the contents of the phone you have literally no evidence of a crime being committed, other than the one they invented post-facto: "Deleting data that could hypothetically be incriminating, not in any specific way but just generally, maybe".

I've found that the Gemma series of models are made for someone entirely different than myself. They fail at even the most basic questions I throw at them, like 12B just now failed at answering how `XGrabKey` from Xlib is used. It hallucinated the entire API and made up an entire flow of code based on it, for no particular reason. It could've even decided to research this via web search because I have a tool specifically set up for that, but it "chose" not to, relying instead on completely made up information.

This isn't an isolated incident, really, I find myself always having these issues with the Gemma series. I'm sure they can do useful things for someone else, but for the things I want to use LLMs for (very small code generation, quick questions, code review) they always seem to disappoint me. I'm sure it's because of the stuff that I do and use, but it's a very consistent red thread with these models for me.

Edit:

The same question for Qwen3.6-35B-A3B produces a pretty concise and correct answer that would be useful to the questioner, without even going to the web. I don't know what Gemma models are trained on, but it's not the stuff that's relevant to me.

How oblivious are people to the world that they think this is somehow strange or hard to believe? Why would they like any of the tech CEOs, or CEOs in general?

It's hard to see why basically anyone would at this point.

I see what you're saying, but making things less boring by essentially gambling on the implementation of it is a pretty strange thing to do, in my opinion.

Sure, some people legitimately work on things that middle schoolers can put together, and for those things I suppose using LLMs as a way of just getting them done is a less risky prospect. For those cases I don't really see the point of tossing it over the hedge to LLMs because what exactly are you doing beyond that? These types of projects have almost nothing to actually do beyond the grunt work of wiring together MVC stuff.

It's not as if you're going to now have time for interesting things, as they tend to not exist at all in those types of projects, and they're rarely important or big enough to warrant much thought in terms of distributed systems design and so on.

I guess I can see a situation where someone instead finds time to work on actually interesting side projects because they've basically stopped doing their work manually because it's not something worth doing manually. Personally I don't think I could stand that type of situation because it would feel bad on a moral level as well as on a personal stimulation level.

> I’d say “push all your innovation tokens into agents” is probably a good move

Or better yet, just don't use agents, deliver something better with all the stability and boringness that you have. There's never been a better time than now to produce software that actually seems to work and march along steadily; your competitors are all flailing wildly like morons.

I've worked at two major studios and have seen some terrible code. Neither place had code as terrible as LLMs produce for games, they can't even get non-negotiable basics right a lot of the time.

Just so everyone who reads this understands; despite the criticism in this comment, it's being incredibly charitable to LLMs in the context of making games. They're not particularly good at it and you wouldn't want most of the code they write in your game and especially not in the underpinnings of your game.

It's not true as a general rule that they could give you correct small code snippets five years ago; I had frontier models not even understanding enough of the OpenGL API to make separate framebuffers correctly. I asked this as a test and the resulting recommended code would of course compile, but leave someone who didn't already know the correct way to do it staring at a black screen and potentially spending the next hour debugging that.

If you think you're somehow going to make an actual game worthy of people's time with LLMs, you are almost certainly mistaken. Not only because it'll be a complete, unworkable mess with really bad fundamentals, but also because if you're vibecoding the actual technical part you probably also think game design is just about "having ideas" or something else that's really reductive and incorrect.

People who don't know things are usually very impressed by solutions that LLMs come up with. I saw one recently that was very impressed that their chosen LLM took screenshots of their vibe coded game to check results, when it's clear from what they were saying the LLM could've literally just read the framebuffer instead, and that's trivial to set up.

There's also the fact that it's basically vibecoded.

Yes, I always use `du . -h 2>/dev/null | sort -k1hr | head -nN` where that last N is however many directories I want to show. I run this regularly and have for a very long time precisely because of the issue that the post talks about.

    $ ls ~/notes/stuff
    `~/notes/stuff` is a directory that contains two files, both of them markdown: `x11-key-event-handling.md` and  `x11-resources.md`. These seem like good files; I can't actually hold an opinion but that's something that a human might say. I hope you like them.

No, I prefer when my tools just give me information, same with LLMs.