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

31–40 of 163 posts

Re: Understanding the Odin programming language

#31

Post by andyfilms1 »

clumsysmurf wrote: post #23
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.

You can look at my repo here: https://github.com/MadlyFX/odin-embedded-boilerplate

I don't believe Xtensa (ESP32) is supported yet, but people have been asking for it, so it may happen at some point. ARM is well supported now though, obviously.

Re: Understanding the Odin programming language

#32

Post by christophilus »

andrepd wrote: post #25
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…

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

I can see why you would think that about Jon Blow, though I disagree. But Casey? He has a number of thorough videos with plenty of evidence, and has never struck me as arrogant.

Re: Understanding the Odin programming language

#33

Post by christophilus »

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 be interested in reading about your experience building web applications with it. Last I looked, its stdlib didn’t have great support for that.

Re: Understanding the Odin programming language

#34

Post by andyfilms1 »

RetroTechie wrote: post #28
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 met…

Odin is not like JS or something where you'd need a VM or transpilation process to target an embedded system. It's just C with nicer syntax and modern data structures, there's no "squeezing" required. You just compile for the target you want to run on.

Here's a UI framework, if you scroll down you'll see it on a Raspi Pico: https://github.com/MadlyFX/Ansuz

Re: Understanding the Odin programming language

#35

Post by christophilus »

pclowes wrote: post #10
yesfinally wrote: post #7

[flagged]

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…

I find they’re pretty good with Odin. Not as good as with Go, and nowhere near as good as Typescript, but definitely good enough.

Re: Understanding the Odin programming language

#36

Post by wasmperson »

kibwen wrote: post #27
pseudony wrote: post #17

Earlier quoted context omitted.

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

Agreed. IME the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage.

The perf argument against RAII is very abstract and is less "RAII causes bad performance" and more "the kind of design that leads you to reach for RAII is the kind of design that's bad for performance." There exist similar hand-wavy arguments against many other C++/Rust features.

More generally, "you shouldn't even want that" is basically a meme at this point in programming language design. Every new-ish language has some version of it.

Re: Understanding the Odin programming language

#37

Post by CyberDildonics »

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…

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.

This isn't true and doesn't make any sense. Smart pointers don't need to enter into it. If you need a lot of something you make a vector and allocate once.

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.

It is an extremely niche scenario to need a program to shut down so much faster that you can't even deallocate memory. If you don't make lots of small allocations in the first place the deallocations won't take any time.

Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.

It's actually a pretty big advantage to destructors to deal with stuff like this as well as memory and locks.

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

I think it gets polarizing because they are both undeniably sharp programmers but don't have any real evidence of this stuff, they are just grasping at rationalizations.

Re: Understanding the Odin programming language

#38

Post by cmrdporcupine »

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…

Rust barely even trying on the pluggable allocators (seems like it's never going to land, afaik "allocator-api" has been sitting proposed in nightly only since 2018) is one of the things that frustrates me (fulltime Rust eng) about the language and makes me feel like it's just a language that's been eaten by web services developers, applications level work, and/or tokio, and isn't "serious" as a systems PL really despite the verbiage.

Building a database, operating system, etc. absolutely requires fine tuned control over allocation. You can get around some of these things in Rust, but it will fight you. You'll effectively have to turn your back on the containers in std and build your own vectors, maybe even your own Box, etc.

Odin looks really appealing to me at one level, but I'd have a hard time switching to any language at this point that doesn't have a borrow checker story.

Re: Understanding the Odin programming language

#40

Post by sarchertech »

pdpi wrote: post #20
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…

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.

Casey worked on tooling for AAA games that most certainly needed “that level” of optimization.

Jon Blow worked on numerous AAA games that required “that level” of optimization. And he’s one of the very few developers in the last 15 years who have managed to sell more than a million copies of a game running on a scratch built 3D engine.

You can disagree with their opinions, but they certainly have the experience to back those opinions up.

Post reply on HN