Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Charitably, is this aimed at c/zig heads?
I've been actively toying with Odin in past few days. As a Gopher, the syntax is partially familiar. But as it is a lower level language wiht manual-ish memory management, simple things require much more code to write and a ton of typecasting. Lack of any kind of OOP-ism, like inheritance(bad), encapsulation(ok), or methods(nobrainer), is very spartan and unpleasant in 2025, but that's just a personal preference. I don't think I ever used fully procedural language in my entire life. It requires a complete rewiring on one's brain. Which I'd say is a huge obstacle for most programmers, definitely from the younger crowd. For low-level guys, this is quite a nice and powerful tool. For everyone else, it's a bit of a head ache(even Zig has methods and interfaces). The language still lacks basic things like SQL drivers, solid HTTPS stack, websockets, and essentially anything related to web and networking(which has the bare bones functionality). As a Gopher, I am biased, but the web rules the world, so it is objective complaint. In the end, this is a solid language with great support for 2D and 3D graphics and advanced mathematics, which naturally makes it a very niche language for making games or anything to do with visual programming. Definitely try it out.
PS: I just read a funny comment on YT video: "Odin feels like a DSL for writing games masquerading as a systems language."
Thank you for the comment and trying out Odin, but there are a few things in your comment which seem a bit off to me. Odin is trying to be C alternative, not a Go without GC.
Odin does share a lot of similarities to Go, even including it's distinct type system. So requiring more type casting than your Go code is actually a surprise to me because Odin's rules a little more lax than Go's, but it's probably because you don't cast as often in Go for whatever reason, probably because it's not actually a systems-programming language, it's mostly just for web stuff. You're not actually dealing with different sized integers and floats all the time, you're just using `int` and `float64` in Go. If you had to use more, you'd actually realize Go requires even more casts than Odin.
Odin does lack methods BY DESIGN. It is not a design flaw, like you are thinking it is. And adding methods is not a "no-brainer", or you could argue adding them is a "no-brainer" as in you are not thinking about the consequences of them. We have a FAQ section on this topic entirely, so I won't copy and paste it here: https://odin-lang.org/docs/faq/#but-really-why-does-odin-not...
As for the other stuff you are complaining about: they're just libraries...
Odin is going to get an _official_ http package soon, and it has been in the works for a long time. It's going to be based on the native kernel async APIs (IOCP, io_uring, KQueue, etc), and from our preliminary tests, is a heck of a lot faster than any of approaches done with Go (and even many of the Rust approaches too).
There is a reason that I "vehemently [refuse] this notion and [try] to fight in every podcast" that Odin is only for games. You're literally saying because the official Odin compiler lacks a single official library (`core:net/http` which is in works as I said) for dealing with http, it isn't for web dev? Are you actually serious? There are third party libraries that already do this, but as I said, we are working on an official one already, which will be coming out this year for definite.
But saying it is for gamedev is the most accidental compliment you could give it be gamedev is pretty much the most wide domain possible where you will do virtually every area of programming possible. All your comment told me is that you have no idea what gamedev actually involves.
I like Odin and hope for it to gain more momentum.
I have an important metric for new "systems" languages: does the language allow NULL for it's commonly used pointer type. Rust by default does not (References may _not_ be NULL). Here is where I think Odin makes a mistake.
In the linked blog post Odin mentions ^os.File which means pointer to File (somewhat like *FILE in C). Theoretically the pointer can be NULL. In practice, maybe I would need to check for NULL or maybe I would not (I would have to scan the Odin function's documentation to see what the contract is).
In Rust, if a function returns &File or &mut File or Box<File> etc. I know that it will never be NULL.
So Odin repeats the famous "billion-dollar mistake" (Tony Hoare). Zig in comparison is bit more fussy about NULL in pointers so it wins my vote.
Currently this is my biggest complaint about Odin. While Odin packages a lot of power programming idioms (and feels a bit higher level and ergonomic than Zig) it makes the same mistake that Golang, C and others make regarding allowing NULL in the default pointer type.
Not a Odin user, but iirc odin also has Go like zero values. There is no practical option unless you have null. Like a string cant be null, its "at least" an empty string. But whats a base value for a pointer? A function? An interface? Either you wrap (ocaml style) or use null. Its pragmatism vs correctness, a balance as old as computing.
Anyone have a good comparison of Odin vs C/C++/Rust/Zig/Hare/etc? I'm particularly interested in how simple it is to implement a compiler in the given language.
This is a delight to read. I've been doing a survey of languages over the last several days, and Odin is one of the more interesting ones... but looking at the OS and FS related parts of the standard library made me back away at high velocity. They seemed like litanies of generated code that simply describe every quirk of every platform: not an abstraction at all. And while I do want those levels to be _available_, I also don't want to be dragged down there in every program.
Delighted to see more work will be focused there in the future.
Language explorers looking for lower level languages like this may also want to take a peek at the V language. https://vlang.io/
I won't say with confidence either is better than the other; but I think both are worth a look.
Odin (iiuc) always makes you manage memory; Vlang permits you to, but does also have linking to the Boehm GC that it will generate for you in most cases.
Vlang and Odin in terms of syntax and legibility goals... well. I suggest if you're interested, just quick look will say more than I can. :)
Vlang mentioned, let's goo!
I like low-level languages that provide easy access to a GC. It's a nice way to make some parts of the code more high-level and it kinda avoids the need for a scripting language sometimes.
You should be allowed to prefer or have interest in different languages and not have envious competitors try to blank you out. Which is a strange thing being promoted around here.
Vlang is indeed worthy of a look, as great project, with (at present count) 807 contributors and more than 37,000 stars.
10 comments
[ 3.3 ms ] story [ 30.2 ms ] threadPS: I just read a funny comment on YT video: "Odin feels like a DSL for writing games masquerading as a systems language."
Odin does share a lot of similarities to Go, even including it's distinct type system. So requiring more type casting than your Go code is actually a surprise to me because Odin's rules a little more lax than Go's, but it's probably because you don't cast as often in Go for whatever reason, probably because it's not actually a systems-programming language, it's mostly just for web stuff. You're not actually dealing with different sized integers and floats all the time, you're just using `int` and `float64` in Go. If you had to use more, you'd actually realize Go requires even more casts than Odin.
Odin does lack methods BY DESIGN. It is not a design flaw, like you are thinking it is. And adding methods is not a "no-brainer", or you could argue adding them is a "no-brainer" as in you are not thinking about the consequences of them. We have a FAQ section on this topic entirely, so I won't copy and paste it here: https://odin-lang.org/docs/faq/#but-really-why-does-odin-not...
As for the other stuff you are complaining about: they're just libraries...
Odin is going to get an _official_ http package soon, and it has been in the works for a long time. It's going to be based on the native kernel async APIs (IOCP, io_uring, KQueue, etc), and from our preliminary tests, is a heck of a lot faster than any of approaches done with Go (and even many of the Rust approaches too).
There is a reason that I "vehemently [refuse] this notion and [try] to fight in every podcast" that Odin is only for games. You're literally saying because the official Odin compiler lacks a single official library (`core:net/http` which is in works as I said) for dealing with http, it isn't for web dev? Are you actually serious? There are third party libraries that already do this, but as I said, we are working on an official one already, which will be coming out this year for definite.
I highly recommend reading the following FAQ question to regarding the entirety of 'Is Odin "just" a language for game development?": https://odin-lang.org/docs/faq/#is-odin-just-a-language-for-...
But saying it is for gamedev is the most accidental compliment you could give it be gamedev is pretty much the most wide domain possible where you will do virtually every area of programming possible. All your comment told me is that you have no idea what gamedev actually involves.
I have an important metric for new "systems" languages: does the language allow NULL for it's commonly used pointer type. Rust by default does not (References may _not_ be NULL). Here is where I think Odin makes a mistake.
In the linked blog post Odin mentions ^os.File which means pointer to File (somewhat like *FILE in C). Theoretically the pointer can be NULL. In practice, maybe I would need to check for NULL or maybe I would not (I would have to scan the Odin function's documentation to see what the contract is).
In Rust, if a function returns &File or &mut File or Box<File> etc. I know that it will never be NULL.
So Odin repeats the famous "billion-dollar mistake" (Tony Hoare). Zig in comparison is bit more fussy about NULL in pointers so it wins my vote.
Currently this is my biggest complaint about Odin. While Odin packages a lot of power programming idioms (and feels a bit higher level and ergonomic than Zig) it makes the same mistake that Golang, C and others make regarding allowing NULL in the default pointer type.
Delighted to see more work will be focused there in the future.
I won't say with confidence either is better than the other; but I think both are worth a look.
Odin (iiuc) always makes you manage memory; Vlang permits you to, but does also have linking to the Boehm GC that it will generate for you in most cases.
Vlang and Odin in terms of syntax and legibility goals... well. I suggest if you're interested, just quick look will say more than I can. :)
Vlang is indeed worthy of a look, as great project, with (at present count) 807 contributors and more than 37,000 stars.