Odin, a pragmatic C alternative with a Go flavour

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.

> 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/.

While I do agree that C3 tries a bit harder to keep closer to the look and feel of C, it has arguably already veered too far away, in order to be modern. These changes can be viewed as unacceptable to many fans of C. C3 has taken on a very strong Odin and Jai flavor. Since that's the case, the argument for Odin, Jai, Vlang, etc... would be equally valid. If you are going to make a modern language, then their creators should not feel too restrained.

There are other C family languages that have a Pascal influence and didn't go OO crazy, not just Odin. So in that context, languages like Golang, Vlang, Jai, etc... are equally viable alternatives to look at.

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 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.

Isn't Go the modern successor of Pascal? It certainly didn't fall down the OO hole.

Hard disagree the simplicity of Pascal, is what made it unusable outside the original goal to learn programming.

Instead we ended up with UCSD Pascal, Object Pascal, TMT Pascal, Quick Pascal, VMS Pascal, Delphi and what not.

By the time it came to be, ISO Extended Pascal was largely irrelevant, outside some UNIX compilers that supported it.

The Borland linage, after taking over Apple's design, which had input from Niklaus Wirth, is my favourite, then their management messed up.

In an ideal world, Modula-2 or Ada would have taken over, sadly no big name OS vendor, ever felt like adopting them.

As for Oberon, when I came to learn it, Oberon-2 was already out, eventually Component Pascal and Active Oberon were much more interesting to me.

While I appreciate Niklaus Wirth work, I was never a fan of the minimalism he tried to pursue with Oberon-07. Then rather use Go.

In the end, nothing of this will matter in the age of AI assisted tooling and code generation.

Arguing what is the best language is getting akin to argue about Assembly language syntax, when most people are using optimizating compilers.

> but doesn't give you a whole lot to make your own custom data structures

For anyone unfamiliar with Odin that might misinterpret this, Odin has structs and parametric polymorphism for those structs. What it does not have is operator overloading or methods (which also means no constructors or destructors). In this sense, its product types are like ocaml's, only without methods too. Odin is not object oriented.

I'm kinda curious, you mind sharing some of the things you thought you didn't like?

Can't comment on RTTI, but lack of conditional imports are indeed an annoyance but I'm willing to put up with it because of all the other niceties in the language.

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).

You should be able to import everything, then use `when` to generate a unified constant name:

@(require) import "x_a"

@(require) import "x_b"

when ODIN_OS == .Windows { x :: x_a } else when ODIN_OS == .Linux { x :: x_b }

x.do_thing()

I believe most of this is language designers picking their personal preference and then that percolating down through history.

The original UNIX folks really love lowercase. Executables are lowercase, most file names are lowercase, file extensions are, etc. That extends to C where DMR and Ken Thompson chose lowercase names for keywords, built-in types, and standard library functions. If I remember right, Thompson uses all lowercase in most of his communications too, so I suspect it comes from him. Or maybe it was a flex because the PDP-11 could do lowercase when some other early computers didn't support it at all?

The early Pascal compilers from Niklaus Wirth and friends appear to be all caps, probably because that's all the machines supported. The language itself generally isn't case sensitive. (I say "generally" because there are many flavors of Pascal.)

When Anders Hejlsberg created Turbo Pascal (which is also case-insensitve), he introduced a convention of lowercase for keywords what we now call PascalCase for function and type names and (judging by the Wikipedia article) a mixture of PascalCase and camelCase for variables.

Perhaps because Straustrup built on C but is a Dane like Hejlsberg, he picked a mix for C++: camelCase function and variable names with PascalCase type names.

These conventions then flowed down through time. Java was heavily inspired by C++ and takes the same convention. C# is another Hejlsberg creation and follows his preferences. JavaScript follows Java. (It must annoy Hejlsberg to no end that his third baby TypeScript breaks with his own convention.)

In this case, I believe the capitalization is a hold-over from raylib's c library, Odin doesn't appear to put any preference?

In Go it has a specific meaning: starting an identifier with a capital causes it to be exported for use in other packages. Identifiers with a starting lowercase char are package private.

Apologies if this is explaining what you already know...

Odin itself does not care what naming conventions you use. Use whatever you prefer.

For Odin native libraries, we usually for the convention of `snake_case` for variables and procedures and `Ada_Case` for types. However for anything that is third-party/foreign, we try to keep to the same convention as the original library to make it easier to people reference the original documentation, as well as not have any of the problems that certain naming conventions cannot be translated to another. So the raylib code uses the original raylib naming conventions because of the reasons I described.

That's a method from Raylib, a C library which has Odin bindings. For all libraries, Odin follows the original library's style.

The Odin convention is Pascal case (lower_case_procedures, Capitalized_Enums_And_Structs).

snake_case is just more readable overall. PascalCase and/or camelCase are okay in moderation and add a kind of emphasis, which is why e.g. Rust uses PascalCase for types (other than core built-in ones) and enum case constructors. SCREAMING_SNAKE_CASE is ok for even rarer things that should stand out - C/C++ uses it for preprocessor macros, Rust for program constants and global variables. Ada_Case is rare and mostly shows up in languages with case-insensitive identifiers, like Ada itself.

To point out something that is a fail: I don't want to hear about how you simulated 10M particles on the GPU without acceleration forces.

Walter Bright, the creator of D, is an active commenter here.

https://news.ycombinator.com/user?id=WalterBright

Zig is also worth mentioning, and pops up frequently.

I always thought it was more akin to a C++ than a C alternative, and reading https://en.wikipedia.org/wiki/D_(programming_language) seems to rather confirm this notion:

  "originated as a re-engineering of C++"
  "influenced by Java, Python, Ruby, C#, and Eiffel"
  "design by contract, ranges, built-in container iteration concepts, and type inference"
  "array slicing, nested functions and lazy evaluation."
  "Java-style single inheritance with interfaces and mixins"
  "function overloading and operator overloading"
  "supports five main programming paradigms" (including OOP)
  ... et cetera

D was never a C alternative, it was a C++ alternative.