Ginger Bill, creator of the Odin programming language, writes about language design, memory allocation, and programming practice.
HN commenters point to his memory allocation strategies series as a strong resource and cite his posts on Odin's design, such as exceptions and declaration syntax.
'We believe that data and code should be separate concepts; data should not have “behaviour”.' is flawed, but I don't believe that's the point being made. Instead, I believe the point actually roots in a "programmer mindset" thing when using methods/member functions, due to this explicit separation of data and procedures. With methods/member functions you naturally fall into an "individual element" mindset, see https://www.gingerbill.org/article/2026/01/02/was-it-really-a-billion-dollar-mistake/ - yes it's semantically equivalent (given the examples in the article and many other cases), but humans are humans and they are biased.
In my opinion: there is a better argument for making new languages not have methods, or more accurately member functions (as what the author describes).
Consider the following situation: you are user of a library that declares a type called SomeType which has "methods" (member functions) in it. You want to add more "methods" to this type.
Now, there is a problem regarding consisteny w.r.t syntax, your new "methods" now have to be called via `foo(&bar)` instead of `bar.foo()`. You as a user of the library and language have to choice to make (regarding code style):
1. Accept this difference in syntax. Maybe you like this style difference, because now you can clearly see what procedures are declared in your codebase vs. the library's codebase, or:
2. Use freeform functions everywhere. Well actually, you can't do this without a refactor of the…
I think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
[1] https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/
I have read the post about exceptions: https://www.gingerbill.org/article/2018/09/05/exceptions-and-why-odin-will-never-have-them/.
I did not personally mind Odin's exceptions, to be honest. I prefer Odin's way, and Go's way, too.
> you'll have to dig for them yourself.
Yeah I was referring to such specifics, but I will take a look at Discord perhaps.
> "Code indentation that is anything but 2, 3, 4, or 8 characters wide, is objectively a bad style from a pure aesthetics standpoint"
Those are just opinions. I prefer 2 spaces, or tab with 2 column width. I tend stick to one style in my codebase, consistently. I do not like anything longer than 2, because I have a small screen and I think it is just simply redundant. I can follow 2 column width indentation just fine. This is just my opinion. If I use tabs, people can choose their own, it is up to them.
Personally I've heard Odin [1] to do a decent job with this, at least from what I've superficially learned about its stdlib and included modules as an "outsider" (not a regular user).
It appears to have things like support for e.g. image file formats built-in, and new things are somewhat liberally getting added to core if they prove practically useful, since there isn't a package manager in the traditional sense.
Here's a blog post by the language author literally named "Package Managers are Evil" [2]
(Please do correct me if this is wrong, again, I don't have the experience myself.)
[1] https://pkg.odin-lang.org/
[2] https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/
I took some shit in the comments yesterday for suggesting "you can do it with a few lines of standard C++" to another similar thread, but yet again here we are.
Defer takes 10 lines to implement in C++. [1]
You don't have to wait 50 years for a committee to introduce basic convenience features, and you don't have to use non-portable extensions until they do (and in this case the __attribute__((cleanup)) has no equivalent in MSVC), if you use a remotely extensible language.
[1] https://www.gingerbill.org/article/2015/08/19/defer-in-cpp/
In the follow up article, I wrote something like this in the conclusion:
> Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly.
Follow-up Article: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/