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 speaking to C from Odin is a pleasure.
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.
To each their own. I had some fun with Rust too, but for me, Odin seems the most appealing :)
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.
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 experience, RAII is my preferred pattern for certain things (std::lock_guard), and you can almost certainly express the majority of these "uber game dev patterns" using RAII/smart pointers/etc, but the c++ implementation of these "uber game dev patterns" tends to be more complicated (and imo esthetically ugly) compared to really well written C.
These new languages (zig, odin, jai) appear to be attempts to improve C to allow an alternative to C++ that doesn't have the ugly baggage that C++ has.
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<Goose>, 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<Goose> 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.
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.
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.
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.
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.
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.
> 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.
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++.
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.
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. Rust went a different route but has tried later to bolt on pluggable allocators.
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.
> 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.
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.
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 just better solved with a more OOP approach. Just because classes exist does not mean they need to be used.
But as far as a language to "get stuff done" with as few tradeoffs as possible, Odin is about as good as I can imagine a language being.
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.
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.
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.
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.
Like Go and Rust, the coolest thing (and maybe only cool thing) about this language is the name.
Now that LLMs are out of the bag, I expect to see a lot of new programming languages. In such an environment, one is better off promoting what you can do with it, rather than the language itself and its quirks.
Show me what you made with this language - it will help me better understand the use case(s) and trade-offs.
I say it because I see Odin following Rust in that it is relying a lot on its name in marketing. And on these microscopic language quirks that people don't really care about en masse, things people easily work around in other languages.
Doesn't seem very useful (sales-wise) to spend so much time talking about garbage collection or whether or not a language has native tuple support - and also the branding just doesn't matter that much. Go does a better job of this (what is Go's logo? Idk either. I know Swift's though. Go is 4x more popular - both "released" around the same time by similar companies).
JavaScript has the worst name of all time yet it's the most popular language because of how heavily relied upon it is by all kinds of consumer technology.
Python also - not a great name really, still wildly popular because of its use cases (and having a high quality library ecosystem).
Turbopack was a great example of when, why, where, to use a new, novel language (Rust) in an area I'd never consider it (web dev). It also opens my mind up to Rust doing other things like that in the ecosystem where I'd never consider it before. Now I kinda know what Rust is for.
It opens up questions like "is it designed only for graphics and GUIs or is it more backend in general, is it low level systems or network" etc. then after that I'd ask whether or not it's strongly typed, compiled, and get into all those language quirks (which don't matter that much).
After seeing the game demo, I read that it wraps basically every major GL - more questions related to graphics programming but then the site keeps saying:
"The Data Oriented Language"
...on every page.
Up until now I had began to think it was a graphics oriented language, with all the GPU talk and game dev demos. But now it's a data language? And what does that even mean?
Then there's a book for sale that I keep running into. This isn't helping!
I love the name "Odin", and I like the idea of a new graphics-oriented programming language that somehow does something useful. Push me over the edge! Help me fall for this thing, it's so much like Rust in this way - seems amazing! But why? Why do I want this?
If it were me: I'd narrowly focus on 1 thing at first, something controversial and powerful - private MMO servers with good server-side physics and anti-cheat, or torrents, or running local AI models.
Build a beautiful IDE designed around your language ecosystem (that works for other languages too) and give it away for free. Optionally include a 7b LLM in the IDE to autocomplete Odin syntax to teach people the language. Get private servers for games like WoW and FF14 (illegal in most countries) online and teach people how to deploy their own. Tout the fact that no backend language in all of gaming can simulate physics to such a degree (fluid dynamics, etc.) and that no front-end language in gaming wraps all major GL providers so seamlessly in a single, easy-to-learn syntax.
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?
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 gain adoption.
Additionally, a language’s qualitative benefits to human writers arguably matters less and less.
I used to live in my IDE. Now I use it maybe an hour each day even in a JVM based language. IDEs dont really matter as much anymore.
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.
I think it would be better to approach it from the other side, the priority is not to design a language for LLMs but a language more suitable for humans to think with. And not a natural language like English, which is inconsistent and allows illogical formulations, but something like Esperanto or Interlingua (Latino sine flexione). Something that is based on mathematics and logic at the bottom, like Lean, with enough abstraction layers for a person to be able to "speak" with the machine intuitively.
I don't know but I would imagine there are a lot of inefficiencies in modern languages from an LLM perspective that it could strip out, reduce token costs, improve speed etc.
An LLM-only oriented language doesn't make sense, because without human generated training data there is nothing for the model to learn from.
But if a human-oriented language were to be designed to also be better for LLMs, I think it would involve deeply expressive syntax that can succinctly but distinctly represent a very broad set of common operations. Succinct so context can be managed well, distinct so completions don't confuse one thing for another, broad so as much "reasoning" can be taken away from the LLM as possible. An anti-C. A new take on the goals of Java and Go to be languages that protect the application from the Junior Developers You're Likely To Hire.
I somewhat think it would also involve application state images ala Smalltalk. LLMs seem okay at generating small deltas. Many deltas sequenced together invites compounding error. LLM generated apps are unlikely to lead to common libraries being compentized and extracted out of the application to share with other applications; it seems like LLM code generation is already a "married to a specific project" act already. So, having a living state image might reveal some benefits by leaning into incrementally developing the application in situ, as a whole.
Having 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 speaking to C from Odin is a pleasure.
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.
To each their own. I had some fun with Rust too, but for me, Odin seems the most appealing :)
Did you try Swift? Its interoperability with C (and even C++) is great IMHO.
It's GC
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 experience, RAII is my preferred pattern for certain things (std::lock_guard), and you can almost certainly express the majority of these "uber game dev patterns" using RAII/smart pointers/etc, but the c++ implementation of these "uber game dev patterns" tends to be more complicated (and imo esthetically ugly) compared to really well written C.
These new languages (zig, odin, jai) appear to be attempts to improve C to allow an alternative to C++ that doesn't have the ugly baggage that C++ has.
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<Goose>, 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<Goose> 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.
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.
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.
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.
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.
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.
Dunno, the Witness had gorgeous lighting. Both have consulted for AAA too.
> 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.
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++.
Hate C++? They both use(d) it...
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.
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. Rust went a different route but has tried later to bolt on pluggable allocators.
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.
> 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.
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.
Yeah, that's weird. I first learned about RAII from professional game developers at gamedev.net.
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 just better solved with a more OOP approach. Just because classes exist does not mean they need to be used.
But as far as a language to "get stuff done" with as few tradeoffs as possible, Odin is about as good as I can imagine a language being.
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.
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
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.
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.
This was a pretty funny video for a language launch:
https://www.youtube.com/watch?v=dLPAqXi9In0
Like Go and Rust, the coolest thing (and maybe only cool thing) about this language is the name.
Now that LLMs are out of the bag, I expect to see a lot of new programming languages. In such an environment, one is better off promoting what you can do with it, rather than the language itself and its quirks.
Show me what you made with this language - it will help me better understand the use case(s) and trade-offs.
I say it because I see Odin following Rust in that it is relying a lot on its name in marketing. And on these microscopic language quirks that people don't really care about en masse, things people easily work around in other languages.
Doesn't seem very useful (sales-wise) to spend so much time talking about garbage collection or whether or not a language has native tuple support - and also the branding just doesn't matter that much. Go does a better job of this (what is Go's logo? Idk either. I know Swift's though. Go is 4x more popular - both "released" around the same time by similar companies).
JavaScript has the worst name of all time yet it's the most popular language because of how heavily relied upon it is by all kinds of consumer technology.
Python also - not a great name really, still wildly popular because of its use cases (and having a high quality library ecosystem).
Turbopack was a great example of when, why, where, to use a new, novel language (Rust) in an area I'd never consider it (web dev). It also opens my mind up to Rust doing other things like that in the ecosystem where I'd never consider it before. Now I kinda know what Rust is for.
This is maybe the best example I've found for Odin: https://odin-lang.org/showcase/solar_storm/
It opens up questions like "is it designed only for graphics and GUIs or is it more backend in general, is it low level systems or network" etc. then after that I'd ask whether or not it's strongly typed, compiled, and get into all those language quirks (which don't matter that much).
After seeing the game demo, I read that it wraps basically every major GL - more questions related to graphics programming but then the site keeps saying:
"The Data Oriented Language"
...on every page.
Up until now I had began to think it was a graphics oriented language, with all the GPU talk and game dev demos. But now it's a data language? And what does that even mean?
Then there's a book for sale that I keep running into. This isn't helping!
I love the name "Odin", and I like the idea of a new graphics-oriented programming language that somehow does something useful. Push me over the edge! Help me fall for this thing, it's so much like Rust in this way - seems amazing! But why? Why do I want this?
If it were me: I'd narrowly focus on 1 thing at first, something controversial and powerful - private MMO servers with good server-side physics and anti-cheat, or torrents, or running local AI models.
Build a beautiful IDE designed around your language ecosystem (that works for other languages too) and give it away for free. Optionally include a 7b LLM in the IDE to autocomplete Odin syntax to teach people the language. Get private servers for games like WoW and FF14 (illegal in most countries) online and teach people how to deploy their own. Tout the fact that no backend language in all of gaming can simulate physics to such a degree (fluid dynamics, etc.) and that no front-end language in gaming wraps all major GL providers so seamlessly in a single, easy-to-learn syntax.
Make the IDE icy af
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?
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 gain adoption.
Additionally, a language’s qualitative benefits to human writers arguably matters less and less.
I used to live in my IDE. Now I use it maybe an hour each day even in a JVM based language. IDEs dont really matter as much anymore.
> 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.
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.
This goes for most languages but also a lot of things in life: if you see something and don't know why you'd want it, it's not for you.
I wonder when we'll see new languages created specifically with LLM's in mind.
I think it would be better to approach it from the other side, the priority is not to design a language for LLMs but a language more suitable for humans to think with. And not a natural language like English, which is inconsistent and allows illogical formulations, but something like Esperanto or Interlingua (Latino sine flexione). Something that is based on mathematics and logic at the bottom, like Lean, with enough abstraction layers for a person to be able to "speak" with the machine intuitively.
What would that look like?
I don't know but I would imagine there are a lot of inefficiencies in modern languages from an LLM perspective that it could strip out, reduce token costs, improve speed etc.
So, assembly?
An LLM-only oriented language doesn't make sense, because without human generated training data there is nothing for the model to learn from.
But if a human-oriented language were to be designed to also be better for LLMs, I think it would involve deeply expressive syntax that can succinctly but distinctly represent a very broad set of common operations. Succinct so context can be managed well, distinct so completions don't confuse one thing for another, broad so as much "reasoning" can be taken away from the LLM as possible. An anti-C. A new take on the goals of Java and Go to be languages that protect the application from the Junior Developers You're Likely To Hire.
I somewhat think it would also involve application state images ala Smalltalk. LLMs seem okay at generating small deltas. Many deltas sequenced together invites compounding error. LLM generated apps are unlikely to lead to common libraries being compentized and extracted out of the application to share with other applications; it seems like LLM code generation is already a "married to a specific project" act already. So, having a living state image might reveal some benefits by leaning into incrementally developing the application in situ, as a whole.