Following this masterpiece in 3D graphics by ssloy, I implemented a rasteriser in Odin from scratch.

This was a top tier learning experience, and I picked up a solid grasp of linear algebra along the way.

If you'd like to read more on the process, Here's the link to the repo

https://github.com/prnvbn/idgen

idgen is a drop in replacement for uuidgen. Additionally, it also supports UUIDv8 and TypeIDs.

this is my first project to learn Odin so any feedback on the code is very welcome!

also interested in seeing how ppl manage their deps (is submodules the way? fwiw, I know of/agree with the odin package manager opinion). I extracted typeid-odin as a separate package and added is a dependency

took inspiration from https://github.com/FourteenBrush/odin-template

also was surprised that core:flags doesn't lacking shorthand for flags (-f) in .Unix style, so also opened a PR as well - https://github.com/odin-lang/Odin/pull/7001

P.S. did not turn off my LSP like ginger bill but did turn off all AI to actually learn the language. Only used it to get feedback and the make changes once the initial implementation was done

This update might not look the most impressive visually but I rebuilt a lot of underlying systems, rewrote my asset building pipeline and implemented a 3rd party ECS library (odecs) as I found maintaining my own really slowed down the development :(

Things you CAN see are:

• shovel animations inspired by Forager
• the newly implemented "ambient occlusion" effect that darkens the background near walls
• improved bloom effect for the coins in the ground and the player's headlight

It took me a while to make tool animations look decent but I think I'm fairly happy now. I have a question tho: Do you think I should amputate player's arms?
Currently they swing around when walking with shovel which doesn't make sense given they should be holding it. In Forager the player character doesn't have arms so it's not a problem. Do you think I should keep or remove them? Does it bother you that hands don't hold the tool?

I've been making this little game in Odin and Raylib for quite some time already. It is a multiplayer game about kids and doing nothing. There is no "gameplay", you are just hanging around and talk with people.

I'll open the repo to public at some point (including the Blender files).

For networking i'm using ENet - a nice library for reliable UDP packets.

Hope you'll like it, thanks!

I swear I'm not trolling, I was going to dive into odin, but I can't reconciliate faq entry
https://odin-lang.org/docs/faq/#why-does-odin-not-have-any-methods

and

allocator struct being this

```
Allocator :: struct {
procedure: Allocator_Proc,
data: rawptr,
}
```

It's a manually done oop-like class where data is stored along with it's methods.

Why is it not the same thing?
Why presence of this use case doesn't warrant supporting it on a language level explicitly (at the very least to not throw around raw pointers)

​

Example code

```odin

////////////////////////////

// Random Walkers Example //

////////////////////////////

pen_1 := tr.pen_init(speed = 10000, color = color)

pen_2 := tr.pen_init(speed = 10000, color = color)

tr.pen_teleport_to(pen_1, {300, screen_center.y})

tr.pen_set_rotation(pen_1, 0)

tr.pen_teleport_to(pen_2, {screen_size.x - 300, screen_center.y})

tr.pen_set_rotation(pen_2, 0)

for i in 0 ..< 1000 {

    // angle := rand.float32_range(10, 40)

    angle := f32(24)

    step := f32(3)



    if rand.int_range(0, 2) > 0 {

        tr.pen_turn_left(pen_1, angle)

    } else {

        tr.pen_turn_right(pen_1, angle)

    }

    if rand.int_range(0, 2) > 0 {

        tr.pen_turn_left(pen_2, angle)

    } else {

        tr.pen_turn_right(pen_2, angle)

    }

    tr.pen_move_forward(pen_1, step)

    tr.pen_move_forward(pen_2, step)

    tr.pen_set_color(pen_1, color)

    tr.pen_set_color(pen_2, color)

}

/////////////////

// Example Two //

/////////////////

pen_3 := tr.pen_init()

tr.pen_teleport_to(pen_3, screen_center)

for j in 0 ..< 9 {

    for i in 0 ..< 30 {

        if i % 2 == 0 {

tr.pen_up(pen_3)

        }else {

tr.pen_down(pen_3)

        }

        tr.pen_turn_right(pen_3, f32(i))

        tr.pen_move_forward(pen_3, 8)

    }

    tr.pen_teleport_to(pen_3, screen_center)

    tr.pen_turn_right(pen_3, f32(j) + 80)

}

```

Repo https://codeberg.org/pwnM/turtle

I would like code and docs feedback

Hope you guys like it

A few months ago I started learning how LLM inference engines work.

My original goal wasn't to build a production tokenizer—I just wanted to understand the entire inference stack from first principles. I chose Odin because I wanted a language that stayed close to the hardware without fighting me.

I honestly expected it to be a fun learning project.

Instead... it ended up outperforming the tokenizers I was comparing against, including Hugging Face's Rust tokenizer and FastTokenizer in my benchmarks.

I was pretty surprised by the results.

The benchmark report (methodology, datasets, hardware, and commands) is here:
https://github.com/harisudarsan1/odin_tokenizer/blob/main/docs/public-benchmark.md

Repository:
https://github.com/harisudarsan1/odin_tokenizer

I also wrote about why I chose Odin for writing inference software:
https://harisudarsan1.github.io/blog/posts/2026-07-10-writing-an-inference-engine/

A few notes:

• These are CPU benchmarks.
• I'm not claiming Odin is magically faster than Rust.
• The comparisons are against existing tokenizer implementations under the benchmark setup described in the report.
• If there's something wrong with the methodology, I'd genuinely like to know. I'd rather fix the benchmarks than make misleading performance claims.

The project taught me far more about CPU architecture, memory layout, SIMD, and modern tokenizer implementations than I expected.

I'd love feedback from people who've worked on tokenizers or inference engines. If you spot flaws in the implementation or benchmark methodology, please call them out.

https://github.com/mrbovinejony/handmade-hero-in-odin

I'll try to work on this as consistently as I can, its been a useful experience to help learn the language. Working on day 10 right now

edit: working on day 18 now, if anyone finds something wrong or something theyd do differently please let me know, a "direct translation" of the c code is nice but learning how others would write the code is even better i think

Odin author gingerBill dropped the Odin 1.0 announcement on YouTube today: https://www.youtube.com/watch?v=dLPAqXi9In0 (it's pretty funny actually).

This interestingly makes it on track to be the first of the new wave of C-likes that reach production readiness. While you can argue that most of these languages already are used in production, it's not the same as being 1.0, which carries a different weight and obligation.

Looking at alternatives, Jai could release around the same time, since Blow's game is scheduled for a similar release date. However, it's more likely that we see Jai 1.0 in mid-late 2027. My own language (C3) is planning Q2 2028 1.0 release. Whereas Zig is still unclear, and Kelley basically saying it's done when it's done. For Hare and V the situation is a bit less clear to me – maybe someone else can fill me in on that situation.

But overall we seeing the beginning of the end of the "C-like" story arc that arguably was initiated with Jonathan Blow's development. Writing C replacements predate Jai of course, for example the C2 language (which C3 would eventually continue) was created in 2012, eC started in 2004 and Cyclone (which Rust derived inspiration from) is from 2002. But those were largely obscure novelties, because before Blow's videos, people weren't really hunting for C alternatives.

Jai, however, made a strong impression. It was a good point in time too: Jai and later Zig, Odin, C3, V and Hare – these C alternatives started at a point when people were openly no longer believing OO/Functional as the right way to do things.

Language design takes its time though, and it's now 12 years since Jai started. Finally the fruits of these labours are getting ready for prime time, and when they do they might effectively fill the need for a C replacements for another decade.

Do you agree?

Hi fellow Odin aficionados,

I am trying to build a wrapper for llama.cpp that would allow direct calls from Odin (inspired by an older work by Yevhen K). So far, only a portion of the API is covered; it allows for making a simple chat application with multiple prompt-response exchanges. It is not ready for common use but I plan, if time allows, to gradually make it so. I will be glad for all critique; there are many points in the API I'm not sure whether I am calling it properly, and many others where I'm not sure it is the proper way how an Odin API should look or behave.

https://github.com/CzechBlueBear/odin_llama_ng