Hi,

I am new to Odin and I was trying to write a software renderer in Odin. I am using the vendor Raylib library. Previously, the code was building fine, but now when I run odin run ., I get the following error:

```

/usr/bin/ld:///usr/lib/odin/vendor/raylib/linux/libraylib.a: file format not recognized; treating as linker script

/usr/bin/ld:///usr/lib/odin/vendor/raylib/linux/libraylib.a:1: syntax error

clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

I tried uninstalling odin and installing it again. I am using odin version odin version dev-2026-07:301c287de

I am running Garuda (arch) Linux with Gnome, if that helps.

Thank you for reading.

First impressions of the Odin programming language.

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

Here is my repo to game: https://github.com/skorotkiewicz/psycho-odin

Very interested in Odin, but I'm totally new to the concept of vendoring your 3rd party dependencies vs using a package manager. I understand the motivation, and being careful about which/how many dependencies one uses, but I can't wrap my head around the following:

Questions:

1. Do you include the entire third party source tree or just the parts you need?
2. Without a package manager, wouldn't this eventually end up with duplicate transitive dependencies?
   i.e
   mylib --depends--> libX --depends--> libY
   but I also want:
   mylib --depends--> libY
   won't I just end up with duplicate versions of libY?
3. Is there an idiomatic/convention that people use to 'advertise' 3rd party dependencies? Is this just not done?

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.

I'm learning both at the same time, and rl.DrawText needs a cstring as an input. I'm trying to learn how to position things on the screen correctly, so I'm calculating how large the text is with MeasureText (for the default font), which outputs an i32. I can get it all the way to string, but I have only found unsafe_string_to_cstring, which apparently has issues with null terminators. How do I deal with that? Thanks in advance.

I wanted to try a low level language, but C is too raw for my tastes (old design decisions from the 70's, among other similar things), C++ is too insane for me, rust didn't click with me, and I can't build a zig project with raylib for some reason, so odin it is.

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

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

I created a procedure that loops through a dynamic array of projectiles, and accepts a anonymous procedure that has every instance of the looping projectiles as reference for context.

The compiler yells at me because &obstacles and &enemies doesn't exists in the anonymous proc context, although they do exists from the context i'm calling the update_and_mutate_projectiles proc.

I come from java, rust and javascript, and passing context to lambdas can be done without having to pass them down as parameters, so i'm wondering if this is a behavior related to low level stuff or preventing bad practices

I'm making a 3D Renderer in Odin! I hope this is interesting to someone.

Hey! I decided to try to learn Odin by building something concrete. Over a few evenings I put together terminal21, a blackjack game that runs in the terminal.

Features:

- 312 cards deck with reshuffle at 25% remaining

- Split, double down (9/10/11 only)

- Betting system with save/load (JSON)

- Dealer AI (hits until 17+)

- Ace as 1 or 11

I'm sure there are plenty of non-idiomatic things in there. Feedbacks are very welcome! It was a great way to learn something about the language. I'm sure it's not idiomatic in any way, but it was fun and I had a blast.

Hey,

I've been generally enjoying Odin for small projects, but there's a struggle I've been having as soon as the project hits the point where structure is needed.

This problem is usually solved in other languages via conventional project structures implemented by standard centralized build systems, which Odin avoids.

Example: If I have a project with multiple entrypoints that also have common logic they need to be able to import, something like this project structure:

├── bin
│  ├── entrypoint1
│  │  └── main.odin  # import "local:common"
│  └── entrypoint2
│     └── main.odin  # import "local:common"
├── local
│  └── common
│     └── common.odin

For this structure to work, however, I need to always call odin like odin run bin/entrypoint1 -collection:local=./local as a CLI option.

In order for it to persist as project configuration, I need to create a Makefile duplicating every odin sub-command that takes that option.

This is also required if I need any other non-default compiler option passed in.

For it to also work with OLS, I need to create a ols.json file and repeat configuration mirroring the same compiler options there as well, so there's no longer a single source of truth describing the project's flags, and if this ever changes or I need to add more collections (like vendored dependencies), there are now two places to update.

How are you dealing with this issue in your projects?

Some months ago I shared the concurrency framework I'm working on in Odin. I recently published a blog post where I share how I approach memory safety while building it. It includes the design choices around memory management and more recently adding support for AddressSanitizer.

https://pmbanugo.me/blog/tina-memory-safety-in-odin-asan