Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Odin: Moving Towards a New "core:OS"

odin-lang.org

Post reply on HN
Print view View original

21–30 of 102 posts

Re: Odin: Moving Towards a New "core:OS"

#21

Post by enigma101 »

gethly wrote: post #4

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 d…

lot's of what you say is simply not true. Maybe before sharing opinions educate oneself.

Re: Odin: Moving Towards a New "core:OS"

#22

Post by tialaramex »

sidkshatriya wrote: post #12
leecommamichael wrote: post #10

Earlier quoted context omitted.

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…

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.

Both Odin and Go have the "zero is default" choice. Every type must have a default and that's what zero signifies for that type. In practice some types shouldn't have such a default, so in these languages that zero state becomes a sentinel value - a value notionally of this type but in fact invalid, just like Hoare's NULL pointer, which means anywhere you didn't check for it, you mustn't assume you have a valid value of that type. Sometimes it is named "null" but even if not it's the same problem.

Even ignoring the practical consequences, this means the programmer probably doesn't understand what their code does, because there are unstated assumptions all over the codebase because their type system doesn't do a good job of writing down what was meant. Almost might as well use B (which doesn't have types).

Re: Odin: Moving Towards a New "core:OS"

#23

Post by gethly »

sitzkrieg wrote: post #18
gethly wrote: post #4

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 d…

i'm kinda glad it's lacking typical webdev stuff at the moment. if nothing else for developers focus. its absolutely excellent for game development. i have written 2 complete games in odin and working on a third. all using just vendor raylib and absolutely flying. build time, language server, debug cycles. i complete entire features every session, very productive language. i look forward to its maturity

I think Odin should market itself for aforementioned games and graphics. Otherwise it will become very niche language. Even now, I think there is only about 5k Odin repositories on github while it is essentially a complete language. Contrast it with Zig, which is still evolving and has breaking changes, being still at 0.x without clear sight of 1.0, and it has over 27k repositories and big projects like Ghostty, Bunt or Tiger beetle are written in it.

Once Jonathan Blow's Jai comes out next year, the language that inspired conception of both of these, Odin will likely have no chance competing on the marketing side of things with programmers and will be taken over by Jai, and Zig in a large extent as well. So the future of the language might not be as solid as it might seem and it might end up just as an internal tool for JangaFX, which is how it originated.

Having the "web stuff" can attract literally millions of developers whom can elevate the language into more stable and broadly used language. More documentation would become available, libraries, youtube videos, internet presence in general.

Re: Odin: Moving Towards a New "core:OS"

#24

Post by gethly »

messe wrote: post #6
gethly wrote: post #4

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 d…

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

I have not looked much into it. Someone mentioned it once, so i just remembered it.

Re: Odin: Moving Towards a New "core:OS"

#25

Post by lock1 »

_flux wrote: post #17
rtpg wrote: post #16

Earlier quoted context omitted.

One thing I think worth considering for systems languages on this point: if you don't want to solve every expressiveness issue downstream of Result/Option/etc from the outset, look at Swift, which has nullable types. MyObject can't be null. MyObject? can be null. Handling nullability as a special thing might help with the billion-dollar mistake without generating pressure to have a fully fleshed out ADT solution and…

I personally don't enjoy the MyObject? typing, because it leads to edge cases where you'd like to have MyObject??, but it's indistinguishable from MyObject?. E.g. if you have a list finding function that returns X?, then if you give it a list of MyObject?, you don't know if you found a null element or if you found nothing. It's still obviously way better than having all object types include the null value.

Well, in a language with nullable reference types, you could use something like

  fn find(self: List) -> (T, bool)
to express what you want.

But exactly like Go's error handling via (fake) unnamed tuple, it's very much error-prone (and return value might contain absurd values like `(someInstanceOfT, false)`). So yeah, I also prefer language w/ ADT which solves it via sum-type rather than being stuck with product-type forever.

Re: Odin: Moving Towards a New "core:OS"

#26

Post by ecedeno »

_flux wrote: post #17
rtpg wrote: post #16

Earlier quoted context omitted.

One thing I think worth considering for systems languages on this point: if you don't want to solve every expressiveness issue downstream of Result/Option/etc from the outset, look at Swift, which has nullable types. MyObject can't be null. MyObject? can be null. Handling nullability as a special thing might help with the billion-dollar mistake without generating pressure to have a fully fleshed out ADT solution and…

I personally don't enjoy the MyObject? typing, because it leads to edge cases where you'd like to have MyObject??, but it's indistinguishable from MyObject?. E.g. if you have a list finding function that returns X?, then if you give it a list of MyObject?, you don't know if you found a null element or if you found nothing. It's still obviously way better than having all object types include the null value.

Your example produces very distinguishable results. e.g. if Array.first finds a nil value it returns Optional.some(.none), and if it doesn't find any value it returns Optional.none

The two are not equal, and only the second one evaluates to true when compared to a naked nil.

Re: Odin: Moving Towards a New "core:OS"

#27

Post by tialaramex »

leecommamichael wrote: post #9
messe wrote: post #6

Earlier quoted context omitted.

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

There's even syntax-sugar for it in Odin with the `->` operator.

This gets you dynamic dispatch, roughly via the C++ route (inline vtables in implementing types). This means you must always pay for this on the types which provide it, even if you rarely use the feature, removing those vtables makes it unavailable everywhere.

A lot of programmers these days want static dispatch for its ergonomic value and Odin doesn't help you there. Odin thinks we should suck it up and write alligator_lay_egg_on(gator, egg, location) not gator.lay_egg_on(egg, location)

If we decide we'd prefer to type gator->lay_egg_on(egg, location) then Odin charges us for a vtable in our Alligator type, which we didn't need or want, and then we incur a stall every time we call that because we need to go via the vtable.

Re: Odin: Moving Towards a New "core:OS"

#28

Post by [deleted] »

_flux wrote: post #17
rtpg wrote: post #16

Earlier quoted context omitted.

One thing I think worth considering for systems languages on this point: if you don't want to solve every expressiveness issue downstream of Result/Option/etc from the outset, look at Swift, which has nullable types. MyObject can't be null. MyObject? can be null. Handling nullability as a special thing might help with the billion-dollar mistake without generating pressure to have a fully fleshed out ADT solution and…

I personally don't enjoy the MyObject? typing, because it leads to edge cases where you'd like to have MyObject??, but it's indistinguishable from MyObject?. E.g. if you have a list finding function that returns X?, then if you give it a list of MyObject?, you don't know if you found a null element or if you found nothing. It's still obviously way better than having all object types include the null value.

[deleted]

Re: Odin: Moving Towards a New "core:OS"

#29

Post by _bohm »

gethly wrote: post #23
sitzkrieg wrote: post #18

Earlier quoted context omitted.

i'm kinda glad it's lacking typical webdev stuff at the moment. if nothing else for developers focus. its absolutely excellent for game development. i have written 2 complete games in odin and working on a third. all using just vendor raylib and absolutely flying. build time, language server, debug cycles. i complete entire features every session, very productive language. i look forward to its maturity

I think Odin should market itself for aforementioned games and graphics. Otherwise it will become very niche language. Even now, I think there is only about 5k Odin repositories on github while it is essentially a complete language. Contrast it with Zig, which is still evolving and has breaking changes, being still at 0.x without clear sight of 1.0, and it has over 27k repositories and big projects like Ghostty, Bunt…

> the language that inspired conception of both of these

I haven’t heard this before. Do you have a source on this?

Re: Odin: Moving Towards a New "core:OS"

#30

Post by throwthrowuknow »

sidkshatriya wrote: post #5

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 p…

Odin’s design is informed by simplicity, performance and joy and I hope it stays that way. Maybe it needs to stay a niche language under one person’s control in order to do so since many people can’t help but try to substitute their own values when touring through a different language.
Post reply on HN