D was never a C alternative, it was a C++ alternative.
back
5 comments
^ 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.
Yeah, I have used Odin before, I am thinking of giving C3 a try as well.
At a quick glance though:
> Enum support various reflection properties: .values returns an array with all enums. .len or .elements returns the number of enum values, .inner returns the storage type. .names returns an array with the names of all enums. .associated returns an array of the typeids of the associated values for the enum.
I do not like that the length is named ".elements" instead of just ".len". And why are there two ways, or are they not the same? Etc.
FWIW I have spent the weekend testing out C-replacement languages and their interop (linking to libsdl3 and libtcl) with D, Go, Rust, Odin and C3. My quick impressions:
- D is featureful, but too much so. It feels an unfocused kitchen sink worse than C++. Overall the actual dev experience was nice.
- Go I know pretty well, but saddened that CGo is very slow, so I cannot consider it truly a C replacement
- Rust I also know decently well, but writing types and lifetimes isn’t my idea of fun. I’d rather have less safety when playing with code, I’m not always writing mission critical apps. Overall walks the fine line between excellent and unergonomic; pulls half a gig of dependencies just to include SDL3 which is pure madness.
- Odin I have played with before, excellent for the gamedev world, but some features seems like they have been added just because the author liked them. Having to explicitly set up the context variable in cdecl callbacks feels bad. I dislike the whole context thing actually, because it is rigid though convenient.
- C3: documentation is bad but feels the closest to a better C. Still in the breaking phase, I sent a PR this morning to adapt the SDL3 library to the latest release. Has macros which I haven’t tested but it’s a big plus. Some syntax makes no sense, like block labels and generic in {braces} but it’s the one I will keep playing with for this project. No one seems to use or know about it, which doesn’t bode well for its future.
- Zig I haven’t used this weekend, I loathe that unused variables are errors and it is very verbose. Docs and stdlib are way undercooked. comptime is a brilliant idea. Could be decent past 1.0 release.
- Jai: I’d love to try it, if I had access to the beta.
A lot of paper cuts and small issues, nothing is really worthy of being called a C replacement, but I do not want to write another header file again so these will make do for now.
Thanks for sharing! I think there is hope for C3, if they do not mind breaking backwards compatibility, which I hope they do not, for now!
We have similar experiences I would say. I do like Go a lot, but I rarely had to touch CGo though. The language does not get in the way of being productive. Rust seems like it does.
I would give Jai a try, too!
Have you tried Zig, or perhaps even Nim? Curious about your thoughts.
Added my comments about Zig.
Nim I played a bit with, I don’t really like the syntax but I admit I need to dive deeper. My other issue is that it is so different syntax wise to C, and sometimes so high-level, it’s hard to tell what construct is efficient, and what allocates and takes 500 instructions to run. This is pretty crucial for a low level system language.
Oh `.elements` would you believe that this is a remnant of C2's builtin function `elemsof`? Its used so rarely (I think two uses in the entire stdlib), so it hasn't come up. I opened an issue for it: https://github.com/c3lang/c3c/issues/2130
This is a good example of the sharp edges I hope to smoothen out in 0.7-0.9.
Doesn't having a whole subset of the language called "Better C" qualify?
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
> That D exposes a curated subset of D doesn’t make it a C alternative,
But why? You comment does not clarify what does this subset lack which prevents it being used as a C alternative. The intention is explicitly stated and the "spirit" argument is weak as overly subjective.
It has been a while since I dived into the land of Dlang.
To me, and originally, Dlang was a C++ replacement. However, C and C++ can still be rather mixed despite them being "two different languages"
In my words, BetterC is a tool to help you transition a C programming project to a Dlang one. Turn on the BetterC flag and the transition is quite mild. The goal is to slowly migrate your (now) D code into "proper" D. Then, you can turn off the BetterC flag.
That.. to me.. is the original goal of BetterC. However, I noticed that BetterC has become rather popular in the D community to simply write programs with the GC disabled. There is a slight divide/debate in the community of what D should be.
I remember trying the full features of D and slowly moving to coding in BetterC to.. eventually.. moving away to another language.
Why?
As much as like Dlang - it tries to be everything. By default it is an OOP, GC language. However, it has functional support, BetterC, as well as (dip1000) Borrow Checker, and others. In the end you end up with programs written in D in various ways. Imagine when using the package manager. You can search for packages.. but how are they implemented? Is it using the GC? Will it work on the latest version o D? So many questions. You end up looking at the code yourself to determine if the library is going to do what you want.
I am not sure if D is a "C++ replacement" today. It tries to compete with orther, modern languages like Rust or Go and others would prefer it to be a C# or Java competitor.
This is why I like Odin. It makes it very clear what it is and isn't. Sure this means that Odin in various ways will have less features than D but atleast I know the code is simpler, and when taking on other Odin projects I know it still follows the same format.
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.
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.
> "Better-C" still has things many C-programmers wouldn't particularly like
I'd say a couple, not many.
> RAII
Who wouldn't like RAII?
> Metaprogramming
As a way to avoid preprocessor macros? Yes please.
> Nested functions
Already offered as extension.
> Member functions
I'm sure no C programmer would object to that.
> constructors, destructors
This yes. Agreed.
> operating overloading
Instead of _Generic()? Why not?
I wouldn't like RAII, and why I didn't add it to Odin. It's not a feature C programmers want. And you've just agreed that C don't want ctors/dtors, which is necessary for RAII to work... ctors/dtors are bad for their own reasons (mainly because you cannot handle error cases except through exceptions, which many people disable too).
Do you realize that D has betterC and now it also supports C compilation natively? [1] [2]
[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):
Yes, I am quite aware. But it doesn’t make D any less a C++ alternative.
Safe to say that D is both C and C++ alternative, never say never.
If you aim to be both a C alternative and C++ alternative, in reality you are just a C++ alternative because you haven't understood why people prefer C over C++. Therefore D is a C++ alternative and that's what it was always trying to be, even with "BetterC".
Only if they aren't using anything beyond C99, because after that C is basically turning into C++ without Classes.
Most C programmers I know pretty much do that. I use C11 just for the atomics and that is it. And I know many C programmers who still use C89/C90 exclusively.
Well yeah, I use C99. I would never use newer C, it is too C++-esque. You can actually use some stuff from stdatomic.h with -std=c99 -D_XOPEN_SOURCE=700, such as "atomic_bool" and whatnot.
Depends on the point of view, especially those of us that think there is no reason for C other than legacy code, since C++ exists.
By the way, code that I wrote yesterday is legacy.
It certainly is, also known as D as C or Das C.