I've never given D a fair shake before, so my opinion of it is very weakly held, but up until now I've always thought of it as C++ with even more piles of crap bolted on. Reading the examples here makes me think that I was wrong and that I should give it a real try, because this looks like a sufficiently elegant language that I would actually want to use.
It is definitely related to C++ (both in ideology and in participants) and AFAIU has even more features, but, for example, Scott Meyers views it[1] as having less random stupid inconsistencies than C++.
I've had the displeasure of having to use it professionally for a little while, and to be honest, I'd sooner rub chilli flakes into my eyeballs than have to deal with D's default garbage collector again. Seemed to be a cult-like language in the worst possible sense.
Could you briefly explain the problems with D's GC? Their docs say, "Since version 2.067, The garbage collector can now be configured through the command line" - would that help in your case?
Having used I'd sooner file it under "C, with just enough added, removed, and fixed to make it a pleasant modern language", but then my native language is python so take that with a grain of salt if you're a C/C++ person.
C# and Java have a large base. If you write a small application with it the size will be huge because they both link in the base in the application. It becomes more interesting with larger applications.
C# is getting that sweet spot of how a modern version of Modula-3 should look like.
I also expect the same for Java, if Valhala ever makes it.
So even though Remedy Games had some experience with D, it is C# that gets all the attention as C++ alternative in tooling and graphics engine scripting, while everything that isn't performance critical in Android (no GC at all), gets written in Java/Kotlin.
These are two good examples of how D lost a potencial market, by always re-inventing itself for the next wave of developers that will finally get D and leave everything behind to adopt it, instead of focusing on having something to make it special for adoption.
D standard library uses much templates. So only what's used or what is not templatized get linked in the binary. The runtime somewhat tries to follows this too, aka the "pay-as-you-go" strategy as it is called in the dlang world.
For small applications this works even if certain templates can easily lead to have half of the standard library pulled in (e.g a few conversion, a few format, a few regex and boom, the size explodes).
A subset of the language called betterC allows to fully get rid of the "base", but requires to write much more code to get things done. Maybe this is why prakis managed to get the smaller binary ? The comment is not very clear about the methodology...
Given that D Go Rust etc. are all Turing complete, there's no difference on their ability to compute (perform) a function.
The only difference is how easy is, and how much cr*p you need to suffer in the process.
Yet I see here people patting themselves on the back just because they re-re-rewrote the algorithm of the day (git, computing the day of the week, etc) using all sorts of programming languages to claim they were there first.
So before anyone comments that they rewrote nginx in D, let me say that we don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
Turing-complete languages have been around for the better part of a century now, had we stopped after the first one we'd still be writing some kind of Zuse machine language. There's purpose in trying to make better languages, the goal is not to be able to compute more things (since we're fundamentally more limited by the hardware than by the software), but to compute old things more efficiently and more easily. D, Go, and Rust may all be as Turing-complete as each other, they have good ideas.
That, and the fact that Turing-completeness isn't really a useful concept in real life since we don't have infinite tapes with writing heads taped on top of them. In real life, a program will be more efficient if the language it's written in (or, specifically, the implementation/compiler of that language) is smarter, even though pretty much all languages we use today are technically Turing-complete
Taking that argument to its logical extreme, why should any time spent on any of those (possibly unsolvable) problems be done in anything other than pure machine language, since that is also Turing complete?
In other words you’re severely underestimating just how much gains in easiness and reductions in suffering can contribute towards (eventually) solving the solvable subset of those problems… never mind just how significant some of those quality of life improvements can be between existing languages (and completely ignoring the potential scope of improvements not yet found in extant languages).
What if the solution to [insert sufficiently pernicious problem here] simply cannot be expressed in a human-useable fashion in a merely Turing-complete language? Having just the ability to compute a solution doesn’t mean you have the ability to understand (much less use or build atop) a solution.
So it's over 20 years old yet nobody knows it exists. Doesn't sound very promising. The first time I heard of it was someone who uses it frequently complaining about too many breaking changes in minor updates.
So it's unknown and unreliable. Who gives a crap if it has elegant syntax, it's just another way to write the same stuff. The examples from the article can be done in JS, python, java, c# almost exactly the same way. Slightly different syntax.
I don’t think it’s fair to knock a language on rate of popularity, unless your point is community adoption.
That being said, I agree with everything else you said lol.
All the “elegance” in the article just reminded me of what you can achieve using Linq, or pythons list comprehension (which I personally don’t care for).
I used to get excited about one-liners, but if that’s what elegance is, elegance is not important to me. Are you gaining efficiency or playing code golf?
If there’s anything dev jobs have taught me it’s that readability is whats most important. You can keep your fancy lambdas etc.
Those things have their place but it’s not a crime to write a for loop with local variables.
Unless what you’re doing is as simple as a single statement, a mapping or printing something, One liner loops are not as productive or efficient. when you have multiple statements, you’re often just calling multiple loops. And don’t forget the extra time you have to spend to get the damn thing to work, as opposed to a classic for loop.
I think popularity implies usefulness to a degree, but I don't disagree that it might be unfair.
As for the functional approach to collection operations, I personally like it a lot. When I used Java, I used streams a lot, now that I primarily use C# I use LINQ a lot. I think in a lot of cases the syntax is more expressive and hence more readable than loops, but both have their place and both can be used badly.
Often times you can write a simple statement that does a lot of work and is very clear to the reader, assuming they are familiar with the API/paradigm. Equivalent loop implementations can be significantly more verbose which generally reduces readability. Other times a simple task can require a very convoluted functional approach whereas a loop implementation would be fairly straight forward.
As with everything there are pros and cons, they both have their niche but personally I think I use the functional approach more than I use loops these days.
> Yet I see here people patting themselves on the back just because they re-re-rewrote the algorithm of the day
If you cannot re-create how do you know you understand? This is one of the best ways to learn. There is zero harm here. If you don't like it you can ignore it. :)
> Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
No, we are not in an insect colony to specialize in things.
> We don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Why did we build cars when we have horses?
--------
Anyhow, it is hackernews, we do things we learn, we reinvent the wheel because we can, and we are better for it.
If I write an application I use Java as I am most comfortable with it. But it is not always the best choice. If I needed to write an application for windows with a GUI I would be more successful with C# as it would look more native. If I am writing a command line tool it would be a faster and smaller application if I build it in Go, Dart or Crystal. But then I would need to be good in it as well.
I like seeing these kinds of posts. I often script in Groovy as I am fluent in Java. I like to experiment with other languages when I have time...
Admittedly I don't know Groovy well and I'm a bit biased due to bad experiences with Gradle builds and Jenkinsfiles.
But if you're most comfortable with the JDK, Scala 3 with the Scala CLI provides an unmatched developer experience for small scripts and command line tools. And the output can be self-contained JAR, a GraalVM native image, or even a Scala Native binary if you use compatible libraries.
If you like to experiment with a language that is similar to Java is suggest you try Vala. It looks a bit like Java but has some differences and uses ref counting instead of garbage collection. It compiles to C++ (or C?) and then to native; this makes the build extremely steep and difficult but once you get that going it is really nice.
It takes to me more time, to understand what is doing D, even if theres is a previous explanation, that write down the equivalence with known tools.
The last example needs to download/install dependencies, from the outside of the upstream software origins of my servers (that's a no-no in many places). apt-cache search vibe is no good for me.
If I could have need a program like that simple web example, nowadays I could go with golang, compile and deploy.
But the first two other solutions that come to my mind...
from flask import Flask, request
app = Flask(__name__)
@app.route('/')
def hello_world():
path = request.path
return f'Hello World {path}'
if __name__ == '__main__':
app.run(host='localhost', port=8080)
I know that apt-get install libmojolicious-perl or install python3-flask is not an issue in many internal audits we did pass. Perl an Python are already present in the servers... or if puppet is in use, maybe ruby?
What I like about D is if you already know it, it can adapt to just about anything you want, from these kind of shorter "scripts" to experimenting on bare metal to regular applications.
But yeah, if you already know ruby and python and perl and awk and the unix shell, there's not much to be gained in these examples. Just if you don't know those things and know a little D, it can meet you where you are and take you where you're going.
You can say that about most general purpose compiled languages. I guess I don't see why I would use D for any particular compiled use case over something like zig or rust? and if I just want to script system tasks I'm going to use popular languages with popular libraries and full batteries like python
I think D is a victim of being too early - when it was announced the open source community was still obsessed with C, and D’s garbage collection was seen as an absolute show-stopper (even if the people knocking it largely didn’t try it). By the time Go came out a decade later I guess enough people had been bitten by C that garbage collection was an acceptable option (plus Google’s backing and a more complete standard library).
It’s too bad D didn’t get more traction, writing it really is like writing a script, and the compiler is so fast that the edit-compile-run cycle is faster than some scripting languages. Walter is still a hero of mine!
I think its probably that Go was being worked on by Google employees and the fact that GC languages were well accepted. A lot of early converts to Go were Python programmers, C++ devs didnt jump ship to anything else until Rust, I am seeing plenty of places integrating Rust with C++ code in some cases for mission critical code. I mean just look at when Discord switched from Go to Rust. They also used Rust to aide their BEAM VM code.
Yeah, this matches up more with my observations as well. Go's niche is mostly in modern deployment/infrastructure management and web backends, places that historically Python might've been the premier choice.
Rust gives you better insight and control over memory management that is necessary for many of the applications that are written in C++ while offering strictly better safety guarantees and less baggage (but the tradeoff of encoding a lot of stuff in the type system). I really like Go, Rust, and Python, but all for different things.
I always thought of D as a better C++, not a better C. But at the time D showed up, C++ still showed some promise (in that sense it is right that D might have been too early, the C++ fatique hadn't set in yet for most C++ users, so why switch to D).
I like it so much that you can just specify dependenies in the script.
That's what I hate about python scripts - as soon as you need one third party dependency, the ease of running the script just jumps out of the window and you need to create an entire project in its own dedicated directory and include install instructions for people who want to run it.
I was a big fan of D, it really felt like writing the cleanest version of C ever created. If you want similar capabilities but in a language with some legs for the future, Nim is a very good choice. Some Python or Ada familiarity will make Nim feel like home.
I gave D a honest shot a couple of years ago and used the web framework Vibe.d.
Coming from the scripting world (Ruby) D wasn’t that hard to get started with nor was the learning curve that steep.
I usually prefer to stick with the few languages I already know, but D lang was very fun to play around and build something with, it was kinda worth it because the language was interesting to explore.
The possibilities to meta-program was endless, it’s very powerful.
Something I would like to highlight is that D lang was performant out-the-box, don’t let the GC scare you. D also felt fast to read & write once you got the hang of it.
It also has some interesting concepts like “Turtles all the way down”.
I would highly suggest giving it a try, it’s really an interesting language worth exploring and I think it has matured a lot since.
To me D is the best C like language, you can use it for system needs with manual memory management, OR if you prefer the safety of a GC, you can do that as well!
If you enter the manual memory management route, there won't be many libraries at your disposal, but you can leverage the entire C/C++ ecosystem, so that's no big deal, you go manual memory management route because you want performance and control after all
I use D for my main projects, and i love it, i still try some new languages (i picked odin recently), but i always fall back to D, because of how convenient it is to switch from system to scripting language
The only areas where i want to see D progress are:
- modern language features, such as tagged union, this one definitely helps a lot when you don't want to use the GC/OOP, i liked odin because of that part
- tooling: while the LSP is great, it doesn't support all of the D language features, so i'd love to see a builtin one, like rust's and zig's team doing, that would also help ease the learning curve for new users
- an official allocator API, so people could design libraries for GC users and manual memory mangement users transparently, avoiding the fragmention of the community
D has a bright future, it is independent, has many small companies using it, and grow at a organic rate
I don't think the new languages offer enough to make D irrelevant, they are all stuck with LLVM, while D has its own mature backend! and for that reason, D stands out!
52 comments
[ 2.0 ms ] story [ 72.7 ms ] thread[1] https://www.youtube.com/watch?v=KAWA1DuvCnQ
The CPU and RAM usage of D-lang out performed all other languages.
Compiled binary size:
D-Lang : 450KB Go : 2 MB C#(.NET) : 8 MB Java-GraalVM: 9 MB
D-Lang CPU & RAM Usage is also less than GO. Unfortunately D-Lang is not popular, not many libraries available.
I also expect the same for Java, if Valhala ever makes it.
So even though Remedy Games had some experience with D, it is C# that gets all the attention as C++ alternative in tooling and graphics engine scripting, while everything that isn't performance critical in Android (no GC at all), gets written in Java/Kotlin.
These are two good examples of how D lost a potencial market, by always re-inventing itself for the next wave of developers that will finally get D and leave everything behind to adopt it, instead of focusing on having something to make it special for adoption.
For small applications this works even if certain templates can easily lead to have half of the standard library pulled in (e.g a few conversion, a few format, a few regex and boom, the size explodes).
A subset of the language called betterC allows to fully get rid of the "base", but requires to write much more code to get things done. Maybe this is why prakis managed to get the smaller binary ? The comment is not very clear about the methodology...
Java and C# are not really systems programming languages; they carry too much baggage for that.
Even Go is not too comparable to D
The only difference is how easy is, and how much cr*p you need to suffer in the process.
Yet I see here people patting themselves on the back just because they re-re-rewrote the algorithm of the day (git, computing the day of the week, etc) using all sorts of programming languages to claim they were there first.
So before anyone comments that they rewrote nginx in D, let me say that we don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
That, and the fact that Turing-completeness isn't really a useful concept in real life since we don't have infinite tapes with writing heads taped on top of them. In real life, a program will be more efficient if the language it's written in (or, specifically, the implementation/compiler of that language) is smarter, even though pretty much all languages we use today are technically Turing-complete
In other words you’re severely underestimating just how much gains in easiness and reductions in suffering can contribute towards (eventually) solving the solvable subset of those problems… never mind just how significant some of those quality of life improvements can be between existing languages (and completely ignoring the potential scope of improvements not yet found in extant languages).
What if the solution to [insert sufficiently pernicious problem here] simply cannot be expressed in a human-useable fashion in a merely Turing-complete language? Having just the ability to compute a solution doesn’t mean you have the ability to understand (much less use or build atop) a solution.
Is date of creation a factor?
Because D was created last century.
So it's unknown and unreliable. Who gives a crap if it has elegant syntax, it's just another way to write the same stuff. The examples from the article can be done in JS, python, java, c# almost exactly the same way. Slightly different syntax.
That being said, I agree with everything else you said lol.
All the “elegance” in the article just reminded me of what you can achieve using Linq, or pythons list comprehension (which I personally don’t care for).
I used to get excited about one-liners, but if that’s what elegance is, elegance is not important to me. Are you gaining efficiency or playing code golf?
If there’s anything dev jobs have taught me it’s that readability is whats most important. You can keep your fancy lambdas etc.
Those things have their place but it’s not a crime to write a for loop with local variables.
Unless what you’re doing is as simple as a single statement, a mapping or printing something, One liner loops are not as productive or efficient. when you have multiple statements, you’re often just calling multiple loops. And don’t forget the extra time you have to spend to get the damn thing to work, as opposed to a classic for loop.
As for the functional approach to collection operations, I personally like it a lot. When I used Java, I used streams a lot, now that I primarily use C# I use LINQ a lot. I think in a lot of cases the syntax is more expressive and hence more readable than loops, but both have their place and both can be used badly.
Often times you can write a simple statement that does a lot of work and is very clear to the reader, assuming they are familiar with the API/paradigm. Equivalent loop implementations can be significantly more verbose which generally reduces readability. Other times a simple task can require a very convoluted functional approach whereas a loop implementation would be fairly straight forward.
As with everything there are pros and cons, they both have their niche but personally I think I use the functional approach more than I use loops these days.
If you cannot re-create how do you know you understand? This is one of the best ways to learn. There is zero harm here. If you don't like it you can ignore it. :)
> Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
No, we are not in an insect colony to specialize in things.
> We don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Why did we build cars when we have horses?
--------
Anyhow, it is hackernews, we do things we learn, we reinvent the wheel because we can, and we are better for it.
But if you're most comfortable with the JDK, Scala 3 with the Scala CLI provides an unmatched developer experience for small scripts and command line tools. And the output can be self-contained JAR, a GraalVM native image, or even a Scala Native binary if you use compatible libraries.
Checking the examples, my friction here is... why should I introduce a new language for those things?
First example program equivalence:
Second program equivalence: It takes to me more time, to understand what is doing D, even if theres is a previous explanation, that write down the equivalence with known tools.The last example needs to download/install dependencies, from the outside of the upstream software origins of my servers (that's a no-no in many places). apt-cache search vibe is no good for me.
If I could have need a program like that simple web example, nowadays I could go with golang, compile and deploy.
But the first two other solutions that come to my mind...
Or something like... I know that apt-get install libmojolicious-perl or install python3-flask is not an issue in many internal audits we did pass. Perl an Python are already present in the servers... or if puppet is in use, maybe ruby? But I know many places were adding new languages, using external package repositories for scripting languages, etc, is a problem...So, if it's for that article, I'm not 100% convinced to switch to D or invest my time in it... maybe I'm not the target audience.
I've nothing against D itself, but I need better marketing to be attracted.
But yeah, if you already know ruby and python and perl and awk and the unix shell, there's not much to be gained in these examples. Just if you don't know those things and know a little D, it can meet you where you are and take you where you're going.
It’s too bad D didn’t get more traction, writing it really is like writing a script, and the compiler is so fast that the edit-compile-run cycle is faster than some scripting languages. Walter is still a hero of mine!
Rust gives you better insight and control over memory management that is necessary for many of the applications that are written in C++ while offering strictly better safety guarantees and less baggage (but the tradeoff of encoding a lot of stuff in the type system). I really like Go, Rust, and Python, but all for different things.
Lots of people were using C++ and were not happy with it.
That's what I hate about python scripts - as soon as you need one third party dependency, the ease of running the script just jumps out of the window and you need to create an entire project in its own dedicated directory and include install instructions for people who want to run it.
Coming from the scripting world (Ruby) D wasn’t that hard to get started with nor was the learning curve that steep.
I usually prefer to stick with the few languages I already know, but D lang was very fun to play around and build something with, it was kinda worth it because the language was interesting to explore.
The possibilities to meta-program was endless, it’s very powerful.
Something I would like to highlight is that D lang was performant out-the-box, don’t let the GC scare you. D also felt fast to read & write once you got the hang of it.
It also has some interesting concepts like “Turtles all the way down”.
I would highly suggest giving it a try, it’s really an interesting language worth exploring and I think it has matured a lot since.
If you enter the manual memory management route, there won't be many libraries at your disposal, but you can leverage the entire C/C++ ecosystem, so that's no big deal, you go manual memory management route because you want performance and control after all
I use D for my main projects, and i love it, i still try some new languages (i picked odin recently), but i always fall back to D, because of how convenient it is to switch from system to scripting language
The only areas where i want to see D progress are:
- modern language features, such as tagged union, this one definitely helps a lot when you don't want to use the GC/OOP, i liked odin because of that part
- tooling: while the LSP is great, it doesn't support all of the D language features, so i'd love to see a builtin one, like rust's and zig's team doing, that would also help ease the learning curve for new users
- an official allocator API, so people could design libraries for GC users and manual memory mangement users transparently, avoiding the fragmention of the community
D has a bright future, it is independent, has many small companies using it, and grow at a organic rate
I don't think the new languages offer enough to make D irrelevant, they are all stuck with LLVM, while D has its own mature backend! and for that reason, D stands out!