If I believe in your mission, I am open to engineering work. I prefer systems languages and deeply technical/mathy problems, but I'll write Typescript with minimal complaining for a good cause.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I'm confused by this because I simultaneously agree with Bill by the examples given in the article; things like "ricing" Linux and Vim, but I also advertise Odin as being great due to this friction which may be seen as a limitation.
My favorite example is Odin's approach to metaprogramming and compile-time features. Odin is featureful in this regard, but not nearly to the extent that other languages are (D, Zig, Nim, C++, C) and it may have been the deciding reason I've written far more Odin than any of those other languages.
I _can't_ just do whatever I want at compile-time in Odin. That's a blessing for people like me. I toy with the compiler. I admire languages and language design, and toying with them, learning all of the features, is an expression of that interest. For Odin, there really aren't many novel features for you to toy with. It's just not a toy at all. I don't mean "toy" in then derogatory sense, or to designate others as such. I simply mean that Odin is just not fun to fiddle with, you use it to do something.
Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.
Personally, of that sample I prefer Go and Odin. I find compilers to be terribly fun puzzles, and I love to learn languages inside and out. That's great and all, but I also have to get things done, and I find Go and Odin have a certain... rudimentary feeling which keeps me focused. Go less-so than Odin. I've written quite a lot of Swift in my life, and find it to be the absolute worst language for me in terms of this kind of "distracted energy." There are so many ways to abstract things in Swift, the tool bag is just so deep, and I do get a bit frustrated by the sluggishness of the compiler. I had a work project take us 30 minutes for a clean build, and those of us who have used Xcode know that unfortunately a clean build is not as rare as in some other systems. Maybe this has changed. It's been 4 years since I've done serious work with Swift. Glad to see they stopped making so many breaking changes, though.
EDIT: Actually Typescript is more distracting than Swift. I could spend days toying with the type-checker to make the program sturdier against one change or another.
> So, is taste another way of saying you still know better?
I think that's part of the picture, and that applies to "how to respond to LLM output" but I think people are getting at the stuff that happens before you even reach for the LLM. Taste dictates what you decide is non-negotiable, i.e. the goal of what you're doing. So yeah, what you choose to do differentiates you because it's an expression of your goals and values. It's kind of vacuously true, and probably worth each of us thinking how we can be more authentically ourselves and how to guide ourselves through decisions. No one can make them for you, letting others make your life's decisions has always resulted in slop. So how much can you outsource and still be yourself? I know I could ask someone to make my breakfast each day and I'd still be me, but I wouldn't expect that to be true of everyone. Maybe it's true for a lot of chefs, but probably not all of them. We're complicated like that.
This is something that concerns me about this technology. It's just not going to serve some people well to reach their goals. The odds weren't right. Not enough context. No clear way to surface the right context. The result is a kind of loneliness, but it's the kind when you've got a bunch of shallow "friends," when you really need a mentor who doesn't have a plan for you, who is truly wiser than you, or can see you from the distance required to advise, can step away, has real life experiences.
I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.
Go famously used machine translation to remove dependency from C. It's a nice way to retain structural familiarity with the target language. I imagine they could've saved a large portion of that $165,000 using this route. Hard to say for certain, though. You wouldn't want to scope that transpiler at "being able to transpile all programs generally," and so scoping the project does become a serious task.
> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026.
The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many.
I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle.
I do not claim that these reasons apply to everyone.
> For signed integers, the operations +, -, *, /, and << may legally overflow and the resulting value exists and is deterministically defined by the signed integer representation. Overflow does not cause a runtime panic. A compiler may not optimize code under the assumption that overflow does not occur. For instance, x < x+1 may not be assumed to be always true.
There are a lot of people blaming the iD for having their own tech. Programming is partly an artistic endeavor. Games programming can especially be so, part of the market is based in novelty, and doing new things sometimes requires new/different capabilities.
What would you say is similar between Odin and Jai? I briefly used Jai (I have never had access) and found that essentially only declaration syntax is familiar.
Interactive applications where a GC is not an option.
Rust is shockingly good at being a general purpose language, but that's in the face of the strict semantics of the language and approach to memory. There became a comparison against Go because Go offers strong performance and a complete opposite memory-management experience (in having a GC that largely solves it for you.) Odin sits between these two levels of friction, leaning far more on the Go side of things. There are goodies in Odin which make memory management much breezier than other manual languages, but I'll admit it is still a task you are expected to complete.
So that's the story on the memory-management effort. That aside, I'd say Odin is best for interactive applications where a GC is not an option. Although at this point it comes out of my hands so easily that I'd probably write Odin in some situations where it'd be less optimal, and it'd be fun so why not?
I've been using and loving Odin for probably around 5 years now, with this past couple years being more seriously invested in it. After tens of thousands of lines of code I'm still very happy. If you like C, but feel it's missing a few things, I highly recommend giving Odin a shot. Among the new litter of "better C" languages, Odin is easily the lowest-friction. It makes for a very nice experience. Congratulations, gingerBill.
That’s fair, I think I’m mostly referring to their assessment of how they could possibly come to evaluate his position as BDFL (which I realize is totally subjective) and I disliked that they didn’t bother trying to talk to him… which I’m not being super rational about, people in his position aren’t always accessible.
I think part of being well-reasoned is being honest, and they're certainly being honest. I don't agree with their means, though. Bill is a complex person, and you don't have to stalk him to learn about him. He interacts with newbies plenty in the Discord server. I find him to be pretty nice in those interactions.
>There are two ways one can "figure out a person" who rarely states their beliefs explicitly, specifically a public figure:
>You can infer from their descriptions and prescriptions about things—that's slow, takes times, but it will give you the most accurate image to the extent of the public information.
See who they follow on Twitter.
This feels like an appeal to tribalism against Bill.
My politics are left-leaning and I sponsor Bill/Odin. I even cancelled several subscriptions to donate more monthly. I dislike the politicizing in this article as a means of deciding whether Bill's statements on Wikipedia are valid. Let his stated rhetoric be as it is written, and judge that. Bill may seem blunt, especially by his word online, but I have seen too much truly benevolent behavior from the guy in the Odin Discord server over the years not to believe he's a decent man. He's very patient with newcomers, has been inclusive to a diverse group of people in the server, and puts in a ton of work to help people focus on their needs/problems in their pursuit to becoming better programmers. The guy really cares, and has managed to attract a host of very reliable people who are uber helpful and knowledgeable. (Shoutout @Barinzaya)
If you haven't tried Odin, it's worth a close look. I believe it has an insane ratio of shipped, production software to popularity for a reason. The language works. There are a lot of ideas in it which point you toward great productivity. It feels like a "common C." C is hard to collaborate with for rich GUI applications. C invites mess in the absence of very strong principles and habits, but having formed those makes for notoriously opinionated programmers. I see Odin as a language which allows "people who like C" to work together. I happen to like it more than the more popular stuff. A lot more. I'd rather use Rust if lives were at stake, but Zig is too much friction for me to still end up with an unsafe program. Odin feels just right.
Whether Odin belongs on Wikipedia or not; it's inarguably popular for a programming language. You have to understand there are tens of thousands of languages, and hundreds created each year... maybe thousands more. You'd probably be irked by Wikipedia as well if you were in his position. Maybe even provoked to say some things which are highly critical of it. Personally, I think Wikipedia is a decent historical encyclopedia, but it's not at all good at "pop culture" and that's what we're talking about.
Programming is the art of applying math to solve problems. What kind of problems do you want to work on? That determines how much math to know, and what kind of programming you'll be needing to learn manually before you start offloading morsels to the bot.
If I believe in your mission, I am open to engineering work. I prefer systems languages and deeply technical/mathy problems, but I'll write Typescript with minimal complaining for a good cause.