Odin, a pragmatic C alternative with a Go flavour

[flagged]

Where can I follow Odin's progress other than the blog? It doesn't seems to have any social media presence.

And what sort of time frame in terms of 1.0? I found Odin lacks the marketing push from Zig or Rust.

So Odin the language in-itself is effectively done. But of course the core library, vendor library, tooling, etc are still very much being improved.

The reason for the lack of "social media presence" is because Odin is kind of weird to market for: https://www.gingerbill.org/article/2024/09/08/odin-weird-to-...

It's not "hypeable" like Zig or Rust mainly because it doesn't have any "killer features" but rather is a very pragmatic language by design. The people Odin attracts are also not the types of people to evangelize Odin either, since they are not there for the hype-train but to actually program.

So if you can help us find a way to market Odin itself without lying or exaggerating or overblowing minor features, then that would be very much obliged. It's a lot harder than you think.

As for "1.0", we have never worked to a timeframe for anything nor any sort of roadmap. The reason being is that we do not want to give false promises/hope about anything. Roadmaps are purely for advertisement, and the problem is, we don't even work to one so why present one? The other problem is that for "1.0", the language itself is well known: it's pretty much what you see today. But "1.0" for the general tooling? Now that's a harder question. We have plans but since everything is being worked on as we go (mostly volunteers), we cannot say when things will be finished. The biggest project at the moment is `core:os/os2`, the replacement for the `core:os` package. `core:os` was the first package ever written for Odin and it's absolutely dreadful and needs replacing. And that's what we've been doing with `core:os/os2`, slowly. And when it is ready, we will tell people many months in advance when we will make it the official one. This will be a breaking change, but probably the last biggest one for Odin.

I took a good hard look at everywhere I may have stored it, but I believe I lost the original list after formatting.

I remember believing these were important:

- methods (turned out I mainly wanted working intellisense, which Odin does even without methods)

- a package manager (still a gripe, but git submodules do the trick somewhat)

- expressions (so I could assign the result from a `switch` statement to a variable for instance, but I can use an #inline proc if I _really_ want to)

- private by default (I had forgotten how many times I wanted to use something private from a library, and had to fork it instead)

- - although possible to make something private in Odin, nowadays I'd rather things be prefixed with underscores instead

Also, here are my list of things I'd still prefer changed, but are less important: https://forum.odin-lang.org/t/what-features-of-odin-do-you-d...

I haven't read the article yet, but this seems to conflate compile time evaluation with metaprogramming. Not all comptime evaluation is metaprogramming. I would argue the majority of comptime programming as it is used in Zig isn't even metaprogramming. Metaprogramming is a paradigm where there source or target data structure is primarily the language you're programming in. comptime evaluation of expressions that could be runtime evaluated is not that. I would argue that comptime evaluation of expressions that return comptime only values (like types) is not even inherently that.

Where you start to see actual metaprogramming in Zig is in functions like @typeInfo, @alignOf, @offsetOf, which actually let you operate on language constructs (ie: looping over the fields of a struct). This is not extremely out of the ordinary, but it's not done "as much as possible".

Another place that metaprogramming shows up in Zig is code generation using the build system. I've never done this, and I would argue this is usually recommended to be done as little as possible, rather than as often as possible.

Edit: I read the article, and while I think that the author was wrong about Zig pushing metaprogramming "as much as possible", they were fairly accurate in how it is used in the rest of the article, like for serialization. The thing is, most of my programs are not serialization. I use serialization as a means to do other things.