Given that you are good at writing highly optimized, low-level code I wonder how you could support making D a GCed language. I, and countless other C/C++ programmers, rejected D outright because of the GC. It puts D in competition with C# and Go, not C/C++. I know you are passionate about making D a success and I think nothing sabotaged that more than the GC.
Rust (which has received a much more welcoming reception from the C/C++ crowd) has optional GC, you can choose to make an object GCed by choosing the GCed pointer type, but the standard library (in contrast to D's) is all about values/unique pointers/stack allocation and thus GC is really optional. Do you think D could adopt a similar model? I think this might be the only way to broad acceptance among the C/C++ people.
Getting back to D's GC, I want to point out that you made it extra unattractive by choosing an old clunky one, you just dropped in the ready made, generic Boehm GC. So D not only has GC, but a GC that is far from the state of the art.
If you started with a concurrent/incremental/soft real-time capable bleeding edge GC optimized for D maybe you could have succeeded with a GC too. You really need some impressive benchmarks if you want to sell GC to C/C++ programmers. But I hear nothing about D GC development, you still use the same GC most experimental/hobby languages use. High performance implementations (e.g. Java, .NET) all use custom GCs and for a reason.
Last but not least I have read a lot of horror stories about D's implementation quality, including in the official D forum which I occasionally read. Yet another major turn-off. I watched a video from that recent D conference where you also identified improving implementation quality as important. However, what has been done to achieve that? Simply saying "make it so" doesn't work. You need to change the process and/or the developers. Maybe a (larger) unit and regression test suite is in order, using static analysis tools on the code base, firing Walter ;P etc. Something needs to change for sure.
xhorrr17 karma
Given that you are good at writing highly optimized, low-level code I wonder how you could support making D a GCed language. I, and countless other C/C++ programmers, rejected D outright because of the GC. It puts D in competition with C# and Go, not C/C++. I know you are passionate about making D a success and I think nothing sabotaged that more than the GC.
Rust (which has received a much more welcoming reception from the C/C++ crowd) has optional GC, you can choose to make an object GCed by choosing the GCed pointer type, but the standard library (in contrast to D's) is all about values/unique pointers/stack allocation and thus GC is really optional. Do you think D could adopt a similar model? I think this might be the only way to broad acceptance among the C/C++ people.
Getting back to D's GC, I want to point out that you made it extra unattractive by choosing an old clunky one, you just dropped in the ready made, generic Boehm GC. So D not only has GC, but a GC that is far from the state of the art.
If you started with a concurrent/incremental/soft real-time capable bleeding edge GC optimized for D maybe you could have succeeded with a GC too. You really need some impressive benchmarks if you want to sell GC to C/C++ programmers. But I hear nothing about D GC development, you still use the same GC most experimental/hobby languages use. High performance implementations (e.g. Java, .NET) all use custom GCs and for a reason.
Last but not least I have read a lot of horror stories about D's implementation quality, including in the official D forum which I occasionally read. Yet another major turn-off. I watched a video from that recent D conference where you also identified improving implementation quality as important. However, what has been done to achieve that? Simply saying "make it so" doesn't work. You need to change the process and/or the developers. Maybe a (larger) unit and regression test suite is in order, using static analysis tools on the code base, firing Walter ;P etc. Something needs to change for sure.
View HistoryShare Link