For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more useful built-in primitive data structures like associative arrays and matrices, custom allocators, function overloading, reflection, etc.
You can find odds and ends of these things in other Pascal successors like Delphi, Oberon and Object Pascal. Truth is though, I never found these languages compelling. Why? Because none of them were anywhere close to being the same kind of simplicity as Pascal, and they were too wrapped up in flashy, trendy things that went out of style. Where Odin wins out is that it distinctly lacks the 90's OO craze hangover, and it never feels particularly more complicated or bloated. It's an audaciously tasteful proposition for a language. A C replacement? No, not really. But as a C++ programmer who's fed up with the lack of things like structure introspection and ergonomic sum types, I'm keeping a very close eye on Odin.
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 (`..<` and `..=` in Odin to be more explicit about the range bounds), array initializes with ranges, unnamed structs/unions, empty structs, and so much more.
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.
Perhaps not modern C++, but I would absolutely place it in the same weightclass as CFront and C++98 (albeit with less bugs and more ergonomics than those). I know you've placed the language adjacent to gamedev, so an appropriate metaphor, I feel like Odin is up to the task of making something with the complexity of a Goldsrc game, or a Dreamcast game. I feel like I could churn out half a million lines of high density soft real-time code quite happily.
Excited to see how it evolves through the years. Keep up the good work!
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 feel like the lack of marketing push is for two reasons. One is that it feels like Odin simply doesn't desire the kind of attention the other two languages have. Two is...I can't speak for Rust, but I feel like Zig punches well above its weight because of comptime, privileged support for Result <T, E> in the form of error unions, and having a realistic roadmap for porting C code thanks to translate-c and its build system.
From what little I've seen of Odin, it doesn't have anything in particular that's especially headline-grabbing. However, Odin does have one thing that Zig doesn't, and it's that the language is considered "complete" despite its git repository being newer than Zig by a year. When it comes to programming languages, I do feel like there's something to be said for ease-of-implementation, and although Zig _feels_ simple from a feature-set point of view, I imagine it has a much higher bar to clear in terms of implementation complexity.
> Delphi, Oberon and Object Pascal [..] I never found these languages compelling. Why? Because none of them were anywhere close to being the same kind of simplicity as Pascal
Agree. Oberon comes close, but has other orthodoxies like upper-case keywords, and it lacks the low-level support of e.g. Delphi. I spent a lot of time with extending Oberon, but backward compatibility prohibited some features I thought were necessary. My forthcoming Micron language is this kind of "better Pascal" you mentioned; essentially it's an Oberon withouth orthodoxies and with the power of C (without its disadvantages); there are language levels from minimal, stack-less systems, up to dynamic dispatch and optional garbage collection. See https://github.com/rochus-keller/micron/.
I checked out bcrypt implementation in Hare, and I saw "errors::invalid" being used. It was not specified. What if I want to have more errors and in the documentation I want people to know which errors, say, my library may return from specific functions?
C3 had some weird stuff going on at some places, not exactly sure why. In my other thread someone else already went into it in more detail. I hope the developer will fix it. Needs to stay as close to C as possible and build on top of it, only some of the goodies.
Thank you! I appreciate you opening the issue with regarding to enum's "elements". I would have to take a serious look at C3 to be able to be useful, but I cannot do it right now due to some health and financial struggles. :( Hopefully soon enough though! I want to have C3 as a better C alternative.
Did you take a look at Ada as replacement for Pascal ? With the 'gnat' compiler and some doc (https://www.adaic.org/learn/) I think you can find what you are looking for.
I think Nim is much more of a pascal successor than Go ; It retains some of the syntax and feel, although it uses Python style indentation instead of begin/end.
It is by no means pascal-simple - although the subset used by 95% of programs is.
It does have everything you need including macros, unsafe access, minimal OO but these are almost exclusively used by library developers.
You can find odds and ends of these things in other Pascal successors like Delphi, Oberon and Object Pascal. Truth is though, I never found these languages compelling. Why? Because none of them were anywhere close to being the same kind of simplicity as Pascal, and they were too wrapped up in flashy, trendy things that went out of style. Where Odin wins out is that it distinctly lacks the 90's OO craze hangover, and it never feels particularly more complicated or bloated. It's an audaciously tasteful proposition for a language. A C replacement? No, not really. But as a C++ programmer who's fed up with the lack of things like structure introspection and ergonomic sum types, I'm keeping a very close eye on Odin.
[1] - https://c3-lang.org/
[2] - https://harelang.org/