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

Understanding the Odin programming language

odinbook.com

Post reply on HN
Print view View original

21–30 of 163 posts

Re: Understanding the Odin programming language

#21

Post by scott01 »

dustbunny wrote: post #9
CyberDildonics wrote: post #5

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

From what I understood, their critique of RAII is twofold: coupling of allocation and initialisation, and enforcement of deallocation. The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts. Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back. Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.

As on some references, Ryan Fleury did an episode on Wookash podcast on RAD debugger showing ECS like approach.

IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.

Edit: the sibling comment just proved my last point.

Re: Understanding the Odin programming language

#22

Post by kode-targz »

yesfinally wrote: post #7

[flagged]

Data-oriented is a programming paradigm, just like object-oriented and procedural and functional. It has nothing to do with Big Data. It's about the way things are done. It prefers something like an ECS (data-oriented) rather than a class hierarchy (object-oriented). "Graphics oriented" isn't a thing.

Also, i disagree with your point about "promoting what you can do with it, rather than the language itself and its quirks". Like, what? Every language can do everything another language can. As long as it's turing-complete and has some interface for FFI or something similar, it can do anything. You can make a full modern SaaS in C if you really wanted to, from backend to frontend. The language itself and its quirks are what would make you maybe consider not doing that (as much as I love C, that would just be stupid if your goal is anything other than fun and experimentation).

I can see all the great software and games that were made with C++. Doesn't make me wanna use it though, the language sucks.

Your paragraph about IDE and the whole name thing just seems very out of touch to me. Are you a marketing / HR / sales person perchance?

Re: Understanding the Odin programming language

#23

Post by clumsysmurf »

andyfilms1 wrote: post #6

I'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 like to hear more about Odin + STM32 MCU firmware, do you have any good resources? I'm also curious how difficult it may be to using it with ESP32 (ESP-IDF) / RP2350.

Re: Understanding the Odin programming language

#24

Post by pclowes »

mpweiher wrote: post #19
pclowes wrote: post #10

Earlier quoted context omitted.

Interesting, I am thinking/expecting we will see a massive decrease in new languages. Or people might make new languages but the will not get any adoption. A new language now has to clear the ever growing hurdle of not being in the LLM training data. Unless the language provides an absolutely incredible technical or runtime advantage over every other language that LLMs “speak” well I think it will really struggle to…

> A new language now has to clear the ever growing hurdle of not being in the LLM training data. I found this to be far less of a prblen than I thought it would be. Do you have practical experience?

Not with a new language but novel approaches within a framework or paradigm feel outside the LLM wheelhouse.

Even if the LLM is adept at novel languages the developer still has to learn it and learning new languages now when most programming is done via a prompt-review loop feels like it has lower ROI.

Re: Understanding the Odin programming language

#25

Post by andrepd »

dustbunny wrote: post #9
CyberDildonics wrote: post #5

Earlier 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 Muratori and Jon Blow have pushed this concept frequently

Ah... The school of what I like to call "maximum opinions and minimal evidence". Aggressive arrogant dismissal of anything except their exact view (and for Muratori, you're also "woke" for good measure), coupled with a complete lack of _hard evidence_ to back up their views. In that regard, they're not unlike "investment advice" instagram influencers.

Re: Understanding the Odin programming language

#26

Post by CyberDildonics »

dustbunny wrote: post #9
CyberDildonics wrote: post #5

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

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 create a global data structure just as easily in C++.

Re: Understanding the Odin programming language

#27

Post by kibwen »

pseudony wrote: post #17
CyberDildonics wrote: post #5

Earlier 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?

Games ? Many have talked about it, but many also make their games work inside of Unity and so on, so, depends on the project. My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to. Eg, ask for lots of memory, manage with arenas. Interestingly Odin and Zig both lean into this heavily. Ru…

> My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to. Eg, ask for lots of memory, manage with arenas.

This gives the misleading impression that ordinary memory allocators are materially different from arena allocators. They aren't. Both types of allocators first ask for a big block of memory from the kernel, then dole that memory out in userspace. There's no need to cross the userspace/kernel boundary more often than you need to, especially when you consider that you can replace the standard platform allocator with whatever you want.

To wit, C doesn't emphasize arena allocation anywhere near as much as Zig et al do, and yet nobody alleges that C is somehow less suitable for systems programming than these languages. Have you considered why that is? Because, for the most part, arena allocation doesn't make a significant difference, and in the places where it actually does make a difference, you can trivially build an arena allocator on top of the standard allocator.

Re: Understanding the Odin programming language

#28

Post by RetroTechie »

andyfilms1 wrote: post #6

I'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…

Out of curiosity:

In your opinion, could a minimal system to develop in Odin be squeezed into a device like the one(s) you targeted?

That's assuming maybe some tweaks to the toolset, doing without some niceties, but not cutting core features out of the language.

Asking 'cause I have a passing interest in programming languages that allow for native development on really small implementations (think sub-1MB on bare metal). The list of candidates doesn't seem long.

Re: Understanding the Odin programming language

#29

Post by andrepd »

CyberDildonics wrote: post #26
dustbunny wrote: post #9

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

Exactly! The most interesting arguments for Rust that I've ever read have come not from people who hate C++, but precisely from people who are really into C++, because those are the people who actually recognise its shortcomings are are better positioned to give INSIGHTFUL criticism into it.

People who are motivated by a superiority complex or by the wish to impress a herd of twitter followers hardly if ever produce a thought I want to read.

Re: Understanding the Odin programming language

#30

Post by tancop »

scott01 wrote: post #21
dustbunny wrote: post #9

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

From what I understood, their critique of RAII is twofold: coupling of allocation and initialisation, and enforcement of deallocation. The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts. Also I remember they mentioned it’s not necessary to free memory if you’re ab…

most of that criticism only works on C++. rust does enforce RAII but uses stack allocation for locals by default instead of touching the heap so it skips the slow part.

on the other hand there are no constructors (just normal functions) so you cant initialize values in place, only stack allocate and return. i think rust needs to add in place init and change the rules from "always init at declaration site" to "must be initialized at first use" like kotlin.

the big missing piece is custom allocators that let you use something like a bump arena with the same convenience as system malloc. they already exist on nightly but nobody knows when they will land on stable.

honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked. they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.

there should be a stage between nightly and full release where feature is in stable toolchains behind a cfg flag and you get a warning if upstream crates use it. show commitment to shipping it in time but still make it clear that it can change (in minor incompatible ways) before release.

Post reply on HN