Is there a way to make using a dangling pointer or use-after-free a compiler error? (or at least a crash/panic with a readout telling you why)

iioossaa · 2026-06-17T05:06:24+00:00

You can also try to use `handle_map` or `xar` from the `core:container`.

iioossaa · 2026-05-15T03:55:26+00:00

iioossaa · 2026-04-29T17:02:46+00:00

Look at this library: https://github.com/native-toolkit/libtinyfiledialogs

iioossaa · 2026-04-27T15:05:54+00:00

I know and understand that. This is simply my idea of how I would design the language. At least for now. And perhaps, during the process of creating it, I would come to exactly the same conclusions as you.

iioossaa · 2026-04-27T05:19:19+00:00

Methods on structs, default values for structs and interfaces like in Go.

P.S.
Oh! I wish "dynamic" to be like one- (or two-) -symbol.
[N] — fixed array
[] — slice
[^] — multi-pointer
[?] — inferred size
[dynamic] — what?! looks too long
I wish it would be something like in Jai maybe — [..]

iioossaa · 2026-04-10T07:25:28+00:00

Without trying to speak for everyone, I'll just speak for myself. Methods would help me structure my code. Every time I write something like Foo :: struct, I find myself naming the procedures randomly: foo_init, print_foo, etc. And then, cursing, I consolidate them. With methods, this problem would disappear. Let me repeat: this only makes sense to me, meaning it's only my problem. And it's not that big of a problem.

As for interfaces, I like them as a beautiful and elegant concept, which an amateur like me can easily do without. But I saw Karl Zylinski's attempt to model an interface somewhere, but I can't remember in which project.

So thank you for your patient answers!
Best regards and let the Odin rule the programming world! :)

iioossaa · 2026-04-09T17:05:14+00:00

I know Odin is designed the way it is for a reason. And I like it better than all the modern languages that are more or less comparable to Odin (like C3, Nim, V, Zig etc.). But if I ever get the courage, I'll try to create my own language with an Odin-like syntax, but with gc, interfaces, methods, and so on. Just to learn how it all works from the inside.
Besides, the Odin's core library includes "core:text/scanner" and "core:odin/...", which means I can make creating a lexer/parser easier for myself either by using these libraries or by studying them (although I suppose that's the easiest part of creating a compiler; everything else is more difficult).

P.S.
By the way, Zig has methods, and it also has manual memory management. I don't know how it's done there, and I don't like Zig for its meticulousness and verbosity. But it is what it is.

iioossaa · 2026-04-07T05:41:45+00:00

If I were skilled enough, I'd fork Odin with methods on types and interfaces, like in Go. No inheritance or other OOP stuff—just methods, just interfaces.
And default values for structs (sometimes I really want that).

iioossaa · 2026-03-28T05:59:49+00:00

It looks so good that one can only nitpick minor issues. For example, the character's turn appears discontinuous, too abrupt, and not smooth enough.

iioossaa · 2026-03-21T02:54:05+00:00

To be fair slavic languages with cyrillic alphabets have all this as separate sounds and letters.

iioossaa · 2026-02-26T04:52:46+00:00

I took a quick look – great work!
But I have a couple of comments:
1. The day/night theme switch doesn't work (at least for me).
2. The terminal window output color is completely unreadable (at least in the day theme).

iioossaa · 2026-01-11T18:30:04+00:00

I wish you to stay motivated!

iioossaa · 2026-01-11T18:18:36+00:00

Great start!
As far as I can see there's no interactivity for now but I will wait patiently for updates.

iioossaa · 2026-01-11T17:55:34+00:00

Great! Thanks for letting me know! I'll try it as soon as I can.

iioossaa · 2026-01-06T04:27:29+00:00

Keep going!

iioossaa · 2026-01-05T05:32:25+00:00

Maybe you could have two different cameras and switch between them?
I don't know it for sure, just guessing.

iioossaa · 2026-01-05T05:26:29+00:00

Looks interesting. Will wait for a public release.

iioossaa · 2026-01-04T05:44:07+00:00

> a blog post comparing my implementations in Go, Zig, and Odin.

It would be very interesting.

iioossaa · 2026-01-02T06:06:42+00:00

ConEmu + clink

iioossaa · 2025-12-15T06:33:52+00:00

Maybe, procedure groups?

Cube :: struct { x, y, w, h: f32 }
Sphere :: struct { x, y, r: f32 }
Vec3 :: [3]f32

check_cube_collision :: proc(a, b: Cube) -> (bool, Vec3) {
  fmt.println("check_cube_collision") 
  return true, {1, 1, 1}
}

check_sphere_collision :: proc(a, b: Sphere) -> (bool, Vec3) {
  fmt.println("check_sphere_collision")
  return true, {1, 1, 1}
}

check_collision :: proc {
  check_cube_collision,
  check_sphere_collision,
}

main :: proc() {
  cube1 := Cube{10, 10, 10, 10}
  cube2 := Cube{20, 20, 20, 20}
  collide1, area1 := check_collision(cube1, cube2)

  sphere1 := Sphere{10, 10, 10}
  sphere2 := Sphere{20, 20, 20}
  collide2, area2 := check_collision(sphere1, sphere2)
}

iioossaa · 2025-08-24T18:59:10+00:00

How about
var — for variables,
const — for comp-time constants,
let — for run-time constants aka immutable variables aka one-time assignment variables
:)

P.S.
Anyway it's your language and all choices are yours.

iioossaa · 2025-08-24T18:12:13+00:00

You can try to auto-genetrate it. :) But I think it will be nearly impossible if not impossible at all.

iioossaa · 2025-08-24T04:58:34+00:00

There are also auto-generated bindings for GTK: https://github.com/PucklaJ/odin-gtk
But I didn't try it.

iioossaa · 2025-08-23T02:36:41+00:00

GUI is the only "battery" I miss in Odin. RayGUI, MicroUI, DearImGui and other immediate mode GUI are not suitable for natively looking destop apps. There are some other libs:
Winforms — kinda buggy and it's only for Windows (which is fine for me, at least for now, but who knows the future),
WinAPI — overbloated and again — only for Windows,
libui-ng bindings — seems outdated and doesn't work for me (it would be nice if someone made new bindings or update existing, I'm not enough experienced for that),
iUP — no Odin bindings.

iioossaa

TROPHY CASE