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.
Well he should, he's the guy who created D.
Remarkable understatement right there :-P
Just to note: Walter Bright, whom you replied to, is the creator of D.
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.
I'd love to listen to you two discuss D, BetterC and Zig and C.
But - it's not production ready yet, is it?
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.
> - 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.
That happens to all languages over time. The more interesting thing is how well do those features fit in with the language's style.
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.
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.
// Increment all elements by one (array-wise expression)
half[] += 1;
Is this really that useful? Seems like a weirdly specific code smell...I know Ruby, so here is what I'm used to:
half.map { |i| i + 1 }
I also know Elixir: Enum.map(half, fn i -> i + 1 end)
...and JS, I guess because we have to: half.map(i => i + 1) // It looks just like the Ruby one
...vs whatever the Python version is... I don't know Python very well, but I imagine it involves list comprehensions...Compare all those to the aforementioned D version :
half[] += 1;
I'm really feeling the D version!EDITED to fix little mistakes.
It just seems like a weirdly specific syntactic sugar... which is a "language smell"... to me
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.
Looking at the notes, it may have separate syntax to make compiler vectorization and parallelization easier. Plus it's pretty terse.
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.
"...was originally released under a custom license, qualifying as source available but not conforming to the open source definition. In 2014..."
Which has been a different path other more popular languages took to increase popularity. The standard D2, which is now D, introduced breaking changes and stabilization only came around 2010.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.
I have code that has worked unmodified for many years. The language doesn't change that often.
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)
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)
Might be more? Don't get me wrong I see the benefit. The vectorflow example I think is a good use case thought because it allows a more natural conceptualization of object -> member access -> conversion rather than having to call to!ulong(W.length) which forces the reader to start with the (pending) conversion. You get this same dataflow/conceptualization benefit in threading macros in clojure (->, ->>, etc).Anyway, thank you for all the work you've done.
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 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!
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.
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)
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.