7 ms·

Odin: Moving Towards a New "core:OS"

135 points by ksec 10mo ago

MangoToupe 10mo ago
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?
- BigJono 10mo ago
  I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
  - astrange 10mo ago
    That's a pretty heavyweight pattern. Wouldn't dynamic scope be better?
    - miningape 10mo ago
      As another commenter wrote "how do you allocate memory without an allocator?" Even `malloc` has overhead. > Wouldn't dynamic scope be better? Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way. Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.
      - johnisgood 10mo ago
        > and to an extent Odin does do this already with `context.allocator` It has a temporary allocator as well, which could track memory leaks. Not so much anymore though, IIRC. > As another commenter wrote "how do you allocate memory without an allocator? I would like to point out that this is basic knowledge. At first I was wondering if I have gone insane and it really is not the case anymore or something.
        deleted 10mo ago
        [deleted]
      - MangoToupe 10mo ago
        > As another commenter wrote "how do you allocate memory without an allocator?" You call these things something other than an "allocating" and "allocators". Seriously, few people would consider adding a value to a hashmap an intentionally allocational activity, but it is. Same with adding an element to a vector, or any of the dependent actions on it. Seriously
        tialaramex 10mo ago
        For "adding an element to a vector" it's actually not necessarily what you meant here and in some contexts it makes sense to be explicit about whether to allocate. Rust's Vec::push may grow the Vec, so it has amortized O(1) and might allocate. However Vec::push_within_capacity never grows the Vec, it is unamortized O(1) and never allocates. If our value wouldn't fit we get the value back instead.
        miningape 10mo ago
        Yep exactly, at it's simplest all an allocator is doing is keeping track of which memory areas are owned and their addresses. In a sense even the stack pointer is a kind of allocator (you can assign the memory pointed to by the stack pointer and then increment it for the next use)
      - astrange 10mo ago
        > Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this Not necessarily, you can imagine that malloc() itself has an API that says "temporarily switch calls on this thread to a different allocator" and then you undo it later.
- messe 10mo ago
  > All procedures that returned allocated memory will require an explicit allocator to be passed All procedures in core/os. Odin isn't removing the allocator from implicit context in the rest of its APIs.
- leecommamichael 10mo ago
  All you've got to do is write `context.allocator` to abide.
- ycombinatrix 10mo ago
  How do you allocate memory without an allocator?
  - tialaramex 10mo ago
    The usual thing for languages is to provide a global allocator. That's what C's malloc is doing for example. We're not asked to specify the allocator, it's provided by the language runtime so it's implied everywhere. In standalone C, or Rust's no_std, there is no allocator provided, but most people aren't writing bare metal software.
    - ycombinatrix 10mo ago
      That creates problems when you need to use multiple allocators. IMO allowing an allocator to be specified is a superior design.
      - MangoToupe 10mo ago
        If you need multiple allocators, and you aren't already using lisp, who cares? Just use lisp. Anyone who can use allocators against the C abi can clearly see the benefits of using a language that can cater to the developer. Zig can never do this, yea even with its shallow macros. Zig will always be a shitty B knockoff rather than something artisans actually want to use
  - MangoToupe 10mo ago
    You call the use of memory something other than "allocation". Ez. I thought that passing down allocators was core to the language. I was mistaken. This is actually quite nice for writing allocation code when you'd like to opt into it.
gethly 10mo ago
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."
- enigma101 10mo ago
  lot's of what you say is simply not true. Maybe before sharing opinions educate oneself.
- messe 10mo ago
  > even Zig has methods and interfaces Zig doesn't have interfaces as a language level feature. It uses manually implemented vtables and wrapper methods. You can do the same in Odin with wrapper functions around a vtable.
  - leecommamichael 10mo ago
    There's even syntax-sugar for it in Odin with the `->` operator.
    - messe 10mo ago
sidkshatriya 10mo ago
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.
- leecommamichael 10mo ago
  Odin offers a Maybe(T) type which might satisfy your itch. It's sort of a compromise. Odin uses multiple-returns with a boolean "ok" value for binary failure-detection. There is actually quite a lot of syntax support for these "optional-ok" situations in Odin, and that's plenty for me. I appreciate the simplicity of handling these things as plain values. I see an argument for moving some of this into the type-system (using Maybe) when it comes to package/API boundaries, but in practice I haven't chosen to use it in Odin.
  - sidkshatriya 10mo ago
    All the standard libraries use naked ^T . Maybe(T) would be for my own internal code. I would need to wrap/unwrap Maybe at all interfaces with external code. In my view a huge value addition from plain C to Zig/Rust has been eliminating NULL pointer possibility in default pointer type. Odin makes the same mistake as Golang did. It's not excusable IMHO in such a new language.
    - tialaramex 10mo ago
apitman 10mo ago
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.
- miningape 10mo ago
  Don't have a comparison, but I've written toy languages in a few of them. I only really feel confident to talk about Rust, Rust stands out when it comes to parsing (functional bros unite), but does suffer when interpreting because of unsafe memory access - although for a compiler that shouldn't be an issue. Odin is great, but I feel like it doesn't have enough syntax sugar to make languages easy to work on - that being said you can achieve most of what you want in a mostly comparable way if you're willing to write more ugly code. In this way it's very similar to C.
  - brabel 10mo ago
    Odin has dynamic arrays, dynamic hash tables and generics so imho it’s far from C and closer to D and Go, except for not having GC. It occupies the space between D/Go and C I would say.
- ecshafer 10mo ago
  Odin is more similar to Zig or C, very similar to Zig I think, but less boiler plate and more similar to Go syntactically. I have also found Odin to be a bit more friendly than Zig to get compiling and running, less required safety. There is far fewer features so I wouldn't really compare it to C++ or Rust. I am not familiar with Hare.
- Kapendev 10mo ago
  I wrote a simple benchmark comparing my custom dynamic array implementation in Dlang with dynamic arrays in other languages. The test appends and then removes 100,000,000 integers on a Ryzen 3 2200G with 16 GB RAM. This is just a rough cross-language benchmark and not something serious: Appending and removing 100000000 items... Testing: ./app_d real 0.16 user 0.03 sys 0.12 Testing: ./app_zig real 0.18 user 0.05 sys 0.13 Testing: ./app_odin real 0.27 user 0.10 sys 0.16 Code and benchmark files are here: https://github.com/Kapendev/joka/tree/main/benchmarks/array_append_remove/others https://github.com/Kapendev/joka/tree/main/benchmarks/array_...
heavenlyhash 10mo ago
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.
heavenlyhash 10mo ago
Language explorers looking for lower level languages like this may also want to take a peek at the V language. https://vlang.io/ 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. :)
- Kapendev 10mo ago
  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.
- baranul 10mo ago
  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.

135 points by ksec 10mo ago

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?

BigJono 10mo ago
I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
- astrange 10mo ago
  That's a pretty heavyweight pattern. Wouldn't dynamic scope be better?
  - miningape 10mo ago
    As another commenter wrote "how do you allocate memory without an allocator?" Even `malloc` has overhead. > Wouldn't dynamic scope be better? Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way. Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.
    - johnisgood 10mo ago
      > and to an extent Odin does do this already with `context.allocator` It has a temporary allocator as well, which could track memory leaks. Not so much anymore though, IIRC. > As another commenter wrote "how do you allocate memory without an allocator? I would like to point out that this is basic knowledge. At first I was wondering if I have gone insane and it really is not the case anymore or something.
      - deleted 10mo ago
        [deleted]
    - MangoToupe 10mo ago
      > As another commenter wrote "how do you allocate memory without an allocator?" You call these things something other than an "allocating" and "allocators". Seriously, few people would consider adding a value to a hashmap an intentionally allocational activity, but it is. Same with adding an element to a vector, or any of the dependent actions on it. Seriously
      - tialaramex 10mo ago
        For "adding an element to a vector" it's actually not necessarily what you meant here and in some contexts it makes sense to be explicit about whether to allocate. Rust's Vec::push may grow the Vec, so it has amortized O(1) and might allocate. However Vec::push_within_capacity never grows the Vec, it is unamortized O(1) and never allocates. If our value wouldn't fit we get the value back instead.
      - miningape 10mo ago
        Yep exactly, at it's simplest all an allocator is doing is keeping track of which memory areas are owned and their addresses. In a sense even the stack pointer is a kind of allocator (you can assign the memory pointed to by the stack pointer and then increment it for the next use)
    - astrange 10mo ago
      > Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this Not necessarily, you can imagine that malloc() itself has an API that says "temporarily switch calls on this thread to a different allocator" and then you undo it later.
messe 10mo ago
> All procedures that returned allocated memory will require an explicit allocator to be passed All procedures in core/os. Odin isn't removing the allocator from implicit context in the rest of its APIs.
leecommamichael 10mo ago
All you've got to do is write `context.allocator` to abide.
ycombinatrix 10mo ago
How do you allocate memory without an allocator?
- tialaramex 10mo ago
  The usual thing for languages is to provide a global allocator. That's what C's malloc is doing for example. We're not asked to specify the allocator, it's provided by the language runtime so it's implied everywhere. In standalone C, or Rust's no_std, there is no allocator provided, but most people aren't writing bare metal software.
  - ycombinatrix 10mo ago
    That creates problems when you need to use multiple allocators. IMO allowing an allocator to be specified is a superior design.
    - MangoToupe 10mo ago
      If you need multiple allocators, and you aren't already using lisp, who cares? Just use lisp. Anyone who can use allocators against the C abi can clearly see the benefits of using a language that can cater to the developer. Zig can never do this, yea even with its shallow macros. Zig will always be a shitty B knockoff rather than something artisans actually want to use
- MangoToupe 10mo ago
  You call the use of memory something other than "allocation". Ez. I thought that passing down allocators was core to the language. I was mistaken. This is actually quite nice for writing allocation code when you'd like to opt into it.

gethly 10mo ago

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."

enigma101 10mo ago
lot's of what you say is simply not true. Maybe before sharing opinions educate oneself.
messe 10mo ago
> even Zig has methods and interfaces Zig doesn't have interfaces as a language level feature. It uses manually implemented vtables and wrapper methods. You can do the same in Odin with wrapper functions around a vtable.
- leecommamichael 10mo ago
  There's even syntax-sugar for it in Odin with the `->` operator.
  - messe 10mo ago

sidkshatriya 10mo ago

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.

leecommamichael 10mo ago
Odin offers a Maybe(T) type which might satisfy your itch. It's sort of a compromise. Odin uses multiple-returns with a boolean "ok" value for binary failure-detection. There is actually quite a lot of syntax support for these "optional-ok" situations in Odin, and that's plenty for me. I appreciate the simplicity of handling these things as plain values. I see an argument for moving some of this into the type-system (using Maybe) when it comes to package/API boundaries, but in practice I haven't chosen to use it in Odin.
- sidkshatriya 10mo ago
  All the standard libraries use naked ^T . Maybe(T) would be for my own internal code. I would need to wrap/unwrap Maybe at all interfaces with external code. In my view a huge value addition from plain C to Zig/Rust has been eliminating NULL pointer possibility in default pointer type. Odin makes the same mistake as Golang did. It's not excusable IMHO in such a new language.
  - tialaramex 10mo ago

apitman 10mo ago

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.

miningape 10mo ago
Don't have a comparison, but I've written toy languages in a few of them. I only really feel confident to talk about Rust, Rust stands out when it comes to parsing (functional bros unite), but does suffer when interpreting because of unsafe memory access - although for a compiler that shouldn't be an issue. Odin is great, but I feel like it doesn't have enough syntax sugar to make languages easy to work on - that being said you can achieve most of what you want in a mostly comparable way if you're willing to write more ugly code. In this way it's very similar to C.
- brabel 10mo ago
  Odin has dynamic arrays, dynamic hash tables and generics so imho it’s far from C and closer to D and Go, except for not having GC. It occupies the space between D/Go and C I would say.
ecshafer 10mo ago
Odin is more similar to Zig or C, very similar to Zig I think, but less boiler plate and more similar to Go syntactically. I have also found Odin to be a bit more friendly than Zig to get compiling and running, less required safety. There is far fewer features so I wouldn't really compare it to C++ or Rust. I am not familiar with Hare.
Kapendev 10mo ago
I wrote a simple benchmark comparing my custom dynamic array implementation in Dlang with dynamic arrays in other languages. The test appends and then removes 100,000,000 integers on a Ryzen 3 2200G with 16 GB RAM. This is just a rough cross-language benchmark and not something serious: Appending and removing 100000000 items... Testing: ./app_d real 0.16 user 0.03 sys 0.12 Testing: ./app_zig real 0.18 user 0.05 sys 0.13 Testing: ./app_odin real 0.27 user 0.10 sys 0.16 Code and benchmark files are here: https://github.com/Kapendev/joka/tree/main/benchmarks/array_append_remove/others https://github.com/Kapendev/joka/tree/main/benchmarks/array_...

heavenlyhash 10mo ago

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.

heavenlyhash 10mo ago

Language explorers looking for lower level languages like this may also want to take a peek at the V language. https://vlang.io/ 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. :)

Kapendev 10mo ago
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.
baranul 10mo ago
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.