[dead]
Understanding the Odin programming language
41–50 of 163 posts
Re: Understanding the Odin programming language
#42Earlier quoted context omitted.
That is, imho, where Rust fails the most - the second part is the C++’ish approach to memory management (RAII) - that’s not how systems programming or games (I’m told) tend to work. What does this mean? Who told you that?
Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…
Casey spends a lot of effort on what he considers an anti-pattern where you're making a huge number of separate objects. I think a lot of this comes from Java, a language where all the user defined types actually are obliged to be heap allocations. If I make a Goose type, and I say I want a Goose, Java will allocate space on the heap for the Goose and put my Goose there, that's really how Java works. If I make a growable array of them ArrayList, and add each of 500 geese, that's 500 allocations for geese plus maybe 8 allocations for the ArrayList, so 508 total. Ouch. If making a Goose was itself cheap this overhead hurts badly.
But a lot of languages aren't like that, and so this doesn't translate. Obviously in Rust with Vec that's only 8 allocations, each local Goose lives in the stack - or, if you knew up front there were 500 geese, you Vec::with_capacity(500) and it's a single allocation - but similar is true in many languages, Java is an outlier.
Re: Understanding the Odin programming language
#43Earlier quoted context omitted.
Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…
Casey Muratori and Jon Blow are both hyper-dogmatic "my way or the highway" types, and, crucially, neither of them has built any of the super high fidelity types of game that would require that level of optimisation. They're basically influencer types.
Dunno, the Witness had gorgeous lighting. Both have consulted for AAA too.
Re: Understanding the Odin programming language
#44Earlier quoted context omitted.
Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…
I think those guys both hate C++ so much that they want to dismiss everything about it instead of using all the features that work for them like most people. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. They might say this, but there isn't a good technical rationalization here since anyone can cr…
Hate C++? They both use(d) it...
Re: Understanding the Odin programming language
#45Re: Understanding the Odin programming language
#46Earlier quoted context omitted.
Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…
Casey spends a lot of effort on what he considers an anti-pattern where you're making a huge number of separate objects. I think a lot of this comes from Java, a language where all the user defined types actually are obliged to be heap allocations. If I make a Goose type, and I say I want a Goose, Java will allocate space on the heap for the Goose and put my Goose there, that's really how Java works. If I make a grow…
Maybe I'm missing something but when would the 500 geese instances ever be stack allocated in Rust? That comparison seems unfair, the lifetime of that kind of object isn't going to be compatible with stack allocation.
Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
Re: Understanding the Odin programming language
#47Having fun with this. Never bought into rust (have studied, have a (mostly AI-generated app in rust). Wrote some Zig but Odin is even less overhead for me. I first loved Zigs built-in build system but having tried to wrap/use C libraries from both, I must say I prefer Odin. Wrapping some sqlite 3 API’s for my first little Odin program - just because I need so little of the API that it seems easier this way - and spea…
Did you try Swift? Its interoperability with C (and even C++) is great IMHO.
It's GC
Re: Understanding the Odin programming language
#48I wonder if this will help them get a wikipedia page. (not sure whether this comment is a joke or serious...)
Re: Understanding the Odin programming language
#49I've been using Odin for about 6 months now, and to be honest, it's hard to find fault with it. I've used it for STM32 microcontroller firmware, web and desktop applications, and all are performant and compile quickly. My one issue is (and I'm fully aware it will never happen) I do wish there was some sort of first-class solution to inheritance. I've grown to love procedural programming, but some problems really are…
I’d be interested in reading about your experience building web applications with it. Last I looked, its stdlib didn’t have great support for that.
There’s an official http package coming out and native tls support as well.
Re: Understanding the Odin programming language
#50Earlier quoted context omitted.
Casey spends a lot of effort on what he considers an anti-pattern where you're making a huge number of separate objects. I think a lot of this comes from Java, a language where all the user defined types actually are obliged to be heap allocations. If I make a Goose type, and I say I want a Goose, Java will allocate space on the heap for the Goose and put my Goose there, that's really how Java works. If I make a grow…
Maybe I'm missing something but when would the 500 geese instances ever be stack allocated in Rust? That comparison seems unfair, the lifetime of that kind of object isn't going to be compatible with stack allocation. Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
When you make a local variable with a Goose in Java, that's a heap allocation
Goose jim = make_a_goose_somehow(); // Java, so jim is on the Heap, no way around it
let jim : Goose = make_a_goose_somehow(); // Rust, jim is on the stack
ArrayList geese = new ArrayList();
// ... some loop eventually
Goose a_goose = somehow_get_this_goose(); // That's an allocation
geese.add(a_goose);
let geese: Vec = Vec::new();
// ... some loop eventually
let a_goose : Goose = somehow_get_this_goose(); // But this is not
geese.push(a_goose);