Why I Like D
aradaelli.com
aradaelli.com
We've gone a step further with ImportC, and now C code can be imported directly into the D compiler, which makes it easy to interface D code to your existing C base.
Edit: I added that first sentence because it's awkward to tell the creator of the language that his answer was incomplete.
Just to note: Walter Bright, whom you replied to, is the creator of D.
Well he should, he's the guy who created D.
It wouldn't surprise me if he genuinely didn't know about how dstep and dpp are used.
Remarkable understatement right there :-P
this is definitely a killer feature; i can think of very few languages that can do this. i think rust and zig are the only other two that have gotten any sort of popularity, though i would love to hear of any language i've missed.
But - it's not production ready yet, is it?
I'd love to listen to you two discuss D, BetterC and Zig and C.
I've never had a chance to look at it much, but I think the magic is in the metaprogramming capabilities. It's more principled than C++ templates, more ergonomic than Scala macros, and more practical than Template Haskell. Somehow. (At least this was my impression from discussing it)
My point isn't that "D doesn't meet that bar", but that the GP picked strange points of comparison: the steelman argument for C++ templates would focus on power (e.g. Eigen) instead of principles, and those for Template Haskell on safety instead of practicality. And of course, no macro comparison would be complete without gesturing vaguely in the direction of Lisp while muttering something about parentheses.
It's like the "Always Be Closing" speech in Glengarry Glen Ross: Dlang macros as John Travolta truly do kick ass in that scene—but why not have Al Pacino there to represent as top dog of the local branch?
But, I think one of the things that people seemed very happy about feature-wise that started to turn me off the language was UFCS. I don't deny that it makes the written code look more elegant but I think to me it existed as a net negative for other people who are unfamiliar with the code they are reading. There was an example someone gave years ago on reddit that was supposed to convey how clean the code to solve the problem was but it included an UFCS expression of the form 'a.b!c.d' which was sans-UFCS 'd(b!c(a))'. Trying to determine which reordering the compile would going to eventually choose seemed like more work than should be necessary for simple expression like that.
Having said all that it still might be a good choice for certain development environments and I should see whether there's a second edition of TDPL.
It helps keep structs small and simple, rather than becoming kitchen sinks.
Without knowing any of the associated types and members how many interpretations could the prior expression 'a.b!c.d' have with UFCS and parens-less calling conventions (and any other feature that might contribute to different semantics)?
b!(c.d)(a)
b!(d(c))(a)
d(b!c(a))
d(a.b!c)
Anyway, thank you for all the work you've done.
The template parameter after a ! without parentheses is always 1 token, so it's never one of the first two interpretations.
Furthermore, the point is that often when writing generic code, you're not supposed to care what the `.d` means specifically. For example, an `InputRange` is defined to have `.front`, `.empty` and `.popFront` properties. Is `.empty` a member variable, function, or constant? Doesn't matter, as long as it results in a boolean.
This does require some getting used to. A common question from newcomers is how to explicitly spell out the type in a situation like this:
import std.algorithm;
void main()
{
auto x = [10, 20, 30].map!(x => x*2);
}
While it's flexible, generic code is also complex. Many D standard library functions don't take a simple `string`, but a 'generic input range of a code unit'. (UTF-8, UTF-16, UTF-32). The resulting template machinery that this spawns is not pleasant to work with, so I understand your concern.
In my own D code, I often use regular arrays, foreach loops and if-statements instead of ranges, map and filter etc.
"...was originally released under a custom license, qualifying as source available but not conforming to the open source definition. In 2014..."
Parallel to this, other programming languages became more popular and evolved, particularly C++. This certainly affected D's "novelty value".
I wonder how much these facts negatively influenced D adoption.
It's now part of the dmd D compiler. Just throw the -vasm switch, and it'll display the generated code on the console.
I see many uses for a freely available disassembler. For example, you can add it to your favorite text editor! Admit it, you've always wanted to disassemble your text.
https://github.com/dlang/dmd/blob/master/src/dmd/backend/dis...
Humble comment. It is very good to hear this. Will guard this for future examples.
I'm impressed with -vasm, but fo the record this isn't strictly true. It supports most everything you'll see day to day but AVX2 (for example) is emphatically not the latest and greatest.
AVX512 adds quite a lot of stuff for example. Entirely new set of mask registers for example.
Even with the VEX prefix Intel did new instructions just recently (VNNI).
As long as it doesn't blow up I think it's fine to not support these, just want to make it clear that if you use (say) TSX via inserting raw bytes in an AsmStatement (which I have done) then the disassembler will not pick it up.
This is easy to verify by looking at the archived releases.
This is a weird thing to call out java for: you cannot inherit from multiple classes there. You can only get a diamond if you inherit two interfaces with default implementations of a method on a shared parent interface. Over a decade of writing java, I hit this zero times. In any case, Java treats it as a compile error and forces explicit resolution instead of silently doing something confusing.
vibe.d is pretty similar to express.js
There are also other non-vibe web service libraries like arsd cgi (can't tell you much about that one) or hunt-framework (which is probably the highest performance library for the D ecosystem if you can believe the benchmarks, but doesn't have much documentation)
If you released super popular whatever (game engine, embedded platform, 3d design software) that uses D as its customization language suddenly a lot more people would have a good reason to learn D.
D had some missteps along the way that lost some initial traction. I also wouldn't be surprised if timing was a factor with more C++ warts being added while the programming community has learned more lessons along the way that could be applied to the next languages (Go, Rust).
As I followed D, the problems I remember there being were:
- Compiler availability (DMD vs GCC)
- Split stdlib
- It was aiming for C/C++ post-Java but covered more Java use case (GC) than the remaining C/C++ ones (no-GC). It took a while before BetterC. No idea how well that ecosystem has matured.
- It felt like they were shoehorning every feature into the language rather than having a cohesive design strategy
These have slowly been resolving but Rust is now here, targets most of BetterC's use cases by default, and the borrow checker has let me squeeze out performance out of my code that would have been irresponsible without the compiler making it maintainable.
That happens to all languages over time. The more interesting thing is how well do those features fit in with the language's style.
[0] https://web.archive.org/web/20110320130326/http://www.digita...
> - Split stdlib
Oh, yes, even as a complete outsider who merely reads D related threads from time to time, I remember these coming up repeatedly years ago. Both on HN and the programming side of reddit, among the top comments on D related threads. The tone was one of these being showstopper issues too.
To be clear, I have no experience with D myself - the point is just about the PR side of things and how things seemed to an outsider.
I wish that criticism would go away.
But the language just wasn't for me. Right off the bat, the default import style which thrusts everything exported into the default namespace like C seems odd at this point. Apparently one can use what are called static imports, but as a code reader I can't enforce it.
It feels a lot like a language for C(++) folks, who IMO tend to be more conservative and entrenched.
Given the initial paragraph, maybe I'm just not smart enough to grok it :).
Yes, two different D modules can declare the same name as public, and they will not conflict with each other.
It wasn't about name clashing, but readability. It's not clear at first glance what functions belong to which imports.
As an example: https://tour.dlang.org/
Three imports and what appear to be four unqualified functions from them.
Or just use static import.
Well, the developer wrote `import thing;` instead of either `static import thing;` or `import thing : specific, list;` so it was their decision.
The old phrase "nobody ever got fired for buying IBM" is another one (though nobody has said that since 1990).
it's pretty awesome
I have code that has worked unmodified for many years. The language doesn't change that often.
On a more serious note it's cool to see the languages creator quite frequently on HN - it is the reason I took a look at it a while ago :)
I work on D too, feel free to email.
i had two abortive attempts to use the language for specific projects - one was to wrap a C++ library and use it from D, but it turned out the swig bindings didn't work.
the second was to find an active gtkd-based app and contribute to it, to get a feel for desktop gui development (which seems on the surface like a very compelling use case for the language), but after asking on reddit no one could suggest anything other than tilix, on which development has stalled :( i would still love to do this, if anyone has something to suggest.
if anyone is involved in a fun desktop-based D project (CLI, TUI or GUI are all fine) please recommend it!
// Increment all elements by one (array-wise expression)
half[] += 1;
Looking at the notes, it may have separate syntax to make compiler vectorization and parallelization easier. Plus it's pretty terse.
I know Ruby, so here is what I'm used to:
half.map { |i| i + 1 }
Enum.map(half, fn i -> i + 1 end)
half.map(i => i + 1) // It looks just like the Ruby one
Compare all those to the aforementioned D version :
half[] += 1;
EDITED to fix little mistakes.
It just seems like a weirdly specific syntactic sugar... which is a "language smell"... to me
e.g.:
arr1[] += arr2[] / 10.0 + 5;
TBH, I don't use this feature much, because I work with ranges more than arrays, which do not have this ability. This feature predates ranges (and the std.algorithm.map function, which can do what you say as well).
You can also mix and match scalar and slices, so for audio code it's quite cool:
a[0..frames] += b[0..frames] * volume;In this case the syntax lowers to a template which handles the iteration for you. It is not special, it gets treated the same by the compiler backend, but it will almost definitely be inlined & vectorized if the compiler is allowed to.
GCC and LLVM are actually clever enough to call memset for you if they deem it profitable.
I wonder how many people are missing out on Go for a feature they wouldnt miss 80-90% of the time?
Just surprises me how quickly people write it off. Horses for courses!
You can take D metaprogramming from my cold dead hands.
No argument on going from D to something else but to not know either and not even try Go is what surprises me.
D has me fooled and I can't imagine Go choosing to go further in D's direction over C#. I feel sorry for them.
Then wait until you see how Rust usage compares with C and C++ usage. Sorry, but I fail to see the point of your comment.