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 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.
"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.
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."
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:
I think a lot of Rust's cognitive load comes from things unrelated to borrow-checking.
At the same time I don't think it can be said that Zig's compilation speed can be credited to the absence of borrow-checking.
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.
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.
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.
ngrilly | 11 hours ago
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.
LesleyLai | 2 hours ago
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
lilac | 8 hours ago
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.
lukasl | 7 hours ago
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.
trousers | 7 hours ago
My counter position: go devs should wait for roc, jai, or zig, to hit 1.0... and just keep using go in the meantime.
vforvaline | 11 hours ago
"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.
zmitchell | 10 hours ago
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.
vforvaline | 10 hours ago
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?
zmitchell | 9 hours ago
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.
untitaker | 9 hours ago
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."
zmitchell | 9 hours ago
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:
untitaker | 8 hours ago
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:
zmitchell | 8 hours ago
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).
untitaker | 8 hours ago
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.
vforvaline | 9 hours ago
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.
zmitchell | 9 hours ago
I wouldn't say I'm "so" focused on Rust, you mentioned it and I used it as an example...
andyc | 8 hours ago
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.
rpjohnst | 3 hours ago
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.
yorickpeterse | 6 hours ago
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.
neilmadden | 4 hours ago
Lack of memory safety means a programming language cannot protect its own abstractions. Everything built on top of that rests on sand.
jrwren | 10 hours ago
https://go.dev/doc/faq#go_or_golang
WilhelmVonWeiner | 8 hours ago
Don't care, golang is clearer. Same reason people call the Nix language nixlang.
ManuLinares | 11 hours ago
The author presumed other C-family systems languages lacked field metadata and vectorized math. In reality, C3 has built-in support for both concepts.
telemachus | 10 hours ago
It has at least one: Karl Zylinski's Understanding the Odin Programming Language.
ghthor | 5 hours ago
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.