D is technically better than C++ in most features. (It has always lead C++. For example, among about 100 new feauters that C++11 brought, only 2 were not already in D. No C++ designer will ever admit this fact.)
D is safer and more productive. It's a joy to write in D because most of the time it feels like whatever you think, you code. This is unlike C++ where you fight the language all the time. C++ is not a productive programming language. I say this with experience: I coded in C++ as an "expert" for many many years, including these last couple of years. It's not fun to write in C++, which translates to another kind of loss of productivity.
C++ is a burden and liability for companies but no CTO will be blamed for chosing it because it's popular. I can list so many popular things and persons that worth nothing but I will refrain from getting political.
Yes, on paper, there are way more C++ programmers out there than D programmers. But I interview these C++ programmers occasionally. Most of them don't even have an inkling that they don't know C++ at all.
How about engineering with C++? That is such a difficult task. I went over header file hygiene with a colleague a couple of months ago. The number of points that you should pay attention to is mind boggling: Don't #include unnecessarily, do forward declare as much as possible (but what can be forward declared is hard to understand even for experienced programmers), #include your own API header first to prove that it's complete (and good luck!), don't forget header guards, don't reuse header guards, etc. etc. This is just efficient header file usage! We haven't started coding yet!
My friends, the emperor doesn't have clothes. C++ simply is not a tool that is designed well. People who choose it do so because they have to or they are masochists. (True story: I asked a relatively young Google meetup presenter once why he was using C++ instead of a modern language and he said "because it is hard".) C++ separates the elite from the masses; I used to strive to be a C++ elite; I am not interested a bit anymore; I want to write useful programs with D; and I do.
D is niche only because humans are populists. We are not encouraged to use tools (or products) that are designed better. We follow popular leaders. It takes one some time to find his or her own voice to reject bad products and use only good ones. I am extremely lucky to work for a company that allows me to use D to write useful products.
I still take the same joy from programming that I did when I first learned it.
Then there is the human aspect of it: I want to be associated with real people isntead of snobby elites. (Remember how C++ was marketed at around 2000? "Yes, C++ is hard but it was never meant to be for normal programmers anyway." Ha ha ha! I am old enough now to reject that mentality. Bad design is bad design my friends; you can't defend it by blaming the user for not being elite.)
I can go on and on...
Now it's my turn to ask: Why would anyone choose C++ for their projects despite the production costs that it brings? None of your programmers really know it; they introduce hidden liabilities in the projects, their source code become non-refactorable monsters. Why waste that money on C++ when you can produce products easily. Products that just work...
> Why would anyone choose C++ for their projects despite the production costs that it brings?
Familiarity, and all the libraries and tools available for C++. I see that D has a section on C++ interop,[0] but it looks about as painful as FFI usually is, and even more painful given how template-heavy C++ code tends to be.
(Completely unrelated: I can't mention FFI without also mentioning how amazing LuaJIT's C FFI is. The developer(s) really nailed it.)
I actually don’t think C++98 was that bad or complex. Yes nobody knew how to use it and wrote Java instead, but I think the hate comes from having code spanning so many different features and idioms that also require a compiler expert to understand.
I recently read almost the whole book in a week or so. It's excellent and I feel like I can write in D pretty well after reading it. Too bad that I most likely won't be writing in D, but, at least, I'm confident I can come back to it anytime and be up to speed if I ever need to. This book should be the goto for anyone who wishes to quickly learn the language.
It may not be a step function improvement but the difference is still night and day: Dreading one more line of C++ versus looking forward to many fun lines of D.
I mean... Modules versus header files, 13 times faster compilation, introspection, unittest, etc. etc. etc. Okay, it's more like death by a thousand cuts but once you produce with D, you can't even touch C++ anymore. I am in that state...
Sure, that's what makes C++ one of the worst PLs. Just break for every decade or so to fix things for good.
What's D been doing meanwhile? D community and the authors know its short comings for over a decade now, which are the reasons for its lack of adoption even in the open source world. Most of the D code is yet to be written, tbh. If D can't break stuff to fix the mistakes with defaults, why was all the hatred marketing towards C++? Was it a failed strategy trying to kill C++, so let's just surrender to it via core.stdcpp?
PS: Yes, D has the best interop with C++ in the world and even better interop with C as the memory model is same!
I am not aware of a common issue like that but D has bugs.
> Also importC isn't what you think it is
That's contrary to my tests: I installed libplot on my system, 'import'ed its .h file to my D source code, called C functions from D, linked with -L-lplot and it worked.
> not importing foreign C libs you've installed on your system
Maybe you mean something else with "importing" but I installed a foreign C library on my system and it just worked without any hand-written D bindings for it.
I am not aware of a common issue like that but D has bugs.
Not an error I suppose, but doesn't fill me with confidence nonetheless.
$ dub test
No source files found in configuration 'library'. Falling back to "dub -b unittest".
Performing "unittest" build using /home/lewis/dlang/dmd-2.100.2/linux/bin64/dmd for x86_64.
myproject ~master: building configuration "application"...
Linking...
Running myproject
Hello world!
(dmd-2.100.2)[lewis@lightgrey myproject]$ micro source/app.d
(dmd-2.100.2)[lewis@lightgrey myproject]$ dub test
No source files found in configuration 'library'. Falling back to "dub -b unittest".
Performing "unittest" build using /home/lewis/dlang/dmd-2.100.2/linux/bin64/dmd for x86_64.
myproject ~master: building configuration "application"...
Linking...
Running myproject
core.exception.AssertError@source/app.d(9): unittest failure
----------------
??:? _d_unittestp [0x555fe0e339b1]
source/app.d:9 void app.__unittest_L8_C1() [0x555fe0e328b8]
??:? void app.__modtest() [0x555fe0e33888]
??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo) [0x555fe0e3d9c2]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo)).__lambda2(immutable(object.ModuleInfo)) [0x555fe0e3b88f]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x555fe0e42a83]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x555fe0e42f5b]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo))) [0x555fe0e42a11]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo)) [0x555fe0e3b861]
??:? runModuleUnitTests [0x555fe0e3d80e]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])).runAll() [0x555fe0e342d8]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])).tryExec(scope void delegate()) [0x555fe0e34265]
??:? _d_run_main2 [0x555fe0e341ce]
??:? _d_run_main [0x555fe0e33f97]
/home/lewis/dlang/dmd-2.100.2/linux/bin64/../../src/druntime/import/core/internal/entrypoint.d:29 main [0x555fe0e328dd]
??:? __libc_start_main [0x7f1a0be25e09]
../sysdeps/x86_64/start.S:120 _start [0x555fe0e327c9]
1/1 modules FAILED unittests
Program exited with code 1
Is this one of the dub hello worlds? Looks like it.... but it also says line 8 and the built in thing doesn't have a line 8. So what is the code there? If it is `assert(0)`, you're seeing the result of the test. The info is a bit spammy since it prints all the mostly-useless stack trace but there's some situations beyond hello world where the extra info helps explain why the test failed.
If the default project manager barfs out all of that - ??? and all - when you write a simple hello world project with a failing test...
Well I'm not filled with confidence. If you discover such a lack of care at that early of a stage, god knows what it'll be like when you actually start solving problems.
I heard Discord may have negative posts as well but I find the official D newsgroups (with a forum interface) very friendly and clean. Minimal moderation seems to help there.
We do our best to ensure everyone feels welcome to join in. Of course none of us have social media training and are just doing our best.
If something is going down and we are not taking action it may be because we are not aware of it being problematic and are always open to hearing complaints as they come up!
D is safer and more productive. It's a joy to write in D because most of the time it feels like whatever you think, you code. This is unlike C++ where you fight the language all the time. C++ is not a productive programming language. I say this with experience: I coded in C++ as an "expert" for many many years, including these last couple of years. It's not fun to write in C++, which translates to another kind of loss of productivity.
C++ is a burden and liability for companies but no CTO will be blamed for chosing it because it's popular. I can list so many popular things and persons that worth nothing but I will refrain from getting political.
Yes, on paper, there are way more C++ programmers out there than D programmers. But I interview these C++ programmers occasionally. Most of them don't even have an inkling that they don't know C++ at all.
How about engineering with C++? That is such a difficult task. I went over header file hygiene with a colleague a couple of months ago. The number of points that you should pay attention to is mind boggling: Don't #include unnecessarily, do forward declare as much as possible (but what can be forward declared is hard to understand even for experienced programmers), #include your own API header first to prove that it's complete (and good luck!), don't forget header guards, don't reuse header guards, etc. etc. This is just efficient header file usage! We haven't started coding yet!
My friends, the emperor doesn't have clothes. C++ simply is not a tool that is designed well. People who choose it do so because they have to or they are masochists. (True story: I asked a relatively young Google meetup presenter once why he was using C++ instead of a modern language and he said "because it is hard".) C++ separates the elite from the masses; I used to strive to be a C++ elite; I am not interested a bit anymore; I want to write useful programs with D; and I do.
D is niche only because humans are populists. We are not encouraged to use tools (or products) that are designed better. We follow popular leaders. It takes one some time to find his or her own voice to reject bad products and use only good ones. I am extremely lucky to work for a company that allows me to use D to write useful products.
I still take the same joy from programming that I did when I first learned it.
Then there is the human aspect of it: I want to be associated with real people isntead of snobby elites. (Remember how C++ was marketed at around 2000? "Yes, C++ is hard but it was never meant to be for normal programmers anyway." Ha ha ha! I am old enough now to reject that mentality. Bad design is bad design my friends; you can't defend it by blaming the user for not being elite.)
I can go on and on...
Now it's my turn to ask: Why would anyone choose C++ for their projects despite the production costs that it brings? None of your programmers really know it; they introduce hidden liabilities in the projects, their source code become non-refactorable monsters. Why waste that money on C++ when you can produce products easily. Products that just work...