Why I use the D programming language for scripting (2021)
opensource.com
opensource.com
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.
Checking the examples, my friction here is... why should I introduce a new language for those things?
First example program equivalence:
tr -s ' ' '\n' < file.txt
awk 'NR <= 10 {print} {total += $1} END {print "total:", total}' monies.txt
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...
perl -Mojo -E 'a("/")->to_text(sub {
"Hello World " . shift->req->url->path
})->start' -l http://localhost:8080
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)
ruby -rwebrick -e"WEBrick::HTTPServer.new(Port: 8000){ |req, res| res.content_type = 'text/plain'; res.body = 'Hello World ' + req.path; }.start"
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.
awk 'NR<=10 {print; total+=$1} END {print "total:", total}' monies.txtThe 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.
Java and C# are not really systems programming languages; they carry too much baggage for that.
Even Go is not too comparable to D
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...
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!
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.
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.
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.
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
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.
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.