Odin, a pragmatic C alternative with a Go flavour

First it needs to catch up to some Pascal features like real enumerated types, no iota/const dance.

It does bounds checking for you but there's not memory safety feature a-la Rust. That's not the point of Odin anyway.

There is compile time type introspection in Odin, it's just not that easy to use on purpose. But why do you not want RTTI? One of the reasons I wanted it over CTTI is because it's a fixed cost rather than an exponential cost—at both compile-time and run-time.

People who want CTTI is because they think it will produce better code because it is specialized for that type, and that is partially true, but also it will produce a hell of a lot more code. The canonical example of what I mean is the difference between doing something like `core:fmt` in Odin, which is a fixed cost at both compile-time and run-time, and then doing something closer to `std::format` in C++ (or other similar things in other languages) which will do a specialized procedure for each set of argument types. The former might be a huge initial cost if you only have a single type you want to print, but that cost is always the same regardless of many more types you add, it's also easier to debug. The latter is a small initial cost per type, and when the types get more and more complex, you also produce more and more code, which in turn increases the compiling time and binary/executable size.

As for the conditional imports, we did use to allow them but we found that what people were doing with them was kind of missing the point of the platform-specific features of the `package` system, and their code was always better if it actually utilized the package system correctly. There were some other quirks with the conditional imports which did confuse people because they didn't realize how things had to be executed (to allow for out-of-order type checking) and just disallowing it in the first place just solves that too (as a consequence, not as a goal).

"go flavour" refers to the similarity in the design philosophy, and some of the features. That said, it's still not Go.

For example, "errors as values" is a point that Odin makes, but it does make it in a slightly different light from Go. Whereas Go has an `error` type that encompasses all errors, Odin does not. Instead, it treats some types (booleans, enums, unions) as "special", in that they support things like `or_return`, which are typically your error propagation statements. Oh yeah, `or_return` is another big point, it does simplify a lot of `if err != nil { return err }` type of code.

And another big similarity to Go is the declaration syntax. It was inspired by one of Rob Pike's (iirc) comments on twitter about how they should have used a different syntax for Go instead.

From personal experience though, there are some things in Odin that I wish Go had. Its features play along together so nice, and it's so satisfying having three different language features come together in a nice logically-coherent simple way. That said, I don't think Odin is capable of replacing Go. Things like server-side logic and lightweight threads are probably where Go still excels at and beats Odin.

For systems-level programming I'd pick Odin though.

Thank you for the kind words regarding Odin! So Odin is in the family of Pascal _but_ I've tried my best to design it in such a way that it does "fix" most of the problems of C (since I am/was a C programmer), and make it _feel_ good to a C programmer when programming in the language.

My view is that the core of Pascal was actually the correct place to start rather than the core of C. C won out of Pascal purely because the original Pascal didn't fix its problems quick enough, and all of the successors also tried to focus on other fancier things like OOP or GC or whatever. C still remained "basic" and its preprocessor allowed for enough extensions for lacking language features, whilst not adding any of those fancier things.

For Odin, I tried to take the lessons of what I and others were emulating in C and just make them core constructs. Odin initially didn't have many of the constructs it has now such as parametric polymorphism or explicit procedure overloading, but all of them came about as a result of solving the problems people used the preprocessor for or other new features. For example, the explicit procedure overloading came about seeing how people use the (relatively new) C11 `_Generic` feature, and realizing that they were trying to emulate this aspect pretty much.

Odin also took a lot of the GNU C extensions and incorporated them directly (some of which are not in the latest version of C): `0b` literals, nested procedures (but not scope capturing), `type_of`, `case` ranges (`..Odin isn't a C++ alternative by any stretch, but I have seen a lot of C++ programmers really like it because it feels like it has just enough to make them feel at home whilst still have the control and more explicitness that C offers.