- More powerful metaprogramming capabilities.
- Better module and library system.
- Nicer syntax.
The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language.
Furthermore, many of the other downsides of C++ are still present:
- The complexity of the language, and then the sheer number of different ways of doing the same thing.
- Some pretty dark corners in the way stdlib/language feature were implemented that seemed hard to ever fix.
- The way behaviour is specified in the language is very tied to the underlying hardware: rather than explicitly describing behaviour in terms of an abstract machine, it works more in the way C++ is specified where we all know it operates on an abstract machine thanks to compiler optimizations, but the spec likes to pretend it doesn't...
And then there are problems that are introduced by D, such as the fact that a safe subset exists, but depends on GC, so there's a weird split where no "safe code" can be used in contexts where GC is unsuitable.
Contrast this to Rust, where:
- There is a true step-change in bringing safe code to all contexts, not just those where GC can be used.
- It's missing a lot of the complexity of C++. Rust is hard because it has concepts that are foreign to a lot of programmers, but the total number of features is low (compared to C++) so there are fewer surprising ways they can interact.
- Rust is a suitable replacement for C, not just C++, because it's not just adding more features.
Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway.
And I really question what these situations are where you can't have garbage collection in 2021. Hard real time systems, sure, but that's not what 99% of people are using rust for. Maybe people just like the challenge.
Game development, anything with a UI (GC pauses frustrate users), anything that needs high performance (scientific applications, data analysis), you name it. Ownership semantics have a side-benefit of automatic thread safety; something that is less important than memory safety (because many programs can work in one thread but almost no programs can work without allocation) but extremely valuable when needed.
C# Unity, Lua Love 2D,...
>anything with a UI (GC pauses frustrate users)
Millions of C#, Java, Python, Javascript UI apps
>anything that needs high performance (scientific applications, data analysis)
Numpy, Julia,...
Using non garbage collected languages for 99% of apps today is a waste of time, and i'm saying this as mostly an embedded developer.
Your argument also doesn't apply to GUI apps, anyway. C# and Java amount to a huge number of such apps, and they're self-hosted.
GC languages are vastly more productive that manual-memory languages, and for the vast majority of users, that is worth the performance hit.
Most projects are better off written in a GC language because the productivity benefits outweigh the performance costs.
My anecdotal, unscientific experience shows that GC is a double-edged sword that maybe makes writing simple programs slightly faster, at the expense of a much worse maintainability once the code base gets big. And non-memory resource management in GCed languages without RAII is a really huge PITA that kills all productivity gains.
GC allowed memory safety until Rust happened, and that was a big gain, but now that point is moot.
https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScrip...
Or you prefer anything written in DirectX or Metal?
Chapter 5 from The Garbage Collection Handbook.
C# allows for GC free regions with GC.TryStartNoGCRegion, manual memory management via MarshalServices, stackalloc, Span<>() and value types.
Almost forgot Unreal C++ is GC based for entities and anything Blueprint related.
https://docs.microsoft.com/en-us/windows/uwp/audio-video-cam...
https://www.embedded.com/spark-2014-why-i-am-backing-a-predi...
EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development
GNAT Aux could use some help too:
https://github.com/viperproject/prusti-dev
https://www.pm.inf.ethz.ch/research/prusti.html
extern crate prusti_contracts;
use prusti_contracts::*;
#[requires(something)]
#[ensures(result >= a && result >= b)]
#[ensures(result == a || result == b)]
fn max(a: i32, b: i32) -> i32 {
if a > b {
a
} else {
b
}
}
@safe works perfectly fine and exactly the same in @nogc code as in GC-enabled code.
https://dlang.org/articles/safed.html#safed-subset
> When you enter SafeD, you leave your pointers, unchecked casts and unions at the door. Memory management is provided to you courtesy of Garbage Collection.
Does D provide the necessary tooling to be able to expose a safe API for something which needs to allocate memory, without needing a GC?
Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.
I'm aware that D has @live, a WIP attribute that mimics Rust semantics, but it's not remotely ready for production.
Those same reasons would apply for choosing C over D. They might not apply for choosing C over Rust.
Also anything i want to be very fast on limited hardware i also use C and C only.
As for any hobby programming i do on the side, C is usually my goto choice, unless i want to be very esoteric.. following along the lines of: "The enemy of art is the absence of limitations."
I've been doing it so long I could write macros in my sleep, and inline asm is a fun little exercise.
Though i absolutely agree, especially with someone newer, that could be a major road block. Might want to learn D just to be more efficient (even though I will never abandon my first love completely)
Also C++ compilers are hard too. And optimizing C compilers are hard too...
CPU fabs aren't easy, yet we're fine with that.
Also: Marketing, a lot decisions are made based on nothing, we're too modest (to be blunt).
Over time, this proved to be a bad strategy, C++ key strength became RAII (deterministic memory management), so the GC became a failed strategy
The maintainers tried to move in different directions, adding manually memory management, making the GC optional, moved D to be a C replacement, with the -betterc compiling option, and many other tweaks and features added overtime, but nothing really caught on
D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1.
BetterC is a nice-to-have rather than a language dialect.
Having a GC is an absolute godsend for getting clean code out of the door quickly.
You cant replace C++ with GC language, even 10 years ago this should have been evident to a seasoned developers such as Walter Bright and Andrei Alexandrescu
Sometimes great developers are bad product managers
Anyway, with Rust and Go, D have no where to go, I don't think it should be fixed to appeal to a wider user base, the only good strategic move they can do today, it make it better for the current user base, they have few big users, they should focus on them and the language will fade once those users move on to something else
Also, if you think existing D users are going to replace D with Go I don't know what to say to you. Go and Rust are literally punchlines without a need for a joke in discussions I've had with many senior people at these companies (Mostly Go). The reasons why people use D are so utterly detached from everything that has been discussed in this thread that I don't know what to say to you. Go is a bad programming language, pure and simple, good ecosystem, awful language.
"Lockheed Martin reviewed various options for the Aegis Open Architecture including the programming language and execution environment for the system. In their experiments, they found that HotSpot Java code ran comparable to C++ on an experimental 250 millisecond periodic workload. At the same time, they found that the Java language provided superior abstraction and encapsulation than C++, and they judged that retraining their existing staff of CMS-2 programmers to become effective in Java would have lower risks than attempting to train them in C++."
https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...
So there you have it, Java powering battleship weapons targeting systems, after replacing C++.
Java is one of the top 3-5 most popular languages, and have huge backing
So its understandable that people found a way to make it fast, and honeslty, i dont really know how much effort does this require, but it seems from your example, it less than what C++ need
This all in all, seem counter intuitive, if Java is really as fast as C++, why is it that mainstream knowledge suggest otherwise
Either, your example is hiding something, or there is other reasons people still use C++ when they need high performance
D was meant to replace C++ not be a fast Java like language, I would argue, it achieved neither
D wanted to be a mainstream language, this is why the adopted the C/C++/Java style of programming, and again they didnt achieve this objective
D is not instinct, it still have a small dedicate user base, I just wholeheartedly think, today, you have far better options: Rust, Go, OCaml , C# , Kotlin
Not everyone is doing Websites or Android apps.
PTC isn't using Hotspot, rather their own JVM implementation.
Just like C++, Java enjoys multiple implementations.
Just like C++, the best ones for embedded deployment with soft real time capabilities, are commercial, directly supported by hardware vendors.
D's biggest failure so far is not having a Google or Apple behind it, that would push the language no matter what naysayers have to say against the language.
Just like on iOS and Android, wanna play? Here are the allowed list of toys.
Andrei is a big deal i would say
Since then FB moved on the build their own Ocaml based language reasonml
Julia doesn't have a big company behind, yet the language is steadily climbing the popularity ladder (and i doubt they have anyone at the calibre of Andrei Alexandrescu, but again, good pogrammer is not a good program manager)
D is not popular, because its leader failed at making it popular, they failed to give the qualities that would make it popular
Facebook never really adopted D beyond a C++ preprocessor written in D.
And yes the community is rather lousy with language marketing, which is completely unrelated to technical achievements.
Why are you refusing to blame the product owner
D is not a good language, it really is not, it doesn't offer any compelling advantage to justify accepting its flaw
Or simply put, its a bad product A bad product doesnt have to be trash, just enough bad design issue to make it bad I would strongly recommend new developers not to touch it there are far better option
Say it as it is, its simple, its the truth
Its functional, people use it, but its bad C++ is also bad, but its so overwhelmingly popular that you might want to learn it D is bad, and is unpopular
Cannot comprehend your logic here, one of the Java objectives was also to replace C++. It kind of achieved the objective by consistently being top 3 languages since its introduction and it achieved that by not even natively compiled, unlike D. Based on Java story, it seems that having no GC is not a required condition for success. I'd had imagined if Java is not being invented the entire Android eco-system (the world's most popular operating system) will be written in C++.
>D wanted to be a mainstream language, this is why the adopted the C/C++/Java style of programming, and again they didnt achieve this objective
Not sure what is your point here since almost every programming languages wanted to be a mainstream language including Ruby, regardless whether the author admit it or not.
>D is not instinct, it still have a small dedicate user base, I just wholeheartedly think, today, you have far better options: Rust, Go, OCaml , C# , Kotlin
I think you meant 'extinct'. Time will eventually tell and no need to be so negative. When Python was 20 years old (about the same age as D today), it literally was playing a 2nd or 3rd fiddle to PHP, TCL, Perl, R, Ruby and Matlab in their respective domains, and look where is Python now? I believe even Guido did not have predicted the astronomical rise of Python at the time.
D's main objective is to be useful. I did some hobby C++ that I replaced with D, but my main D migration was actually from PHP.
Another anecdote - Someone who hires people in D has told me definitely that D being small means that hiring for them is usually just seeing some code, i.e. there hasn't been an eternal September let's say. They can onboard people who don't know the language, but knowing D is a very good cultural (programming is easy!) filter.
Lots of stuff exist specifically to help with onboarding people into the community. Like the recent announcement of adding a C parser into the frontend.
If you want to go the noGC route, you have to refrain from using certain language constructs, which puts you in a similar spot as with C++...
And if you actually want a GC, you might find the simple linear allocator of D to be lacking...
D is a very cool language, but it is also a lot like QTified C++... Which, well, already exists...
A whole two features:
1. concatenating strings using the ~ operator. You can concatenate strings using malloc if you prefer.
2. closures that escape the context of the function they enclose. Instead, write a struct with fields representing the values, and make the lambda a member function of that struct. Allocate the struct instance any way you wish.
The GC is a convenient feature with lots of nice uses. Programming in D is not impaired by not using it.
It's a short list, for sure, but thats not the point: Anyone looking into using D without GC will see that there are some language features that require special care.
At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.
GC free D is low friction, but seemingly not low enough for uptake from interested parties.
Yes. Walter was referring to the operator itself. Strings are arrays.
> as well as exceptions
It's not exceptions themselves, but the `new` operator. It directly allocates from the GC. That said, there is a plan to enable @nogc exceptions.
> At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.
People who already know another language and are happy with it have no reason to switch. Why would they? It's people who aren't completely satisfied with a given language that are going to be more open to looking at others. And so of course then it's a matter of weighing pros and cons. Do I like the syntax? Does it feel intuitive? Am I comfortable using it? Do I find the pain points blockers or minor annoyances?
There is nothing special about D in this regard. If you aren't looking for a new language, you aren't going to try it. And if you are, you either like it or you don't.
WekaIO wrote the world's fastest filesystem in D. They did it without the GC, and went so far as to write their own GC_free standard library (which they open sourced). Their CEO talked about why in this interview:
https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...
That said "GC-free D" is not a major selling point of the language. You will not find the maintainers recommending anyone start a D project fully GC-free unless there is a very specific use case, like that of WekaIO or the blog post author. The allocation patterns in D are different than they are in Java or C#, it's clearly defined when a collection may trigger, the @nogc attribute provides compiler enforcement for avoiding GC allocations in specific functions, a command-line switch can warn you about the same if you find @nogc too much to think about (because employing @nogc does require more consideration of your architecture), and other switches can help minimize the impact of GC.
So the tools are there for anyone who needs them. There are definitely rough edges and we are forever in need of improvement, but everything is usable and people are using D in production right now.
It's been implemented.
Exists as a preview switch
Apart from that, they came pretty late, are still in experimental, and don't change the fact that only a subset of D is usable without GC.
I very much like D, I really do, but I never encountered a usecase where the pros of using D outweight the cons. It sits in a very very weird spot design-wise, and while Walter and Andrei tried their best to get rid of the most common problems, not much of that effort resulted in actual useful change: Still no other GC than the default linear one, the stdlib is still not fully noGC usable (and probably never will), and "proper" compile time functions are still not done, after quite a few years now...
Which is a shame, D is very close to being the perfect C++ replacement.
I have no idea what you mean by "proper" compile time functions. D's CTFE is excellent.
This viewpoint is typically represented by the question "what can I do in X that I can't in C++?".
Something I personally find interesting is the thought experiment: if Golang was written by a small actor, and D by a big one, which one would have succeeded?
(The third essential is that a language do something significantly better or easier than existing languages. A language can't just be "does the same as C, but with a bit different syntax", unless it's radically better syntax. Switching languages has a cost; your new language has to pay back that investment or it won't get used.)
In a way I think it is a kind of revenge that most newer languages adopt Pascal style variable and type declarations.
The Rust community realized early that if they wanted to succeed, they had to talk about Rust a lot, show good examples, be beginner friendly to avoid people picking it up and dropping it quikly. But that "marketing" is also things like a really good package manager, really good compiler errors, a really good VSCode extensions. Many communities don't have this (especially the new ones) and this makes developing in Rust more of a joy than in let's say OCaml or even JS.
There will be a book on dlang.org soon, that's the one thing I think we're lacking at the moment.
https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/
Let's not pretend marketing is just paid Facebook/Google ads.
https://dlang.org/blog/2017/07/28/project-highlight-funkwerk...
Companies using Java or C++ don't switch because a language is "sufficiently different". I've been involved in programming language discussions for decades and I've never heard of a company switching to a language because it was different from what they were already using, though being too different is a common reason for not switching.
{For those not aware, D has intentionally kept compatibility with C as a priority, to the point that you can set a compiler flag and restrict yourself to "betterC". You can translate C code to D without making many changes to it.}
When switching is costly, the potential upside must be big. When the other language seems similar, the upside also seems limited. When there are few differences, you can rationalize staying with the old language, because it may catch up with the features, or you can emulate the missing features, or just live without them, if the differences are small.
[1] A random commenter on HN might well conclude that there's no benefit to D's templates without using them.
No major tech company behind Dlang.
Edit: Why am I being downvoted for repeating publicly available information?
I think a language technology needs at least one, but ideally a few, flag ship projects using it. It provides some examples for people to see, it shows the "why" and then it also connotes that it's living and good. I don't think it has to be big, just good. Ripgrep is a prime example, there are a few other smaller tools in Rust that are nice, well put together tools that do a nicer or better job than the old standards.
You can talk about why something is nice or better, but actually showing people that it is probably convinces more.
While this makes D a deeply pleasant language to use, it also makes it tough to sell. It doesn't have any whizz bang features you can get across in an elevator pitch.
D to my knowledge has never fully transitioned to garbage collection being a thing of the past.
For tools I think D fell into a common trap, which is to just keep working on the language itself. Eventually the lack of debugger, real time syntax checking and auto completion take their toll and something like C++ seems better even with the rough edges of the language itself.
This specific article talks about using No GC aka "betterC".
D has GC by default; the use of GC is convenient and mainstream as most popular languages show - Java/C#/Python etc. What D gives is the unique ability to do No GC programming for the cases where GC is not desirable. Very few languages offer this capability.
Zig is interesting in this arena, but it approaches the problem from the other angle. It is manual memory management by default, but you can explicitly choose which memory management technique you want to use - at compile time.
Granted, this isn't optional GC, but does D really give you that? Don't you lose the entire ecosystem and stdlib with -asBetterC? Why would I choose that over rust/zig/c++?
FWIW, I am a big fan of D.
[0] https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/...
-betterC is not the only way to avoid the GC in D, just the most extreme. The original motivation for -betterC was to ease porting C code to D. Walter has used it for that to port a good bit of his old C code over. But it's also suited for the space in which the blog author is using it, and some people just prefer it. You always have access to the existing C ecosystem, but there are people writing -betterC libraries in the D ecosystem. And as more people use it, I expect that space will grow.
1. either they don't use any library, including the standard one,
2. or the (standard) libraries must be written in both manual and managed memory management versions.
Additionally, the language must include extra syntax for memory allocation and access. This doesn't event include safety-related semantics, like Rust, which would be very hard to bolt-in (language-wise).
I hardly see any advantage in Java/C# having this functionality; Oracle is actually putting lots of effort into improving their garbage collectors. Java does actually have manual memory management (through Unsafe), although it's rudimentary; for the reason mentioned, I doubt it will ever be improved/expanded.
That's at least why I glossed over it.
Granted on Java side it required sun.misc.Unsafe, JNI or Real-Time JSR, while on C# side, a mix of structs, SafeHandle, MarshalInterop, unsafe and eventually C++/CLI.
So while not as pleasant as D, the cost to drop those eco-systems wasn't worth the cost to switch, and now 10 years later those eco-systems have doubled down on improving the experience for low level coding.
This makes it quite hard to sell D to those potential users.