Golang developers should try Odin
18 points by cgrinds
18 points by cgrinds
I don't understand the insistence on memory leaks and at the same time no mention of use-after-free and type confusion, the latter being the real challenge with manual memory management.
I've repeatedly seen people accusing Rust of being "claim to be memory safe but can have memory leak". It's widely used red herring
useful context from prior discussion of odin on lobsters: https://lobste.rs/s/5rvgim/odin_1_0_announcement#c_httxa2
I will be sticking with go, thanks.
I don't see why would a person using Go look at language with thread-based concurrency, manual memory management and very limited ecosystem. The article doesn't really give any good reasons. I'd say you should only do it when doing something low level, where GC and the compiler backend with integrated runtime is causing problems, but if you are writing regular server apps, like most Go devs do, there aren't many advantages of Odin.
My counter position: go devs should wait for roc, jai, or zig, to hit 1.0... and just keep using go in the meantime.
"If you read pointer after free() or delete(), you will get random value"
This sentence is pretty revealing just how misunderstood undefined behaviour is by the author.
There is no excuse for not being memory safe in 2026. Garbage collectors are absurdly fast. Use Rust if you still can't afford the overhead. But trying to downplay the lack of memory safety is pretty ignorant.
Memory safety is one kind of bug, not the end-all-be-all of bug killers. It's a trade-off, and I say this as someone that writes Rust professionally and as a hobbyist since 2018.
I did not imply that it was a "end-all-be-all" of bug killers?
And no, it is not a "trade-off". A trade-off implies you gain something in exchange of memory safety, what exactly are you gaining here?
If you can't recognize that each choice has a tradeoff...that's not a great place to start a discussion.
The borrow checker disallows a range of valid programs, for example. In those cases you gain compile-time checked memory safety, lose the ability to write some valid programs, and increase cognitive load thinking about how to satisfy the borrow checker in some circumstances. That is by definition a trade off.
If you can't recognize that each choice has a tradeoff...that's not a great place to start a discussion.
I wish people who say "everything has a tradeoff" would actually be more explicit about the tradeoffs they're making. I don't see any discussion of tradeoffs made in Odin's language design, just the usual reactionary stuff: Jabs at "people with the programming socks" and downplaying risks.
Fine, the language is very new to the point there's no docs yet. But it's still described as "ready."
I can't tell if the "everything is a tradeoff" person you're talking about is me or not because I have an example in that same comment.
I don't actually know Odin, so I have no idea what the rest of your comment is talking about (socks? what?).
For a bunch of languages there's obvious tradeoffs:
Like vforvaline i think you over-indexed on Rust and borrow-checking (and discussing tradeoffs specifically related to Rust's borrow checker, not inherent to memory safety) and I was trying to steer the discussion back to the actual OP about Odin. The things I'm talking about are right in the article.
For your list of tradeoffs, in order:
Sure, but to be clear I wasn't talking about the borrow checker in that list. I never said Zig's compilation speed came from the lack of a borrow checker (I don't know where you got that from).
I never said Zig's compilation speed came from the lack of a borrow checker
You said there are tradeoffs. I took that to mean, tradeoffs made when designing a new language. I.e. Odin gained something by not having memory safety.
If we're not talking about Odin's design then there's no point. Then it would just be another boring programming language war.
Every choice is indeed a trade-off, but the risks here are so great and so well-documented that it is simply unreasonable.
Odin markets itself as a general-purpose programming language. Not for use-cases where this trade-off would even make sense (embedded, kernel development, etc). Another programming language which takes this trade-off where it actually makes sense is Hare.
Additionally, why are you so focused on Rust? For 99% tasks, a garbage collected language would be just fine (something like Swift or Go). I intentionally mentioned that before Rust.
I feel this (imo, fruitless) discussion must've taken place a million times already.
If you read pointer after free() or delete(), you will get random value
This sentence is pretty revealing just how misunderstood undefined behaviour is by the author
the risks here are so great and so well-documented that it is simply unreasonable.
I think you have made an error in reasoning -- the risks with C's undefined behavior are well documented.
Odin's behavior is not C's behavior. What are the risks there?
Specifically, "random value" is a very different thing from "attacker-controlled value". It's defined behavior, not undefined behavior.
They're one and the same thing. Odin doesn't go out of its way to detect and handle use after free to provide you with that random value. All that "random value" means is that Odin does exactly what C does, and is just as susceptible to attacker-controlled values.
It may be a trade-off, but it's one hell of a trade-off to go from a reasonable amount of memory safety as offered by e.g. Go, to "here's a gun, don't shoot yourself in the foot" levels of no memory safety.
Lack of memory safety means a programming language cannot protect its own abstractions. Everything built on top of that rests on sand.
The author presumed other C-family systems languages lacked field metadata and vectorized math. In reality, C3 has built-in support for both concepts.
Lastly, it does not have...books
It has at least one: Karl Zylinski's Understanding the Odin Programming Language.
I personally don’t care too much for go other than it making it easy to parallelize anything. The main sellers for me are the tooling and the maintenance cost being almost zero friction compared to any other ecosystem. That keeps me gophering for the foreseeable future.