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

31–40 of 102 posts

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

#31

Post by skydhash »

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

I like go’s approach on having default value, which for struct is nil. I don’t think I’ve ever cared between null result and no result, as they’re semantically the same thing (what I’m looking for doesn’t exist)

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

#32

Post by miningape »

astrange wrote: post #11
BigJono wrote: post #3

Earlier quoted context omitted.

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

That's a pretty heavyweight pattern. Wouldn't dynamic scope be better?

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.

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

#33

Post by imiric »

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…

Popularity is not required for a language to be "successful". An argument can be made that popularity can bring fragmentation, a lack of focus, security and usability issues via poor quality code and outdated information, and overwhelm core developers. Just take a look at JavaScript and Python ecosystems. Whereas less popular languages like Nim, Zig, Odin, etc., thrive within their niches.

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

#34

Post by Yokohiii »

_bohm wrote: post #29
gethly wrote: post #23

Earlier quoted context omitted.

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?

The language is in closed beta, there isn't exhaustive details available. You can see interviews and some details on YT if you look up Jon(athan) Blow with suitable topics.

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

#35

Post by binary132 »

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.

not every new language needs to conform to your ideas of what is or isn’t excusable / acceptable.

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

#36

Post by throwthrowuknow »

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…

Please read gingerbill’s blog to understand more about why Odin is designed the way it is https://www.gingerbill.org/article/

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

#37

Post by _flux »

ecedeno wrote: post #26
_flux wrote: post #17

Earlier quoted context omitted.

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.

What language is this? I'd expect a language with a ? -type would not use an Optional type at all.

In languages such as OCaml, Haskell and Rust this of course works as you say.

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

#38

Post by Yokohiii »

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…

Did Jon state that he intends to release as open source? I am not sure he is the guy to the stressful route. If it all he would probably go long release cycles without considering public feedback too much.

He also stated recently that he doesn't care too much about language design at a syntax level, or better said it's not his top focus as the overarching concepts are more important to him.

I think there is a chance that people may have a hard time to adopt to the language. His strong focus on gamedev will further cut down the audience. It will certainly draw a lot of attention but a massive adoption is highly questionable.

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

#39

Post by _flux »

lock1 wrote: post #25
_flux wrote: post #17

Earlier quoted context omitted.

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…

How does this work if it is given an empty list as a parameter?

I guess if one is always able to construct default values of T then this is not a problem.

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

#40

Post by noelwelsh »

tialaramex wrote: post #20
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 like to think about how many problems a feature solves to judge whether it's "worth it". I believe that the Sum types solve enough different problems that they're worth it, whereas nullability solves only one problem (the C-style or Java-style null object) the Sum types can solve that with Option and also provide error handling with Result and control flow with ControlFlow among others so that's already a better de…

Erased generics give parametricity, which most PL people think is fairly important. See https://en.wikipedia.org/wiki/Parametricity or https://www.cl.cam.ac.uk/teaching/1617/L28/parametricity.pdf
Post reply on HN