On Fri, Jan 14, 2022 at 01:19:01AM +0000, forkit via Digitalmars-d-announce wrote: [...] > C provides even greater autonomy over both C++ and D. And I'd argue, > that's why C remains so useful, and so popular (for those problems > where such a level of autonomy is needed). > > By, 'autonomy', I mean a language provided means, for choosing what > code can do, and how it does it. [...] > An aversion to losing that autonomy, I believe, is a very real reason > as to why larger numbers of C++ programmers do not even consider > switching to D.
How is using D "losing autonomy"? Unlike Java, D does not force you to use anything. You can write all-out GC code, you can write @nogc code (slap it on main() and your entire program will be guaranteed to be GC-free -- statically verified by the compiler). You can write functional-style code, and, thanks to metaprogramming, you can even use more obscure paradigms like declarative programming. If anything, D makes it *easier* to have "autonomy", because its metaprogramming capabilities let you do so without contorting syntax or writing unmaintainable write-only code. I can theoretically do everything in C++ that I do in D, for example, but C++ requires that I spend 5x the amount of effort to navigate its minefield of language gotchas (and then 50x the effort to debug the resulting mess), and afterwards I have to visit the optometrist due to staring at unreadable syntax for extended periods of time. In D, I get to choose how low-level I want to go -- if all I need is a one-off shell script substitute, I can just allocate away and the GC will worry about cleaning after me. If I need to squeeze out more performance, I run the profiler and identify GC hotspots and fix them (or discover that the GC doesn't even affect performance, and redirect my efforts elsewhere, where it actually matters more). If that's not enough, GC.disable and GC.collect lets me control how the GC behaves. If that's still not enough, I slap @nogc on my inner loops and pull out malloc/free. In C++, I'm guaranteed that there is no GC -- even when having a GC might actually help me achieve what I want. In order to reap the benefits of a GC in C++, I have to jump through *tons* of hoops -- install a 3rd party GC, carefully read the docs to avoid doing things that might break it ('cos it's not language-supported), be excluded from using 3rd party libraries that are not compatible with the GC, etc.. Definitely NOT worth the effort for one-off shell script replacements. It takes 10x the effort to write a shell-script substitute in C++ because at every turn the language works against me -- I can't avoid dealing with memory management issues at every turn -- should I use malloc/free and fix leaks / dangling pointers myself? Should I use std::autoptr? Should I use std::shared_ptr? Write my own refcounted pointer for the 15th time? Half my APIs would be cluttered with memory management paraphrenalia, and half my mental energy would be spent fiddling with pointers instead of MAKING PROGRESS IN MY PROBLEM DOMAIN. With D, I can work at the high level and solve my problem long before I even finish writing the same code in C++. And when I need to dig under the hood, D doesn't stop me -- it's perfectly fine with malloc/free and other such alternatives. Even if I can't use parts of Phobos because of GC dependence, D gives me the tools to roll my own easily. (It's not as if I don't already have to do it myself in C++ anyway -- and D is a nicer language for it; I can generally get it done faster in D.) Rather than take away "autonomy", D empowers me to choose whether I want to do things manually or use the premade high-level niceties the language affords me. (*And* D lets me mix high-level and low-level code in the same language. I can even drop down to asm{} blocks if that's what it takes. Now *that's* empowerment.) With C++, I HAVE to do everything manually. It's actually less choice than D affords me. T -- People tell me I'm stubborn, but I refuse to accept it!