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

71–80 of 102 posts

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

#71

Post by tialaramex »

MangoToupe wrote: post #63
miningape wrote: post #32

Earlier quoted context omitted.

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

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.

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

#72

Post by ycombinatrix »

tialaramex wrote: post #70
ycombinatrix wrote: post #15

Earlier quoted context omitted.

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.

That creates problems when you need to use multiple allocators. IMO allowing an allocator to be specified is a superior design.

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

#73

Post by brabel »

miningape wrote: post #42
apitman wrote: post #14

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.

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

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.

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

#74

Post by gingerBill »

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 think the notion that "null" is a billion dollar mistake is well overblown. NULL/nil is just one of many invalid memory addresses, and in practice most of invalid memory address are not NULL. This is related to the drunkard’s search principle (a drunk man looks for his lost keys at night under a lamppost because he can see in that area). I have found that null pointers are usually very easy to find and fix, especially since most platforms reserve the first page of (virtual) memory to check for these errors.

In theory, NULL is still a perfectly valid memory address it is just that we have decided on the convention that NULL is useful for marking a pointer as unset.

Many languages (including Odin) now have support for maybe/option types or nullable types (monads), however I am still not a huge fan of them in practice as I rarely require them in systems-level programming. I know very well this is a "controversial" opinion, but systems-level programming languages deal with memory all the time and can easily get into "unsafe" states on purpose. Restricting this can actually make things like custom allocators very difficult to implement, along with other things.

n.b. Odin's `Maybe(^T)` is identical to `Option` in Rust in terms of semantics and optimizations.

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

#75

Post by gingerBill »

ecshafer wrote: post #52
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 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.

Directly from the FAQ: https://odin-lang.org/docs/faq/#is-odin-just-a-language-for-...

> Is Odin “just” a language for game development? # > No. It is a common misconception that Odin is “just” for game development (“gamedev”) due to the numerous vendor packages that could be used in the aid of the development of a game. However, gamedev is pretty much the most wide domain possible where you will do virtually every area of programming possible. > > Odin is a general purpose language; is capable of being used in numerous different areas from application development, servers, graphics, games, kernels, CLI/TUIs, etc. > > There are many aspects of Odin which do make working with 2D and 3D related operations (which are common in gamedev) much nicer than other languages, especially Odin’s array programming, swizzling, #soa data types, quaternions and matrices, and so much more niceties which other languages do not offer out-of-the-box.

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

#76

Post by 01HNNWZ0MV43FF »

gingerBill wrote: post #74
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 think the notion that "null" is a billion dollar mistake is well overblown. NULL/nil is just one of many invalid memory addresses, and in practice most of invalid memory address are not NULL. This is related to the drunkard’s search principle (a drunk man looks for his lost keys at night under a lamppost because he can see in that area). I have found that null pointers are usually very easy to find and fix, especia…

It's just weird to defend getting less help from the compiler in a situation where that help is so easy to give.

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

#77

Post by Kapendev »

apitman wrote: post #14

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.

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

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

#78

Post by miningape »

MangoToupe wrote: post #63
miningape wrote: post #32

Earlier quoted context omitted.

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

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)

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

#79

Post by jchw »

tialaramex wrote: post #68
jchw wrote: post #60

Earlier quoted context omitted.

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

What I'm saying is, I disagree that "we know" these things. We know that there are bugs that can be statically prevented by having non-nullable types to enforce contracts, but that doesn't in itself make null the actual source of the problem.

A language with non-nullability-by-default in its reference types is no worse than a language with no null. I say this because, again, there will always be situations where you may or may not have a value. For example, grabbing the first item in a list; the list may be empty. Even if you "know" the list contains at least one item, the compiler does not. Even if you check the invariant to ensure that it is true, the case where it is false may be too broken to handle and thus crashing really is the only reasonable thing to do. By the time the type system has reached its limits, you're already boned, as it can't statically prevent the problem. It doesn't matter if this is a nullable reference or if its an Option type.

Because of that, we're not really comparing languages that have null vs languages that don't. We're comparing languages that have references that can be non-nullable (or functionally equivalent: references that can't be null, but optional wrapper types) versus languages that have references that are always nullable. "Always nullable" is so plainly obviously worse that it doesn't warrant any further justification, but the question isn't whether or not it's worse, it's how much worse.

Maybe not a billion dollars worse after all.

P.S.: NaN is very much the same. It's easy to assign blame to NaN, and NaN can indeed cause problems that wouldn't have existed without it. However, if we had signalling NaNs by default everywhere, I strongly suspect that we would still curse NaN, possibly even worse. The problem isn't really NaN. It's the thing that makes NaN necessary to begin with. I'm not defending null as in trying to suggest that it isn't involved in causing problems, instead I'm suggesting that the reasons why we still use null are the true root issue. You really do fix some problems by killing null, but the true root issue still exists even after.

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

#80

Post by remexre »

gingerBill wrote: post #74
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 think the notion that "null" is a billion dollar mistake is well overblown. NULL/nil is just one of many invalid memory addresses, and in practice most of invalid memory address are not NULL. This is related to the drunkard’s search principle (a drunk man looks for his lost keys at night under a lamppost because he can see in that area). I have found that null pointers are usually very easy to find and fix, especia…

> get into "unsafe" states on purpose

see, this seems like something that's nice to actually put into the types; a Ptr is a real pointer that all the normal optimizations can be done to, but cannot be null or otherwise invalid, and UnsafePtr makes the compiler keep its distance and allows whatever tricks you want.

Post reply on HN