As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string mixin, inline json & std.json. It's been so useful for the code I write at work. Much love for D
The one thing I would add to this list is documentation! There is a lot of good documentation available, but not for everything you would expect. For example, I had a hard time figuring out the behavior of sub-packages within a dub package. Some more explicit documentation on this subject would have been appreciated.
I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example:
Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.
>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.
I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects
I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries.
It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great language and to me has always felt like the way C++ should have been.
It does seem to be growing in popularity. Even in the years I've been using it, the number of libraries and community resources has expanded exponentially and every day new code is being added to
Thanks Atila!
I'm curious about your work around reflection, care to give more details? This is one of the great strength of D, and having some API consolidation sounds awesome.
Also: any opinion about runtime reflection capabilities? I love compile-time reflection as much as any other D user, but sometimes runtime reflection can do wonders if used parsimoniously.
I personally believe that it's all about _people_. How do you plan to push the community forward? After all everyone just shares their free time.
So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet.
The D forum is full of shit posts thrashing D for what it is.
In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision?
Looking forward what new perspective you bring to the community!
I have to admit I totally latched onto the point you made about fast development time.
The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.
Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.
Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?
Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.
Is there any impetus in the community towards embedded development? By embedded I mean natively on microcontrollers, even if you were limited to 32 bit ARM platforms?
As a portion of our work targets micros, all of our code needs to be written in a language that supports micros so that we can share code. There is impetus to move on from C, but Rust is the first and only viable replacement candidate because of this.
What about -betterC? I always thought this was a nice "pivot" for D. It would be great to have more support for this direction. You can't avoid malloc there, but maybe some instrumenting for leak detection or some libc replacements that exploit or are exploited by the language.
Other than that, I'm okay with anything that was already in Eiffel or Modula-3…
BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM.
The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.
> Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it.
> With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages.
If you're using an RPC IDL you explicitly do not want to share that code, you want to share that API.
> We’re mostly there—using the actor model eliminates a lot of problems that would otherwise naturally occur.
So D comes with an actor system baked in at the language level? I like that sort of thing after using Erlang and using some half baked libraries in other languages.
I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges.
I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me.
Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library to do something that isn't already in the fairly generous stdlib, I can find it on DUB.
Not as exotic as Rust, due to more being in the Algol line of succession than ML's.
But boy, on the Algol-tree, it's about as far away from Go as you can, erm, go.
The blog poster's predecessor was about as heavy as you can get into generics without being called Stepanov.
D tends to have quite a lot of features and lets you pick your subset, which brings it closer to languages like C++ or Scala. Go, being basically Oberon filtered through New Jersey, is a lot more minimalistic. Old Java vs. new Java, basically.
Compared to Rust: smoother learning curve, and you don't have to fight the compiler so much
Compared to Go: much better designed and richer language.
Obviously in terms of community, it's much smaller.
But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.
I work in c++ and D was designed in part to address a lot of c++ complaints. so I find myself with very few issues while writing D. it's just a very enjoyable experience (subjective ik)
import std.stdio;
struct Math(string Op) {
static auto eval(T, U)(T l, U r) {
static if (Op == "+")
return l + r;
else static if (Op == "-")
return l - r;
else static if (Op == "*")
return l * r;
else static if (Op == "/")
return l / r;
}
}
static immutable auto result = Math!("+").eval(1, 2) + Math!("*").eval(3.0, 3.0);
void main() {
writeln(result);
}
You'll never be able to do anything like that in Rust until const generics are not only complete on their own, but also fully compatible with "const fn".
Rust is pretty low level. As a Python programmer I can use D a lot easier (with the exception of templates and all the stuff that assumes you know C++ which I don't) than Rust as I don't have to worry about memory.
When you believe in systems programming languages with tracing GC support, powerful metaprogramming and generic code capabilities that compiles as fast as Go.
D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been completely left behind by the usual Rust/Go/Java suspects. I'm very confident that it is capable, but that isn't particularly obvious atm.
The one comment on the article on the page I think is spot on - I think every programmer language designer underestimates the importance of good IDE support.
I love D and one space I want to see more of is DMD on SBC's and moreso than that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the main competitors to D, not sure if others would agree, but that's just my view. Other than that it's a great language.
Let's be real, in the real world D, go or rust are not competitors to anything.
Just take a look at http://www.modulecounts.com
to see the gap between language ecosystems.
I wish standardizing documentation tooling (everyone uses a different tool today and ddoc by default has _no_ styling, no navigation, no nothing, so usually nobody writes docs for their code unless it's a big project like vibe.d) and IDE support was on this list (vscode centric tools exist and mostly work, but it's still fairly hit and miss) .. D's tooling has languished for a long time even if it is a great language otherwise.
I don't like D mainly because of the whole dichotomy between structs and classes (and also because of many other smaller things).
But I don't think D hasn't succeeded in replacing C++ for this reason; the reason D hasn't succeeded yet is because it's relatively unknown in the enterprise developers circle. Most people haven't heard of D.
I would like to have a java to D, because a lot of scientific libraries are done in Java. If the interop is easy and can automagically create Java compatible libraries from D, it is a big win. Hopefully it is in the roadmap. C++ interop not that much for me.
[+] [-] ktm5j|6 years ago|reply
The one thing I would add to this list is documentation! There is a lot of good documentation available, but not for everything you would expect. For example, I had a hard time figuring out the behavior of sub-packages within a dub package. Some more explicit documentation on this subject would have been appreciated.
[+] [-] jordigh|6 years ago|reply
http://inversethought.com/hg/medcouple/file/tip/medcouple.py...
http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...
[+] [-] 7thaccount|6 years ago|reply
[+] [-] kernyan|6 years ago|reply
I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects
[+] [-] grawprog|6 years ago|reply
It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great language and to me has always felt like the way C++ should have been.
It does seem to be growing in popularity. Even in the years I've been using it, the number of libraries and community resources has expanded exponentially and every day new code is being added to
https://code.dlang.org/
Not to mention dub is probably the most simple straightforward build system I've worked with.
[+] [-] atilaneves|6 years ago|reply
[+] [-] mochomocha|6 years ago|reply
[+] [-] arunc|6 years ago|reply
So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet.
The D forum is full of shit posts thrashing D for what it is.
[+] [-] abaga129|6 years ago|reply
Looking forward what new perspective you bring to the community!
[+] [-] exikyut|6 years ago|reply
The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.
Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.
Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?
Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.
[+] [-] qznc|6 years ago|reply
[+] [-] rkangel|6 years ago|reply
As a portion of our work targets micros, all of our code needs to be written in a language that supports micros so that we can share code. There is impetus to move on from C, but Rust is the first and only viable replacement candidate because of this.
[+] [-] Shorel|6 years ago|reply
Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.
[+] [-] mhd|6 years ago|reply
Other than that, I'm okay with anything that was already in Eiffel or Modula-3…
[+] [-] skocznymroczny|6 years ago|reply
The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.
[+] [-] gravypod|6 years ago|reply
> With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages.
If you're using an RPC IDL you explicitly do not want to share that code, you want to share that API.
[+] [-] pornel|6 years ago|reply
[+] [-] dmix|6 years ago|reply
So D comes with an actor system baked in at the language level? I like that sort of thing after using Erlang and using some half baked libraries in other languages.
I’m curious how good it is...
[+] [-] thiago_fm|6 years ago|reply
I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.
[+] [-] jordigh|6 years ago|reply
I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me.
Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library to do something that isn't already in the fairly generous stdlib, I can find it on DUB.
http://code.dlang.org/
[+] [-] mhd|6 years ago|reply
But boy, on the Algol-tree, it's about as far away from Go as you can, erm, go. The blog poster's predecessor was about as heavy as you can get into generics without being called Stepanov.
D tends to have quite a lot of features and lets you pick your subset, which brings it closer to languages like C++ or Scala. Go, being basically Oberon filtered through New Jersey, is a lot more minimalistic. Old Java vs. new Java, basically.
[+] [-] mochomocha|6 years ago|reply
Compared to Go: much better designed and richer language.
Obviously in terms of community, it's much smaller. But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.
[+] [-] xhgdvjky|6 years ago|reply
the meta programming is very cool also
[+] [-] ZootAllures91|6 years ago|reply
[+] [-] petre|6 years ago|reply
[+] [-] 7thaccount|6 years ago|reply
[+] [-] zem|6 years ago|reply
[+] [-] he_the_great|6 years ago|reply
https://dev.to/jessekphillips/my-case-for-d-444p
[+] [-] pjmlp|6 years ago|reply
[+] [-] kitd|6 years ago|reply
[+] [-] dsissitka|6 years ago|reply
[+] [-] coldtea|6 years ago|reply
The most popular frameworks having the 90% of deployments, are at the middle to bottom of the Techempower benchmarks.
[+] [-] rayiner|6 years ago|reply
[+] [-] jeffrallen|6 years ago|reply
[+] [-] rcpt|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
[+] [-] mhh__|6 years ago|reply
[+] [-] dwrodri|6 years ago|reply
[+] [-] alexashka|6 years ago|reply
[+] [-] WalterBright|6 years ago|reply
Oh, we're well aware of it. It's just that the language design part consumes all our time.
[+] [-] giancarlostoro|6 years ago|reply
[+] [-] The_rationalist|6 years ago|reply
[+] [-] floatboth|6 years ago|reply
[+] [-] arunc|6 years ago|reply
Edit: added previous "vision" links
[+] [-] Profan|6 years ago|reply
[+] [-] axilmar|6 years ago|reply
But I don't think D hasn't succeeded in replacing C++ for this reason; the reason D hasn't succeeded yet is because it's relatively unknown in the enterprise developers circle. Most people haven't heard of D.
[+] [-] flowerlad|6 years ago|reply
[+] [-] fithisux|6 years ago|reply