Odin: Moving Towards a New "core:OS" • Hacker News Board

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

#61

Post by heavenlyhash » Wed, Dec 31, 2025, 2:58 PM UTC

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…

I'm an advocate for "both".

- `Option` and `Result` at core;

- `?T` and `T!E` as type declaration syntax that desugars to them;

- and `.?` and `.!` operators so chains like `foo()?.bar()!.baz()` can be written and all the relevant possible return branches are inserted without a fuss.

Having `Option` and `Result` be simply normal types (and not special-casing "nullable") has benefits that are... obvious, I'd say. They're just _normal_. Not being special cases is great. Then, having syntactic sugars to make the very, _very_ common cases be easy to describe is just a huge win that makes correct typing more accessible to many more people by simply minimizing keystrokes.

The type declaration sugar is perhaps merely nice to have, but I think it really does change the way the average programmer is willing to write. The chaining operators, though... I would say I borderline can't live without those, anymore.

Chaining operators can change the SLOC count of some functions by as much as... say, 75%, if we consider a language like Go with it's infamous "if err not nil" clause that is mandated to spread across three lines.

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

#62

Post by [deleted] » Wed, Dec 31, 2025, 3:03 PM UTC

tialaramex wrote: post #27

leecommamichael wrote: post #9

Earlier quoted context omitted.

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

[deleted]

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

#63

Post by MangoToupe » Wed, Dec 31, 2025, 3:30 PM UTC

miningape wrote: post #32

astrange wrote: post #11

Earlier quoted context omitted.

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

> 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

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

#64

Post by tialaramex » Wed, Dec 31, 2025, 3:38 PM UTC

noelwelsh wrote: post #57

tialaramex wrote: post #48

Earlier quoted context omitted.

I mean, yeah, type erasure does give parametricity, but, you can instead design your language so that you monomorphize but insist on parametricity anyway. If you write stable Rust your implementations get monomorphized but you aren't allowed to specialize them - the stable language doesn't provide a way to write two distinct versions of the polymorphic function. And if you only regard parametricity as valuable rather…

I don't understand your first paragraph. Monomorphization and parametricity are not in conflict; the compiler has access to information that the language may hide from the programmer. As an existance proof, MLTon monomorphizes arrays while Standard ML is very definitely parametric: http://www.mlton.org/Features I agree that maintaining parametricity or not is a design decision. However, recent languages that break it…

My point was that you don't need to erase types to get parametricity. It may be that my terminology is faulty, and that in fact what Rust is doing here does constitute "erasing" the types, in that case what describes the distinction between say a Rust function which is polymorphic over a function to be invoked, and a Rust function which merely takes a function pointer as a parameter and then invokes it ? I would say the latter is type erased.

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

#65

Post by maccard » Wed, Dec 31, 2025, 4:08 PM UTC

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

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

This is a problem with the signature of the function in the first place. If it's:

  template 
  T* FindObject(ListType items, std::function predicate)

Whether T is MyObject or MyObject?, you're still using nullpointers as a sentinel value;

  MyObject* Result = FindObject(items, predicate);

The solution is for FindObject to return a result type;

  template 
  Result FindObject(ListType items, std::function predicate)

where the _result_ is responsible for the return value wrapping. Making this not copy is a more advanced exercise that is bordering on impossible (safely) in C++, but Rust and newer languages have no excuse for it

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

#66

Post by maccard » Wed, Dec 31, 2025, 4:10 PM UTC

_flux wrote: post #39

lock1 wrote: post #25

Earlier quoted context omitted.

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.

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

this is how go handles it;

  func do_thing(val string) (string, error)

is expected to return `"", errors.New("invalid state")` which... sucks for performance and for actually coding.

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

#67

Post by ModernMech » Wed, Dec 31, 2025, 4:26 PM UTC

gethly wrote: post #49

_bohm wrote: post #29

Earlier quoted context omitted.

> the language that inspired conception of both of these I haven’t heard this before. Do you have a source on this?

I do not, but John's old videos on the idea of making a language and addressing the modern problems of archaic languages has been cited many times. Here is a list with his videos where he goes from conception to something tangible: https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxai... The first video is from September 17, 2014. Zig's first commit was Aug 5, 2015. Odin has first commit in Jul 7, 2016.

tbf there was a general systems language renaissance circa 2015, following Mozilla sponsoring Rust in 2009 and its impending 1.0 in 2015. Jai, Zig, and Odin were all contemporaries in that wave.

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

#68

Post by tialaramex » Wed, Dec 31, 2025, 4:41 PM UTC

jchw wrote: post #60

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…

I wonder if some day we'll look back differently on the "billion-dollar mistake" thing. The key problem with null references is that it forces you to either check any given reference to see if it's null if you don't already know, or you would have to have a contract that it can't be null. Not having null references really does solve that problem, but still in every day programs you often wind up with situations where…

I think Hoare is bang on because we know the only similar values in many languages are also problematic even though they're not related to memory.

The NaNs are, as their name indicates, not numbers. So the fact this 32-bit floating point value parameter might be NaN, which isn't even a number, is as unhelpful as finding that the Goose you were passed as a parameter is null (ie not actually a Goose at all)

There's a good chance you've run into at least one bug where oops, that's NaN and now the NaN has spread and everything is ruined.

The IEEE NaNs are baked into the hardware everybody uses, so we'll find it harder to break away from this situation than for the Billion Dollar Mistake, but it's clearly not a coincidence that this type problem occurs for other types, so I'd say Hoare was right on the money and that we're finally moving in the correct direction.

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

#69

Post by tialaramex » Wed, Dec 31, 2025, 5:23 PM UTC

gethly wrote: post #56

ecshafer wrote: post #52

Earlier quoted context omitted.

I am using Odin to write a video game.... why would I want tn HTTPS stack, SQL Drivers, Websockets or any of that? Maybe eventually I might need some websockets if I want multiplayer. But I can also just make bindings to a C library so no real issue there. Odin is explicitly made for video games.

> Odin is explicitly made for video games. Ginger Bill vehemently refuses this notion and tries to fight in every podcast, to "sell" Odin as general purpose low level language. But he is failing because of my points and your claim just proves it yet again that Odin has profiled itself as language for games when in reality that was never the intention of Bill. There is nothing wrong with that, it's just the perception…

It's also in the Handmade crowd, and for a lot of people that's intimately connected to video games. I actually think Handmade's approach is helpful for games in a way it isn't for a lot of other software.

Games are art. The key thing is that you have to actually make it. Handmade encourages people who might make some art to actually make something rather than being daunted by the skill needed for a very sophisticated technology. Handmade is like telling a would-be photographer "You already have a camera on your phone. Point it at things and take pictures of them" rather than "Choose your subject, then you will need to purchase either an SLR or maybe a larger camera, and suitable lenses and a subscription for Photoshop and then take a college course in photo composition"

I don't want to use a text editor made by someone who has no idea what they're doing and learned about rope types last week. A dozen handmade text editors, most not as good as pico, are of no value to anybody.

But I do want to play video games by people who have no idea what they're doing. That's what Blue Prince is, for example. A dozen handmade video games means a dozen chances for an entirely unprecedented new game. It'll be rough around the edges, but novelty is worth a lot.

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

#70

Post by tialaramex » Wed, Dec 31, 2025, 5:43 PM UTC

ycombinatrix wrote: post #15

MangoToupe wrote: post #2

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?

How do you allocate memory without an allocator?

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.