On Mon, 2016-06-06 at 19:57 +0000, poliklosio via Digitalmars-d wrote: > […] > > I should have been more specific here. I mean I want to > elliminate GC in my code. I don't mind if you or anyone else uses > GC. Even I use GC languages when writing things like scripts, so > I'm not a no-GC-because-I-say-so person.
Indeed. D has a GC by default which can be switched off. This is good. That D needs a better GC is an issue. > Is it a unique selling point (USP) against C++ or Rust? I don't > think so. People who use the GC languages for business/scientific > apps don't care what is behind the scenes. Also, the relationship > between GC and productivity is a subtle point that requires some > CompSci background to grasp. I think D is far too complicated to > be marketed as even simpler than python or Go. Low-latency people > do care what is behind the scenes and they understandably want no > GC. That leaves high-performance high-latency people. If you > think you can find a niche there, fair enough, otherwise its not > a USP. My feeling is there is no point in over-thinking this, or being abstract. C++ can have a GC but doesn't. Rust can have a GC but doesn't. Python has a GC. Go has a GC. Java has a GC. D has a GC that you can turn off. That seems like a USP to me. Whether this is good or bad for traction is down to the marketing and the domain of use. > D's power is in its native-but-productive approach. This is an > improvement in C++ niches, not a simplified language for banging > end-user apps. Productive is way, way more important that native. […] > > Why would they not use D? D is a much better language for them as > well. To give some examples, in C++ code there is a ton of > boilerplate, while D code hardly has any. Also, the number of > bugs in a D program is smaller due to easier unittesting. Also, > templates don't cause day-long stop-and-learn sessions as in C++. > I don't think those people are a lost market. Can we drop the unit and just talk about testing. Unit, integration and system testing are all important, focusing always on unit testing is an error. As to why not use D? The usual answer is that "no else is using D so we won't use D" for everyone except early adopters. D needs to remanufacture an early adopter feel. It is almost there: LDC announcing 1.0.0, Dub getting some activity, new test frameworks (can they all lose the unit please in a renaming), rising in TIOBE table. This can all be used to try and get activity. However it needs to be activity of an early adopter style because there are so many obvious problems with the toolchains and developer environments. So let's focus on getting these things improved so that then the people who will only come to a language that has sophistication of developer experience. > This is a big issue now due to lack of a comprehensive guide, as > well as holes in the language and phobos (strings, exceptions, > delegates). C++ doesn't have those holes. Holes in Phobos can be handled by having third-party things in the Dub repository that are superior to what is in Phobos. Documentation, guides, and tutorials are a problem, but until someone steps up and contributes this is just going to remain a problem. One that will undermine all attempts to get traction for D. So how to get organizations to put resource into doing this? -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
