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?