Logged in today and saw this! Walter here, AMA!
I dimly remember a fairly deep analysis/comparison of C++ and D that went into how opaque or transparent abstractions were to the compiler, and what that means for performance (models) and compile times.
I thought it was by you, but can no longer find it. Might you be able to point me at it?
See here: http://www.drdobbs.com/parallel/the-case-for-d/217801225?pgn...
Are there any reasons - in your opinion - which should make one start tinkering with D before spending time with rust or go ?
The idea of BetterC is to not link to the D runtime library at all.
So, the parts of Phobos that are usable from it are the parts that:
1. are "header only", meaning all the functions are templates
2. don't use exceptions or the GC
3. don't use OOP classes (which rely on the GC and the runtime)
Not much of effort has been expended cataloging this, though.
1. Would it make sense to work on (for the community in general, not necessarily you personally) a header only standard library, a sane STL if you will, for betterC?
2. Is there any interest in language support for GC and runtime independent classes/interfaces? I understand this is partly doable already by abusing templates, but I imagine the results aren't necessarily pretty or concise.
Regardless, thanks a lot for the responses. I haven't managed to write much D beyond small experiments due to ecosystem and related issues, but the ability to incrementally integrate small parts of D in a C++ codebase as freely as betterC lets me is very tempting.
It's a very good question. Most of Phobos is already templates or the GC, so that wouldn't be much change. A more complex problem is working without exceptions. I don't have a ready answer for that, it's a good area for investigation.
D already has support for "COM" classes/interfaces which work in BetterC.
Here is Shachar Shemesh's introduction:
https://www.youtube.com/watch?v=xNWRgEHxOhc&feature=youtu.be...
I was not aware of this at all, do you ever see a time where you could compile D with classes an all with no garbage collection? I am not bothered by the GC coming from C# and Python but it is interesting to know where D is headed since I know there were many efforts at making D compile without any GC.
Basically do you think it will ever make sense for D to just compile without GC by passing a compiler flag? Irrelevant of what D features are used, and maybe it can tell you which features cannot be used without GC (sorry if this already is a feature, I use D I'm not a guru yet).
Suppose I was writing systems software. Considering I know neither, why would I invest time learning D instead of C++? Does D offer anything in that regard?
Plus: none of the sanitizers offer quite-the-same runtime protections. They're intended for use in testing to flush out bugs, not production for avoiding bugs. As is, MSan and ASan are mutually exclusive.
And on the C++ compilers that support such language extension, how does it work with binary dependencies?
why would it matter ? AFAIK D doesn't even have an ISO standard.
> And on the C++ compilers that support such language extension, how does it work with binary dependencies?
you at least get whole-program safety for libc calls since it works by replacing such calls through dynamic loading
Sure it does.
D is defined by the DMD compiler as the reference implementation.
Whatever DMD allows for minus implementation bugs, is what the D programming language means.
C++ is defined by an ISO standard, a document that specifies what every implementation is required to implement.
So any D developer can be sure their code is compliant as long as DMD accepts it, while a C++ developer needs to pay attention how close their favorite compiler is to ISO C++.
> you at least get whole-program safety for libc calls since it works by replacing such calls through dynamic loading
Libc is a very tiny portion of any industrial grade C++ application, and only relevant in open source systems, as it is shipped in binary form in other platforms.
That's a cute, but if that's "the letter of the law" then Walter can replace DMD with emacs in the next release and it'd still be a conforming implementation, and you'd just have to rewrite your codebase in lisp to keep it functioning. All the options available to the D programmer in that case (like "keep using the previous version") are also open to C++ programmers when their compiler makes a change that breaks their code.
In practice everyone cares about stability. The C++ standard provides a signal that "this behaviour is (not) likely to change in the next release". All other features not mentioned in the standard like compiler flags and implementation details like the stack and the heap are on par with features in D when it comes to compatibility from version to version.
The C++ programmer who writes "to the implementation," not "to the standard" is in at least as stable and predictable a situation as the comparable D programmer.
Which is a contrived argument
I do think it's a bit crazy to say that it can increase uncertainty about future compatibility, though -- on that front I think it standardisation has a strictly stabilising effect.
That says everything. Thanks for this ;)
In your expert opinion would it make more sense for a WASM backend to be part or the DUB build process or embedded into DMD itself?
I think Rust has some approaches that let you build as an addon to Cargo (the Rust equivalent to DUB) so maybe a similar path might make sense? I do know there are efforts to bake WebAssembly into Rusts compiler down the road though.