Also I think Odin struck the right balance of features while trying to keep to the spirit of C.
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.
- 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.
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.
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.
GingerBill has shouted out Go, but Odin doesn't particularly feel like a Go flavo(u)r.
https://wiki.dlang.org/Tutorials
Comparatively mature, there's even a freeware book which is quite good:
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.
"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
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.
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)
RAII
Full metaprogramming
Nested functions, nested structs, delegates and lambdas
Member functions, constructors, destructors, operating overloading, etc.
...
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.
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
[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):
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.
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 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.)
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/.
WhereIsTheTruth•7h ago
- 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•2h ago