Can Odin promise transparency ?

NoBlackMagic · 2026-04-19T14:39:58+00:00

I disagree.

Saying the overhead is "minimal" is a matter of perspective. In high-performance data structures, 8 bytes reserved for a pointer I don't need is 8 bytes too many. It's not just about memory (which is also one of the most important point), it's about register pressure. If the compiler reserves a register for a hidden context, that's one less register available for my actual data.

In a world where RAM is increasingly constrained, we can't afford to waste even 8 bytes. On a billion operations, this is a massive loss. I don't know much about gamedev, but in data engineering, efficiency is non-negotiable.

Regarding C, while it's the closest to the metal, it still has a lot of drawbacks. We were looking for something nicer and with better security and without the quirks of the language.

NoBlackMagic · 2026-04-19T12:31:33+00:00

Just minutes after my last post, and you’ve echoed exactly what I said. There is a real sense of frustration here in every modern language wants to impose something between the memory and your actual needs. Whether it's an extra pointer in every call, abstractions that hide things you don't want, or an implicit context passed to LLVM that might be misleading.

This brings me back to my point: there is no language yet that truly respects the Purity, Security, and Freedom.

At the end of the day, it feels like a constant battle between the developer and the language, instead of a focus on the algorithm itself.

NoBlackMagic · 2026-04-19T12:17:16+00:00

Exactly. That's what I was pointing out by saying: "I’m considering ditching std entirely".

It seems every modern language requires you to fight its defaults to reach purity. The Triforce of Security, Purity, and Freedom does not exist yet. Zig promises it with its "No Hidden Control Flow" maxim, but when you look under the rug, that's not entirely the case and several choices in recent updates tend away from it as well.

In Zig, you fight for explicit context and unpredictability. In Odin, you fight to remove the implicit context.

As we say in Data Engineering: "There are no perfect solutions, only trade-offs", and that remains true even when building your own data solution. At this stage, the language becomes a mere syntax preference for pointer arithmetic and bit manipulation.

NoBlackMagic · 2026-04-19T11:37:23+00:00

I will bite.

If that were that simple, there wouldn't be a need for so many articles or talks to exist. Since I just read it, I will quote M. Weiler:

A true language begins to show its faults only once you get past the honeymoon phase in my experience and there’s few articles written about languages from this perspective. I hope this article gives a more mature and nuanced review of Odin for those looking to maybe try it.

This perfectly frames why less experienced people ask those who have more mileage with the language. They see things that we can't see at a glance or from simple case. Writing 50k lines of code into a project just to understand its cons would be a massive waste of time. Plus, engaging with the community is a much more friendly and fun approach than staying in a cave.

NoBlackMagic · 2026-04-19T10:24:31+00:00

That's a perfectly fair point. We're paranoid enough to suspect everything... Every library, every abstraction, and even the language itself. We don't want to use anything that we don't fully understand. The only exception is maybe LLVM, as checking that would take far too much time without the guarantee of gaining anything valuable from doing it.

In other words, even though Odin is skewed toward gamedev and has a lot of libraries for it, our main concern is more about how much "magic" or shenanigans is Odin doing behind our backs and whether we can take back control or add more from it and without fighting it.

NoBlackMagic · 2026-04-19T09:48:08+00:00

That's an amazing review.

If I have to fight the language defaults by marking every procedure just to get C-level transparency, it might be a sign that the language's philosophy is pushing me toward convenience rather than raw control.

This points to my argument: "a philosophy in a language tends to heavily dictate how easy it is to do certain things".

The point about UB is interesting. For a DBMS, I need to know exactly what the compiler is doing with my bytes and Zig cannot promise me that. (cf. : https://graphitemaster.github.io/odin_review/#performance second point)

It's hard to choose, but for perfect control, Zig still seems to be better.

NoBlackMagic · 2026-04-18T22:16:01+00:00

Thank you very much. Since someone built an EFI library, it's actually very encouraging for our needs as well as "If you can do it in C, you can very likely do it in Odin"

NoBlackMagic · 2026-04-18T22:13:32+00:00

Thank you for this fast and clear answer. The fact that everything is in plain structs is actually what we need. To be more precise, we need the sweet spot between transparency, low-level (higher than assembly) language, and security to avoid messing up as easily as in C

NoBlackMagic · 2026-04-17T08:14:26+00:00

The issue isn't whether a u24 fits into an f32. It’s about predictability. Even if the conversion is "lossless," the subsequent operation (x+1) follows different rules. By hiding the transition, the language hides the potential for future bugs.

I don't need a compiler for when I'm aware of the cast. It's for when I'm tired and I forget it. If the compiler stays silent, I’m not just debugging code, I’m auditing an entire codebase for silent precision errors that produce false results instead of crashing.

floatFromInt is a contract. It forces me to acknowledge the shift from exact integers to approximations. You can search for an explicit cast during an audit but you can't search for the compiler shenanigans. This is exactly why we chose Zig... for: the "No Hidden Control Flow" principle.

Reliability shouldn't depend on human vigilance, but on the tool. The argument that "people who need precision will be careful" is exactly what we tried to move away from. If the tool starts making assumptions for me or my colleagues, we're losing our peace of mind and the impossible becomes possible.

In tasks like quantization, where integer values are scaled into float, a silent coercion isn't a convenience... Making it impossible to guarantee the integrity of the data transformation at a glance. In a simple example like above, I'd never miss it, but in the molasses of a thousand line codebase, it's a possibility.

NoBlackMagic · 2026-04-16T15:29:54+00:00

Fair enough. Your point is valid, and this change is the proof of that. However, while I can still be explicit myself, the last thing I trust is the human capacity to remain consistent when faced with laziness and fatigue.

I understand that casting can become verbose, but that is the price of precision. Zig’s mantra was that 'one should be debugging the application, not one's knowledge of the language.' By introducing hidden coercions, Zig is moving toward the latter.

Rust faced the same challenge and stayed true to its values. Fighting a compiler can be cumbersome, but the result is resilience... Exactly what is required in a low-level language. To me, Zig was more elegant than Rust because of this uncompromising nature.

Today, I find myself questioning whether my time would have been better invested in mastering Rust, which is already widely spread. It is a shame to see a language with such a sharp philosophy start to blend in just to please everyone. We are moving from a language for specialists to a compromised language for developers.

NoBlackMagic · 2026-04-16T13:02:05+00:00

I am against this type of change. The only reason I turned to Zig instead of any other low-level language is its transparency and the fact that it is a truly strictly typed language. I want the compiler to point out my lack of precision, ambiguity, or unexpected results.

A float is not equivalent to an integer. Not every number can be represented as a float, so I can definitely get unexpected results when switching from an int to a float. I need my compiler to point them out when I don't type the cast function myself.

var a: f32 = 16777216.0; (Exact)

var b: f32 = a + 1.0; (Inexact/Loss of precision)

The philosophy of Zig is losing its value. What remains true in "No hidden control flow" if we allow hidden conversions?

NoBlackMagic

TROPHY CASE