On Tuesday, 7 June 2016 at 08:57:33 UTC, Russel Winder wrote:
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.
For me a much bigger issues are:
- Smaller power of the language with GC switched off.
- Mixing GC and noGC is still experimental thing that few experts
know how to do properly.
Better GC is not a bigger issue for me as I'm not going to use
much of it.
Better GC is of course advantageous for adoption, I just have a
strong impression that there are more important things, like
nailing easy setup of editors, and providing a guide for
programming **without** the GC and for mixing GC and NoGC.
You have to distinguish switching GC off (that implies 2
languages, 2 communities, 2 separate standard libraries, all with
some overlap) from being able to mix GC and non-GC code in the
same program. The problem is that AFAIK the second is not a
viable methodology outside a tightly controlled environment,
where you select used libraries very carefully and limit their
number.
(...)
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.
I'm trying to be as far from abstract as I can. Having GC is
hardly a unique selling point. As for switching it off, see
issues above. After they are solved to a point when experts can
get noGC stuff done easily, it will be a USP.
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.
For some people native is necessary. For them D is the way to get
productive. Others ideally would use D as well but currently
there are more productive options for them, like C# or python.
[…]
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.
There's nothing wrong with discussing unittesting on its own. In
fact, this is very relevant because its the unittesting that D
makes easier. More coarse-grained testing can be done as easily
in any other language - you just make some executables for
various subsystems and variants of your program and run them in
test scenarios.
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.
As long as those are improvements in getting started fast and
time-to-market for D apps, than yes, and that's probably 10 times
more important than the both slow GC and poor noGC 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.
I don't think that third-party libraries can have the reach of
Phobos libraries. Also, things as basic as strings should be in
the standard library or language, otherwise the whole idea of
using D looks ridiculous. Having said that, third-party libraries
can help.
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?
I think those things can be easily done by individuals as well,
as long as pull request are accepted. But of course until someone
steps up... :)
