On Thursday, 10 December 2015 at 08:43:21 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 10 December 2015 at 05:20:26 UTC, Joakim wrote:
I don't see why others are so concerned about it. A better
use of their time would be to chip in themselves, on
documentation or whatever else they're capable of contributing.
I think the primary concern is "what is the plan?". Without a
clear plan it really doesn't matter what you do or not do as an
individual with just a few hours per week.
I agree that a plan needs to be articulated. I hoped to get
something like that from the vision statement, but broad goals
like improving quality or fostering participation are pretty
useless. It should have gone into concrete detail on how they
favored accomplishing those broad aims, say by better integrating
Panteleev's Digger and other tools into the build process or
improving the documentation about getting started on developing D
itself.
Perhaps they've been burnt in the past by putting time into
writing out concrete plans for D and nobody taking up those
tasks- I don't know- but at the very least there should be a
central place where others can see the core team's prioritized
TODO lists. Martin has done great work getting some of the core
team on trello, but Walter and Andrei do not seem to use it:
https://trello.com/b/XoFjxiqG/active
Anyway, even without a plan, we can see from past commits on the
backend alone that it's not a time suck.
It's like voting or volunteering for a party with the right
ideas, but no clear strategy for getting into position. The
second concern is that people evaluate performance based on the
official compiler. They evaluate Go, not gccgo, and they
evaluate dmd, not ldc with an older frontend. This happens
repeatedly when people write about these languages.
Hopefully, the recent change to the Downloads page to point out
that dmd is faster to compile while gdc and ldc produce faster
code will change that. I think you underestimate how much of a
selling point dmd's speed is, even if I personally will not be
able to use it on Android/ARM.
sweet spot in every market. Perhaps those are better tools
for those markets, while D will hit different segments of
those markets and new markets altogether.
That required a strategy. Like, I am now likely to pick up C
again, just to be able to build tight asm.js. WebGL is now
becoming mature and asm.js is becoming a massive target, but it
takes a focused group to do better than emscripten... So you
need a central strategy in order to organize something like
that.
Personally, I think that entire web platform is stupid, so I
don't care that D doesn't target it. Mobile and embedded is a
_much_ more important target and we're making headway there. Dan
recently got the D tests running on the Apple tvOS and watchOS
simulators: soon you'll be able to run D on your TV or watch! :)
I agree that Swift is a strong competitor, as I've been
saying, but it is currently way behind D in platform support,
ie currently just iOS, OS X, and largely done linux/Glibc.
Each has their pros and cons and will garner their own
adherents.
Swift may need 1-2 more years, but if people can replace two
languages with one, then they have a strong adoption card. But
I am not sure if Swift will be able to gain C speeds
consitently, though I would not bet on it.
Well, right now, D is on far more platforms, so it has a head
start, though alpha quality on mobile. I'm sure Swift will try
to compete, but Apple is not going to port it to Android and
it'll be interesting to see how much outside contribution they
get, considering Apple is the largest company on earth and people
don't really want to do their work for them. D, without large
corporate support, actually doesn't have that problem, ie a giant
company pushing an OSS project is a double-edged sword.
The first time Apple tried to spur an OSS community with Darwin
and their base OSS tools, it never took off, with Apple only
providing open-source code dumps ever since. It's only later
efforts like WebKit, now forked by google for Chrome and Android,
and llvm that have built OSS communities. While Swift has a
better chance, since it comes from the llvm group, it will be
interesting to see how much outsiders contribute to it.
But it is rather obvious that being similar to Swift is not a
good strategy. If languages get too close, then the better
ecosystem wins.
You assume that they're very similar and that Swift will have a
better ecosystem eventually. They are _somewhat_ similar but
different enough to attract different devs, and I pointed out
above why they might not be able to grow their community much
larger.
