Kinda related: Apple's blog post on how they borrowed an idea from D, about assert statements: https://developer.apple.com/swift/blog/?id=15
How does D improve on C++17?
61–70 of 77 posts
Re: How does D improve on C++17?
#62Earlier quoted context omitted.
The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development. Package managers for development allow things such as installing multiple versions of a library, creating "sandboxes" with specific versions of libraries, and sometimes they are also the de-facto build system for a language. The OS packag…
(Note: my frame of reference is experience with UNIX-like systems such as Linux and the BSDs, and even MacPorts on OS X.) The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development. Distro repos do provide many of the packages you need for development because you need to be able to compile all of…
> Distro repos do provide many of the packages you need for development because you need to be able to compile all of the C++ applications and libraries in the distro repo, of which there are many.
I think it's more along the lines of the distro's package manager's responsibilities should be different from the language's PM. Although I do find myself in agreement with you that the distro's PM is sufficient for C/C++
Re: How does D improve on C++17?
#63Earlier quoted context omitted.
The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development. Package managers for development allow things such as installing multiple versions of a library, creating "sandboxes" with specific versions of libraries, and sometimes they are also the de-facto build system for a language. The OS packag…
(Note: my frame of reference is experience with UNIX-like systems such as Linux and the BSDs, and even MacPorts on OS X.) The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development. Distro repos do provide many of the packages you need for development because you need to be able to compile all of…
Yes, a distro package manager can partially solve this issue but there are some corner cases where this fails. Though I partially agree with you: my OS package manager can provide me with the C and C++ libs I need most of the time.
To name a C++-specific pain in the ass: Boost. The Boost libraries make minor, incompatible changes every now and then (which is good), requiring applications that use Boost to either specify a certain version that they can work with or bundle the Boost libraries with the application source (which is bad).
And "development" package manager should be able to deal with the situation above, but distro package managers don't really work here. There are several libboost-foo-1.xy.z packages available but it may be that none of those will work with a certain application you're trying to build (either too old or too new).
This situation is handled by development package managers by pinpointing the exact version (or range of versions) of a library an application depends on. This also allows specifying compiler/interpreter version(s) an application works with. Some of my projects depend on features that are only available in recent GCC versions (__builtin_shuffle), but that requirement can only be informally specified in the README, nothing enforces it (leading to unnecessary bug reports).
This is also what git submodules does but without a standard build system, it only solves half of the problem (and may create new problems).
I think you and I can both agree that this situation is less than ideal. Using just one package manager application should be enough, there's a lot of overlap between what a distro package manager and a development package manager do. And it's a huge waste of engineering resources to maintain language-specific package managers such as pip/gem/cabal/cpan.
"Next generation" package managers such as Nix and GNU Guix should be able to address these issues, but they are yet to be widely adopted. Unfortunately those applications are based on less-than-mainstream languages (Haskell and Guile Scheme, respectively) which might scare away potential adopters.
Re: How does D improve on C++17?
#64I'm curious how many people out there on HN actully use D and what for? I don't typically see D based projects here on HN so it would be interesting to find out about any use cases where D was found a perfect fit.
What I'd particularly like to see is an analysis of D vs. Rust. Both have been touted as systems programming languages to replace C/C++, and I'd be curious to see a breakdown of their strengths and weaknesses compared to each other.
Re: How does D improve on C++17?
#65I use C++ but I don't really like it, but ... we need all the libraries that exist in C++ rewritten in D. And also, the same compiler support in the development frameworks.
Otherwise, it will be a failure.
Re: How does D improve on C++17?
#66D is a awesome language to work with, it's got many useful language features that make the activity of code writing a pleasure. - I hope this criticism is taking constructively. However not a beat a dead horse, but if you want to process more than a trickle of data in it you run into problems with the GC really quickly. I really feel the language would be better off without the GC. These are not the same issues addre…
> I've literally seen 20x or more speedups in multithreaded cases just by making sure I reuse every buffer rather than create new ones. Reuse rather than free and reallocate is a core practice whenever you feel the need for speed, regardless of the memory allocate strategy used. For some very fast D code: https://github.com/facebook/warp Minimizing the amount of heap memory allocated is a core strategy.
Thanks for responding. I've seen this code used an an example before actually.
Not that buffer reuse/avoiding heap allocations was unknown to me, it was just surprising to see this in an application that spent most of it's time waiting on the network.
I will say as a positive point that the equivalent D code to a C++ implementation was much cleaner due to build in array slicing among other things.
There are other areas where heap allocations are not so avoidable however (some hashmaps, some std's). My main point is that like at all languages, heap allocations are slow, but here they bear an unnecessarily large contention factor.
I really like D so I hope this is helpful feedback.
Re: How does D improve on C++17?
#67Earlier quoted context omitted.
I'm always on the look out for improvements to C++, and it's been a while since I looked at D... Hope you don't mind if I ask you a couple questions. Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Also, do you know if…
You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that dele…
I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++).
I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me greatly however...
I remember hearing about efforts to remove a lot of the reliance on the GC, and I guess I was hoping that that was further along than it sounds like it is.
Still, I'll try not to pass judgement until I try it out on something small. There are a lot of other potential issues unrelated to the GC that would probably be dealbreakers for me.
Re: How does D improve on C++17?
#68Earlier quoted context omitted.
>it's looking like the next release will have dmd written in D. Is that going to make it trickier for GDC/LDC to stay in sync with DMD? (Either way, it's exciting news!)
Tricky or not, they're on board with the jump.
How will you then bootstrap it on new platforms? Will it become reliant on cross compilation for bootstrap?
Re: How does D improve on C++17?
#69Earlier quoted context omitted.
You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that dele…
I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++). I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me…
The array literals problem isn't so bad, the thing is static arrays in D are distinct types, so you'd say int[2] = [1, 2]; which would go on the stack, but doing int[] = [1, 2]; would allocate since it would be a dynamic array then.
Good luck with trying it out, you make tradeoffs as with any other language :)