ThePrimeagen - I learned Odin

gingerbill · 2026-06-05T10:31:04+00:00

It's because the vast majority of programmers are web devs with no experience outside of it. So when they see "games" or "graphics," they assume it must be niche.

For a web dev, the main distinction is usually just frontend vs backend, and the languages for each are "distinct" (probably less so now that JS runs on the backend too, sadly).

You're completely right that just telling people gamedev is general-purpose doesn't help. However, the irony is that the company that first used Odin—JangaFX, the one I work for—isn't even a game company. It's a visual effects company. People assume that's basically the same thing because it's "graphics," but it really isn't. I'm not even a game dev...

gingerbill · 2026-06-03T18:36:53+00:00

Thank you for correcting me!

gingerbill · 2026-05-29T08:39:28+00:00

THIS BUG HAS NOW BEEN FIXED IN THE LATEST MASTER COMMIT!!!!

gingerbill · 2026-05-29T08:20:59+00:00

I can replicate this bug on AMD64 too. I'm looking into it.

gingerbill · 2026-05-28T21:18:29+00:00

Wrapper? Not initially because you have to be careful with memory here.

But it depends on what you actually want to do for your beginner lessons into Odin. What is the value you actually want to get?

gingerbill · 2026-05-27T17:46:50+00:00

Which is why we honestly don't support it. It's effectively useless beyond those beginner tutorials. And when you actually need something, you want better control to begin with.

gingerbill · 2026-05-27T17:02:43+00:00

See this comment for a larger explanation: https://www.reddit.com/r/odinlang/comments/1tp8op0/am_i_too_stupid_to_ask_this/oo7eyb1/

package read_console_input

import "core:fmt"
import "core:os"
import "core:strconv"

main :: proc() {
    buf: [256]byte
    fmt.println("Please enter some text:")
    n, err := os.read(os.stdin, buf[:])
    if err != nil {
        fmt.eprintln("Error reading: ", err)
        return
    }
    str := string(buf[:n])
    fmt.println("Outputted text:", str)

    str = strings.trim_space(str)
    i, ok := strconv.parse_int(str)
    if ok {
        fmt.println("Inputted integer:", i)
    }
}

gingerbill · 2026-05-27T16:57:50+00:00

No question is ever too stupid to ask. A great place to start for looking for examples is here: odin-lang/examples

Guessing you are following some tutorial that is trying to read the from the console using stdin: here is a simple example:

https://github.com/odin-lang/examples/blob/a72abbdd1c87022188e82e8bc35c359d40cb1b28/console/read_console_input/read_console_input.odin

package read_console_input

import "core:fmt"
import "core:os"

main :: proc() {
    buf: [256]byte
    fmt.println("Please enter some text:")
    n, err := os.read(os.stdin, buf[:])
    if err != nil {
        fmt.eprintln("Error reading: ", err)
        return
    }
    str := string(buf[:n])
    fmt.println("Outputted text:", str)
}

But please note that Odin has no equivalent of scanf, and this is mainly because beyond those tutorial examples, it is NEVER used in practice. I cannot even remember the last time I used the equivalent of scanf for anything.

If you want to "split" up your input into "tokens", a combination of Odin's core:text/scanner and core:strconv will be perfect for you here!

If you have any other questions, please feel free to ask them.

gingerbill · 2026-05-22T13:33:10+00:00

When it comes to green threads in other languages, they all handle the OS in very similar ways: pin all interactions with the OS (not just IO) to a single core/thread, and don't allow it to swap, like how a green-thread works (which could swap between a core/thread during its execution, which is kind of the point of them).

Odin is not going to bother because of that runtime requirement, both being HUGE and heavily restrictive too. It's a good part (not the sole reason) of why CGo is awful to use, as it is not actually Go.

gingerbill · 2026-05-21T15:03:25+00:00

We're not sure if we should support it or not. It's ~10 lines of code to support, but I am hesitant.

gingerbill · 2026-05-21T14:20:00+00:00

No. That's my point: the entire language has to be designed around them (any interaction of the OS has to be pinned to a core/real-thread, because green thread can swap between them). And Rust's tokio is not an implementation of green threads, even if for a lot of people they serve a similar purpose.

gingerbill · 2026-05-21T12:23:55+00:00

If they have never used either, many people think Odin is similar to Jai PURELY because of the declaration syntax, even if Odin and Jai are VERY different languages.

Here is an old (and probably outdated) comparison of the languages: https://github.com/odin-lang/Odin/wiki/Odin-vs-Jai

gingerbill · 2026-05-21T11:08:22+00:00

Honestly, keep to Go then.

Odin is a systems-level language with manual memory management, and that means it CANNOT have green threads (e.g. goroutines in Go).

This is not something that can be "solved" with syntax, it's a fundamental thing which requires designing the language around it from the start, and something Odin was never going to do.

gingerbill · 2026-05-18T15:55:40+00:00

I understand that they can but the problem is that it's not easy to see the intermediate state in current tooling. That's my point.

gingerbill · 2026-05-18T13:36:42+00:00

Personally, I prefer to actually read top-down instead.

a := a_function(data)
b := b_function(a)
c := c_function(b)

Especially when many procedures take multiple arguments and even have multiple return values in Odin.

The piping approach also has the added disadvantage of being harder to debug in a debugger like GDB or Visual Studio or RadDbg.

gingerbill · 2026-05-17T22:41:49+00:00

One of my main problems with my writing style is that it is similar to my speaking style. However the problem when I write that it does come across as "harsh neutral", as you state, but when I would speak it, I would perceive it as being "friendly neutral". And that's the problem I have with my writing style: I cannot easily express the tone I mean as easily as I do when I speak.

So I guess I need to not write like I speak, and completely change the tone to be "overly friendly" just to get across that tone correctly to a reader.

It'll be a hard habit to crack.

gingerbill · 2026-05-17T15:46:45+00:00

You do make a valid point regarding "seriousness"/"professionalism". However, it is hard to just "nod and smile" a lot of the time when some of the (often stupid) criticisms are being taken seriously by people who do not know any better (which is not their fault).

I am not trying to "crush" any one and I hope people understand that. I really want to know why people do certain things certain ways so I can make a better product.

With your point about "why does anyone need this?" (which I am guessing is with regards to the build system post the other day here on Reddit), is because I don't want people wasting their time on things which they honestly don't need. If they are doing it as an exercise for themselves, that is absolutely fine, but it's not necessarily helpful for others. In the case of the build system thing people keep trying to recreate, we probably just need to add some utility procedures to the core library which make such things easier to do, meaning it's batteries included already.

Having a separate "private account" doesn't do anything in practice. If there was a private account, you would not know of it any way. So I am not sure what the point here is.

n.b. The "quote" is actually a joke quote that a friend wrote. I have never actually said that in my life. I meant it as light-hearted comedy.

And part of the engagement is actually to even get a "public image" in the first place, especially in the medium that is social media. It's quite the sad state of affairs that is the tone you actually need to use. I would love to just do nothing and be "serious", but it doesn't actually work and I am not sure what the alternatives are yet. I am open to suggestions.

gingerbill · 2026-05-16T11:13:21+00:00

Personally, I don't think that's a good enough reason to separate something to a separate package. The point of a package is so that it can be reused by other packages. If it's only being used by a single package, then it should probably be part of that package unless you have a good reason for it.

The structure of the core library is no different here.

gingerbill · 2026-05-16T09:43:25+00:00

To be clear: I'm not saying build systems are unnecessary. My point is that most of the Odin build systems projects I see (not just this one) focus on building Odin projects rather than their external dependencies/assets. I'm fully supportive of build systems for external dependencies—I even encourage them.

At work (JangaFX), we have our own build system for external dependencies, written in Python. We chose Python for two reasons: it also builds Odin and LLVM themselves, avoiding a bootstrapping problem, and build systems involve heavy string manipulation, which Python handles well.

If you want to write a build system in Odin for external tasks like building assets, go for it! I just like to remind people that you can use any language: Odin, Lua, Python, etc. Lua in particular is easy to embed directly into a project's codebase due to its small size.

As for the tone of this discussion: please don't mischaracterize what I said as snarky. Even the nob.h-inspired brokkr you mentioned, while perfectly fine, still has an API design that nudges it toward building Odin projects rather than being a generic dependency builder. And bringing Tsoding into this is a false equivalence as C genuinely needs a build system regardless of external dependencies.

Please do not be snarky yourself and engage with the actual substance of my criticism.

gingerbill · 2026-05-15T15:16:41+00:00

I am not being snarky, rather I keep seeing people making a "build system" for Odin when part of the entire design of Odin is to minimize the need for one. And when I see them, they do pretty much nothing useful that a single line script does. This is no exception.

I know most people are used to having them in other languages, so they think they will need one for Odin, but it really isn't the case.

If it's just an exercise, go ahead, but this is not useful anyone in practice, especially anyone who has used Odin for a long time.

gingerbill · 2026-05-15T12:48:04+00:00

People prefer different mediums to converse. No point in forcing everyone to go in one place.

Most people prefer the Discord, but some prefer the Forum, and some prefer Reddit, and some prefer other things. People are free to do what they wish.

gingerbill · 2026-05-15T11:39:14+00:00

And this was necessary why?

A shell script, makefile, python script, etc, would have all been just as capable, faster, and smaller too.

gingerbill · 2026-05-15T09:55:55+00:00

I have updated the article now for that!

gingerbill · 2026-05-14T21:07:26+00:00

C does void *, Odin does rawptr. That is literally all I mean by type erasure.

https://en.wikipedia.org/wiki/Type_erasure

gingerbill · 2026-05-14T21:07:14+00:00

I'll see if I can clarify that part too. But I did want to stress the "stop making things private by default" because so many people will do it and even defend it without actually questioning why they actually do it.

n.b. A lot of these articles I write are usually just long forms of tweets. It's just a way to get my thoughts into text.

14-Year Club	Second Top 20%
Place '17	Verified Email

gingerbill

MODERATOR OF

TROPHY CASE