11 ms·

Understanding the Odin programming language

164 points by AlexeyBrin 2mo ago

jdw64 2mo ago
[dead]
pseudony 2mo ago
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 :)
- CyberDildonics 2mo ago
  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?
  - dustbunny 2mo ago
    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.
    - pdpi 2mo ago
      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.
      - sarchertech 2mo ago
        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.
        gf000 2mo ago
        Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.
        sarchertech 2mo ago
        Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL. Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier--before Unity and Unreal had completely taken over. I'm also not saying that the witness engine is somehow better than anything else out there, but it's a significant enough technical accomplishment that along with Jon Blow's other work, he has the experience to back up his opinions. I've also never seen the critique that Jon Blow is just an influencer with no relevant experience from anyone with equivalent relevant experience. I've seen other experienced game devs who disagree with him, but I've never seen them say that he doesn't have the experience to have them.
  - moron4hire 2mo ago
    Yeah, that's weird. I first learned about RAII from professional game developers at gamedev.net.
  - pseudony 2mo ago
    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.
    - kibwen 2mo ago
      > 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.
      - wasmperson 2mo ago
        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.
- frizlab 2mo ago
  Did you try Swift? Its interoperability with C (and even C++) is great IMHO.
  - hollowturtle 2mo ago
    It's GC
    - leecommamichael 2mo ago
      Pedantically I’ll say it’s reference counted, and someone else will say that’s still a form of GC and I’ll just save us the mini-thread. Reference counting has deterministic timing, you can run a deconstructor without registering objects for deletion and running any known finalizers (what you need to do in all GC langs I’m aware of.)
      - frizlab 2mo ago
        Yes, but only classes are GC (refcounted as parent comment says, indeed). structs and other elements are not. You can even use the same ownership model as rust (borrowing et al.) with non copyable types.
      - Someone 2mo ago
        > Reference counting has deterministic timing Define “deterministic timing”. - One object going out of scope may mean calling free once, but it also can trigger calling free billions of objects, even for the exact same object - Even freeing one object can have largely varying running time, e.g. to coalesce free blocks or, because it happens to be the last block in a virtual memory region, to unmap a block of virtual memory, blocking the program potentially for an arbitrary time - With garbage collection (as with reference counting), lots of the overhead of objects going out of scope can be moved onto a specialized thread. > you can run a deconstructor without registering objects Not requiring finalizes does make reference counting easier, yes. The downside is have to store the reference counts somewhere, and keep them up to date (enough)
        2mo ago
- hkalbasi 2mo ago
  If the major obstacle for adopting Rust is C interop, you may find my project CO2[1] appealing. It helps you to define C crates, `#include` C headers, while exporting a Rust API with Rust types in your crate boundary. [1]: https://github.com/hkalbasi/co2 https://github.com/hkalbasi/co2
Razengan 2mo ago
This was a pretty funny video for a language launch: https://www.youtube.com/watch?v=dLPAqXi9In0 https://www.youtube.com/watch?v=dLPAqXi9In0
andyfilms1 2mo ago
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.
- clumsysmurf 2mo ago
  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.
  - andyfilms1 2mo ago
    You can look at my repo here: https://github.com/MadlyFX/odin-embedded-boilerplate 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.
- RetroTechie 2mo ago
  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.
  - andyfilms1 2mo ago
    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 https://github.com/MadlyFX/Ansuz
yesfinally 2mo ago
[flagged]
- pclowes 2mo ago
  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.
  - mpweiher 2mo ago
    > 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?
    - pclowes 2mo ago
      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.
  - christophilus 2mo ago
    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.
- kode-targz 2mo ago
  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?
datakan 2mo ago
I wonder when we'll see new languages created specifically with LLM's in mind.
- xqb64 2mo ago
  What would that look like?
  - datakan 2mo ago
    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.
    - deleted 2mo ago
      [deleted]
    - SoftTalker 2mo ago
      So, assembly?
      - goosejuice 2mo ago
        That would be less efficient
        pjmlp 2mo ago
        There are already plenty of PLDI and SIGPLAN talks on LLM => Assembly, with some guardrails for determinism, instead of having a "classical" language as translation layer.
        goosejuice 2mo ago
        Sorry are we referring to the efficiency of generating programs (i.e. optimizing LLM software development) or the efficiency of the output (i.e. optimizing software through the generation of assembly)?
functional_dev 2mo ago
[dead]
gcanyon 2mo ago
I wonder if this will help them get a wikipedia page. (not sure whether this comment is a joke or serious...)
- leecommamichael 2mo ago
  It would, but the book has existed for a while now, which is a good thing for anyone looking to learn Odin. The author, Karl, has had time to polish and update the text. He has his own Discord and is also available in the Odin Discord and makes helpful posts there as well.
ant6n 2mo ago
Kinda wanna know why I should learn this language. Unfortunately there’s no wiki entry (deleted with some controversy abut notability), so it’s hard to get the gist of it.
- kulkalkul 2mo ago
  Odin overview is great resource for getting a quick gist (and learning the language as a bonus): https://odin-lang.org/docs/overview/ https://odin-lang.org/docs/overview/ But mainly, language doesn't have a special gimmick. The main idea (imo) is it is opinionated to have defaults to cater for majority of the cases. So once you get used to it, it is pleasure to write C-like code in it.
WalterBright 2mo ago
Oooodiiinn! https://youtu.be/ZqJHqXERslM?t=59 https://youtu.be/ZqJHqXERslM?t=59
phplovesong 2mo ago
Promoting here on HN is not usually allowed. This is a paid tutorial for some obscure programming language.
- AlexeyBrin 2mo ago
  I have no connection with the book author. Also, people post all the time links to paid sources on HN (like books, software or pay for services).

164 points by AlexeyBrin 2mo ago

jdw64 2mo ago

[dead]

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 :)

CyberDildonics 2mo ago
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?
- dustbunny 2mo ago
  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.
  - pdpi 2mo ago
    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.
    - sarchertech 2mo ago
      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.
      - gf000 2mo ago
        Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.
        sarchertech 2mo ago
        Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL. Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier--before Unity and Unreal had completely taken over. I'm also not saying that the witness engine is somehow better than anything else out there, but it's a significant enough technical accomplishment that along with Jon Blow's other work, he has the experience to back up his opinions. I've also never seen the critique that Jon Blow is just an influencer with no relevant experience from anyone with equivalent relevant experience. I've seen other experienced game devs who disagree with him, but I've never seen them say that he doesn't have the experience to have them.
- moron4hire 2mo ago
  Yeah, that's weird. I first learned about RAII from professional game developers at gamedev.net.
- pseudony 2mo ago
  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.
  - kibwen 2mo ago
    > 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.
    - wasmperson 2mo ago
      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.
frizlab 2mo ago
Did you try Swift? Its interoperability with C (and even C++) is great IMHO.
- hollowturtle 2mo ago
  It's GC
  - leecommamichael 2mo ago
    Pedantically I’ll say it’s reference counted, and someone else will say that’s still a form of GC and I’ll just save us the mini-thread. Reference counting has deterministic timing, you can run a deconstructor without registering objects for deletion and running any known finalizers (what you need to do in all GC langs I’m aware of.)
    - frizlab 2mo ago
      Yes, but only classes are GC (refcounted as parent comment says, indeed). structs and other elements are not. You can even use the same ownership model as rust (borrowing et al.) with non copyable types.
    - Someone 2mo ago
      > Reference counting has deterministic timing Define “deterministic timing”. - One object going out of scope may mean calling free once, but it also can trigger calling free billions of objects, even for the exact same object - Even freeing one object can have largely varying running time, e.g. to coalesce free blocks or, because it happens to be the last block in a virtual memory region, to unmap a block of virtual memory, blocking the program potentially for an arbitrary time - With garbage collection (as with reference counting), lots of the overhead of objects going out of scope can be moved onto a specialized thread. > you can run a deconstructor without registering objects Not requiring finalizes does make reference counting easier, yes. The downside is have to store the reference counts somewhere, and keep them up to date (enough)
      - 2mo ago
hkalbasi 2mo ago
If the major obstacle for adopting Rust is C interop, you may find my project CO2[1] appealing. It helps you to define C crates, `#include` C headers, while exporting a Rust API with Rust types in your crate boundary. [1]: https://github.com/hkalbasi/co2 https://github.com/hkalbasi/co2

Razengan 2mo ago

This was a pretty funny video for a language launch: https://www.youtube.com/watch?v=dLPAqXi9In0 https://www.youtube.com/watch?v=dLPAqXi9In0

andyfilms1 2mo ago

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.

clumsysmurf 2mo ago
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.
- andyfilms1 2mo ago
  You can look at my repo here: https://github.com/MadlyFX/odin-embedded-boilerplate 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.
RetroTechie 2mo ago
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.
- andyfilms1 2mo ago
  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 https://github.com/MadlyFX/Ansuz

yesfinally 2mo ago

[flagged]

pclowes 2mo ago
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.
- mpweiher 2mo ago
  > 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?
  - pclowes 2mo ago
    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.
- christophilus 2mo ago
  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.
kode-targz 2mo ago
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?

datakan 2mo ago

I wonder when we'll see new languages created specifically with LLM's in mind.

xqb64 2mo ago
What would that look like?
- datakan 2mo ago
  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.
  - deleted 2mo ago
    [deleted]
  - SoftTalker 2mo ago
    So, assembly?
    - goosejuice 2mo ago
      That would be less efficient
      - pjmlp 2mo ago
        There are already plenty of PLDI and SIGPLAN talks on LLM => Assembly, with some guardrails for determinism, instead of having a "classical" language as translation layer.
        goosejuice 2mo ago
        Sorry are we referring to the efficiency of generating programs (i.e. optimizing LLM software development) or the efficiency of the output (i.e. optimizing software through the generation of assembly)?

functional_dev 2mo ago

[dead]

gcanyon 2mo ago

I wonder if this will help them get a wikipedia page. (not sure whether this comment is a joke or serious...)

leecommamichael 2mo ago
It would, but the book has existed for a while now, which is a good thing for anyone looking to learn Odin. The author, Karl, has had time to polish and update the text. He has his own Discord and is also available in the Odin Discord and makes helpful posts there as well.

ant6n 2mo ago

Kinda wanna know why I should learn this language. Unfortunately there’s no wiki entry (deleted with some controversy abut notability), so it’s hard to get the gist of it.

kulkalkul 2mo ago
Odin overview is great resource for getting a quick gist (and learning the language as a bonus): https://odin-lang.org/docs/overview/ https://odin-lang.org/docs/overview/ But mainly, language doesn't have a special gimmick. The main idea (imo) is it is opinionated to have defaults to cater for majority of the cases. So once you get used to it, it is pleasure to write C-like code in it.

WalterBright 2mo ago

Oooodiiinn! https://youtu.be/ZqJHqXERslM?t=59 https://youtu.be/ZqJHqXERslM?t=59

phplovesong 2mo ago

Promoting here on HN is not usually allowed. This is a paid tutorial for some obscure programming language.

AlexeyBrin 2mo ago
I have no connection with the book author. Also, people post all the time links to paid sources on HN (like books, software or pay for services).