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.
> 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/.
taylorallred · 8h ago
Odin really hits the sweet spot for everything you would want from a language for the game dev and game-dev-adjacent space in terms of simplicity, convenience, and speed. I think a major design decision of the language that will make or break it for users is the fact that the language gives you common features instead of giving you the means of abstraction to make those features yourself. For example, instead of preprocessor macros you get the `when` clause for conditional compilation because in Bill's estimation, that's one of the only real needs for macros. The same goes for data structures. Odin gives you the certified classics like dynamic arrays and maps but doesn't give you a whole lot to make your own custom data structures (it's possible, just not encouraged by the language design). All in all, I think if you want to make an application with a language that has batteries included and you don't need a lot more than that, Odin is nearly flawless.
johnnyjeans · 6h ago
> 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.
vandyswa · 8h ago
FWIW, another take on "C Alternative" is the D programming language:
Zig is also worth mentioning, and pops up frequently.
sdsd · 5h ago
Once, on a previous account, he actually replied to me. It's like a kid going to guitar center and the guy who replaces your strings is Axl Rose.
If you're on here, Walter, you're my hero. I also once interacted with Brendan Eich, who I admire as much for his role in web history as for his activism.
"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
Though it does support things like in-line assembly and the like, I'm sure most C programmers would pass on it, as a C-alternative, based on those factoids.
lerno · 5h ago
D was never a C alternative, it was a C++ alternative.
bsrkf · 5h ago
^ and this person (no affiliation) has a much "truer" C alternative in the making, just for everyone's information: https://c3-lang.org/
Haven't gotten around to trying it out, but skimmed the documents a lot at one point. Always try to keep tabs on it, doesn't get the love it should.
ZoomZoomZoom · 4h ago
Doesn't having a whole subset of the language called "Better C" qualify?
lerno · 3h ago
It was introduced in 2017, and not part of the original direction of D (it’s neither in 1.0 nor the 2.0 revision of the language)
That D exposes a curated subset of D doesn’t make it a C alternative, even though the ”betterC” aims to target people looking for a C alternative
bsrkf · 4h ago
C is liked particularly, even considering all its shortcomings, for being a relatively limited language in scope, being raw but flexible.
D's scope seems to go far beyond what your average C programmer would want in a language; "use only 15% of the language and you'll be fine" (paraphrasing: "use only the 'better-C' subset", if that is what you meant, and it does seem to be a subset of D) seems a weird proposition; it still complicates things, as in collaboration, idiomatic feel and look of code, the amount of knowledge required to be competent in the language, complexity of a compiler implementation, portability of code etc... and by that logic you'd have to prefer C++ over C as well (since a lot of C is valid C++), or prefer C plus one safety feature added over C; but the "rawness"/limited scope/small size/procedural nature of C is what's appealing for many to begin with.
I for one think that a proper C replacement (C's strength also being the simplicity in which to implement a compiler for example, being the reason it's so ubiquitous in the embedded world) will be a much more limited proposition than D is.
RAII
Full metaprogramming
Nested functions, nested structs, delegates and lambdas
Member functions, constructors, destructors, operating overloading, etc.
...
Where to draw the line will be different person to person, but D doesn't seem to be a language "in the spirit of C", or a "modern version of it", at all.
Viewing it as a C++ alternative makes much more sense. A `Better-C` "limit yourself to a subset of the language" compiler flag doesn't change that much.
teleforce · 4h ago
Do you realize that D has betterC and now it also supports C compilation natively? [1] [2]
Yes, I am quite aware. But it doesn’t make D any less a C++ alternative.
teleforce · 3h ago
Safe to say that D is both C and C++ alternative, never say never.
pbohun · 9h ago
I've started experimenting with Odin for some personal projects and it's been great. The built-in vendored libraries make creating certain programs trivial. For example, just `import rl "vendor:raylib"` and you can use `rl.InitWindow(800,600,"Test")`. No need to install Raylib, add to path or use special linker directives, just `odin build .`!
Also I think Odin struck the right balance of features while trying to keep to the spirit of C.
thegeekpirate · 2h ago
When I first saw Odin, I wrote down a list of everything I didn't think I'd like.
After several thousand lines, it proved all of my major worries incorrect, and has been an absolute pleasure.
It has since replaced my usage of Go, which I had been using since release.
I would highly recommend giving it a proper shot!
ultrarunner · 7h ago
As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being capitalized, while their instances are often lowercase. This communicates a subtle "feel" for the language, meta information about what's being accomplished.
Capitalizing method calls (`rl.InitWindow()`) seems to place the importance on the Method being called, but at first glance (ASP, or Go off the top of my head) it muddies the waters. If this isn't clear, consider that capitalizing ALL code would reduce clarity as all letter shapes are now essentially the same (a box).
I spend most of my time in c, c++, ruby, and javascript, but maybe I should try to do a personal project in Go (or Odin) for this reason alone.
munificent · 7h ago
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.)
xemoka · 7h ago
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...
deadwanderer · 2h ago
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).
Dwedit · 1h ago
How does this compare with Zig or Beef?
leelou2 · 7h ago
Odin seems to strike a really interesting balance between simplicity and practicality, especially for game development. I like the idea of having “batteries included” without too much abstraction getting in the way. For those who have used both Odin and Go, how do you feel about the differences in day-to-day development? Are there any features in Odin that you wish Go had, or vice versa? Would love to hear more real-world experiences!
dismalaf · 6h ago
I mean, the biggest difference is that Go has a GC and Odin doesn't. And each's ecosystem reflects that... In practice they're simply not used for the same types of software.
throwawaymaths · 8h ago
> This is the polar opposite of Zig’s embracing of metaprogramming for as much as possible.
I found this claim a bit strange. do people actually use metaprogramming in Zig a lot?
jamiejquinn · 8h ago
IMO it's one of Zig's advantages over C (text substitution macros are both too powerful and not powerful enough). If you're using Zig without metaprogramming, you're leaving a useful (if advanced) tool on the table.
johnnyjeans · 7h ago
C's preprocessor not being powerful enough is less a problem with text-substitution macros, more that they're not allowed to expand recursively which was an intentional design choice. There are some hacks you can do to get around it, and people have done cool things[1] within the limited space those hacks grant you, but there's a reason many C projects with extensive metaprogramming just use an external macro language (which is also just text-substitution).
IMO AST Macros are an even bigger problem than text substitution. Debugging metaprogramming of any kind past a certain point of complexity is a royal pain in the ass (even in a Lisp, Forth or Prolog), but AST explorers are next to useless for complicated logic problems that involve needle in a haystack searches of side effects. If you're dealing with a large AoS of heterogeneous SoAs which influence each other to shuffle around, and most of the related code and the structures themselves are generated via AST macros, you better be really comfortable with assembly analysis and debugger scripting.
Debugging complex Lisp metaprogramming is a piece of cake in the overall debugging landscape.
- It is not distributed across machines. No distributed fault tolerance issues.
- It doesn't run on a resource constrained embedded system, with poor visibility, but in your dev environment.
- It runs in a single thread; no flaky race conditions or deadlocks to debug.
- Its expansion-time performance rarely matters; and it is rarely bogged down with machine dependencies or other low-level stuff.
- It is unit-testable with cases does construct X expanding to construct Y.
I would rather debug a macro than any number of other things I've also debugged.
lerno · 5h ago
Isn't all sorts of stuff metaprogramming in Zig? Generic types, vtable interfaces, printf. All use comptime to generate code.
throwawaymaths · 55m ago
i think "using comptime" as a definition of metaprogramming is not really accurate... for example, i think calling this metaprogramming is really stretching it:
var x: [sqrt(LENGTH)]f32 = undefined
i think calling "instantiating a generic type" meta-programming is weak, since you're not doing any of the metaprogramming yourself, though i would concede that if debugging is the concern there is a point there.
same goes for "using std.debug.print"
Cieric · 8h ago
I can't comment about everyone, but I use it a lot for building libraries and such. I just recently built a database ORM, but since their metaprogramming is used for their generics I've run across it a lot just for those case.
kristoff_it · 7h ago
Depends on the project, the general recommendation is to use metaprogramming like salt: just a pinch to add some flavor. Newcomers sometimes go bonkers with it though.
gitroom · 6h ago
been playing around with odin and honestly the ease of getting started feels way better for me than most c-like stuff ever has. you ever think these smaller pain points keep more folks from switching than big technical features?
mcbrit · 8h ago
I am currently limiting myself to 500 lines of (particle engine) code while listening to visual artists talking about their workflow in UE5 or Houdini, and Odin+Raylib are lovely to work in.
GingerBill has shouted out Go, but Odin doesn't particularly feel like a Go flavo(u)r.
mcbrit · 8h ago
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.
mistrial9 · 42m ago
re Odin -- I do not like reusing important names in this way. Can I be the only one?
WhereIsTheTruth · 10h ago
I like odin a lot, however, there are two things that just don't stick with me, and i ended up quitting:
- RTTI: just give me compile time type introspection and let me disable RTTI without making the language unusable
- when/import: just let me wrap an import inside a when block, being forced to split my file in 3 made me quit the language
rwbt · 5h ago
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.
James_K · 8h ago
A C alternative means a language that will last for 50 years, whereas this seems more like "whatever's popular by way of LLVM". I can see some real smart stuff coming out of languages like Zig and Rust, where Odin seems just to follow along.
bsrkf · 6h ago
Seems needlessly harsh and also misplaced in some way. Zig is super non-ergonomic to any C-developer, and its explicitness at all costs is also non-C-like (meaning a rather big shift for someone actually liking C). Rust is a completely different beast altogether.
Odin is a rather simple, performant, pragmatic, procedural language, fixing especially things in C with regards to its type system and infrastructure (such as packages), adding niceties such as `defer` while being at it. I, as a C programmer, have it far higher up my list of languages to try than Zig or Rust by a rather large margin.
btw: "C alternative means a language that will last for 50 years" seems a snide that could be applied to any language less than 20 years old? I'm not sure what that's concretely meant to criticize here? Is Zig more a 50-year language than Odin, if so how? Odin is used for rather serious commercial products at JangaFX btw: https://jangafx.com/ and is quite beloved by some people using it.
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/
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/.
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.
https://wiki.dlang.org/Tutorials
Comparatively mature, there's even a freeware book which is quite good:
http://www.ddili.org/ders/d.en/index.html
https://news.ycombinator.com/user?id=WalterBright
Zig is also worth mentioning, and pops up frequently.
If you're on here, Walter, you're my hero. I also once interacted with Brendan Eich, who I admire as much for his role in web history as for his activism.
Haven't gotten around to trying it out, but skimmed the documents a lot at one point. Always try to keep tabs on it, doesn't get the love it should.
That D exposes a curated subset of D doesn’t make it a C alternative, even though the ”betterC” aims to target people looking for a C alternative
D's scope seems to go far beyond what your average C programmer would want in a language; "use only 15% of the language and you'll be fine" (paraphrasing: "use only the 'better-C' subset", if that is what you meant, and it does seem to be a subset of D) seems a weird proposition; it still complicates things, as in collaboration, idiomatic feel and look of code, the amount of knowledge required to be competent in the language, complexity of a compiler implementation, portability of code etc... and by that logic you'd have to prefer C++ over C as well (since a lot of C is valid C++), or prefer C plus one safety feature added over C; but the "rawness"/limited scope/small size/procedural nature of C is what's appealing for many to begin with.
I for one think that a proper C replacement (C's strength also being the simplicity in which to implement a compiler for example, being the reason it's so ubiquitous in the embedded world) will be a much more limited proposition than D is.
Edit: And having been curious, even "Better-C" still has things many C-programmers wouldn't particularly like. Going by things listed here https://en.wikipedia.org/wiki/D_(programming_language)
Where to draw the line will be different person to person, but D doesn't seem to be a language "in the spirit of C", or a "modern version of it", at all.Viewing it as a C++ alternative makes much more sense. A `Better-C` "limit yourself to a subset of the language" compiler flag doesn't change that much.
[1] D as a C Replacement (187 comments):
https://news.ycombinator.com/item?id=20323114
[2] Adding ANSI C11 C compiler to D so it can import and compile C files directly (105 comments):
https://news.ycombinator.com/item?id=27102584
Also I think Odin struck the right balance of features while trying to keep to the spirit of C.
After several thousand lines, it proved all of my major worries incorrect, and has been an absolute pleasure.
It has since replaced my usage of Go, which I had been using since release.
I would highly recommend giving it a proper shot!
Capitalizing method calls (`rl.InitWindow()`) seems to place the importance on the Method being called, but at first glance (ASP, or Go off the top of my head) it muddies the waters. If this isn't clear, consider that capitalizing ALL code would reduce clarity as all letter shapes are now essentially the same (a box).
I spend most of my time in c, c++, ruby, and javascript, but maybe I should try to do a personal project in Go (or Odin) for this reason alone.
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 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...
The Odin convention is Pascal case (lower_case_procedures, Capitalized_Enums_And_Structs).
I found this claim a bit strange. do people actually use metaprogramming in Zig a lot?
IMO AST Macros are an even bigger problem than text substitution. Debugging metaprogramming of any kind past a certain point of complexity is a royal pain in the ass (even in a Lisp, Forth or Prolog), but AST explorers are next to useless for complicated logic problems that involve needle in a haystack searches of side effects. If you're dealing with a large AoS of heterogeneous SoAs which influence each other to shuffle around, and most of the related code and the structures themselves are generated via AST macros, you better be really comfortable with assembly analysis and debugger scripting.
[1] - https://github.com/Hirrolot/datatype99
- It is not distributed across machines. No distributed fault tolerance issues.
- It doesn't run on a resource constrained embedded system, with poor visibility, but in your dev environment.
- It runs in a single thread; no flaky race conditions or deadlocks to debug.
- Its expansion-time performance rarely matters; and it is rarely bogged down with machine dependencies or other low-level stuff.
- It is unit-testable with cases does construct X expanding to construct Y.
I would rather debug a macro than any number of other things I've also debugged.
same goes for "using std.debug.print"
GingerBill has shouted out Go, but Odin doesn't particularly feel like a Go flavo(u)r.
- RTTI: just give me compile time type introspection and let me disable RTTI without making the language unusable
- when/import: just let me wrap an import inside a when block, being forced to split my file in 3 made me quit the language
Odin is a rather simple, performant, pragmatic, procedural language, fixing especially things in C with regards to its type system and infrastructure (such as packages), adding niceties such as `defer` while being at it. I, as a C programmer, have it far higher up my list of languages to try than Zig or Rust by a rather large margin.
btw: "C alternative means a language that will last for 50 years" seems a snide that could be applied to any language less than 20 years old? I'm not sure what that's concretely meant to criticize here? Is Zig more a 50-year language than Odin, if so how? Odin is used for rather serious commercial products at JangaFX btw: https://jangafx.com/ and is quite beloved by some people using it.