On Thursday, 23 August 2018 at 04:46:25 UTC, Eugene Wissner wrote:
But this kind of development doesn't work anymore that well for
commercial customers that aren't (only) interested in research.
From this perspective D becomes over-complicated, half-finished
language. And nobody can tell what will be "in" tomorrow.
My point of view (as a tiny commercial user) is that D has
everything you need:
- a way to convert money into bugfixes with the new Foundation
deals
- it's pretty boring and predictable with upgrades, few surprise.
Each releases bring improvements, you get CI and docs for free
etc.
- future-proof. It's not a weaponized language, people love it
etc. It cannot be wiped out by a giant because it doesn't fit a
corporate agenda.
Of the real problems I think I see - and everyone sees those
differently:
A - D needs to keep generating drama (like this thread) to
storify its development and keep people active. It creates
engagement. A lot of the D marketing is very reasonable and that
doesn't cut it that much. Where is superdan?
B - sometimes bizzarre allocation of effort, that's probably part
of some unexplainable evil plan, but can at times feel like
counterproductive wrt marketing.
For example: why implement AVX in DMD backend? Who are the
users that will be delighted by that? Those interested in
performance already use some other back-end, it's imo a
completely useless development since _no one_ use D_SIMD
seriously apart from compiler tests
(https://github.com/search?l=D&p=4&q=D_SIMD&type=Code)
C - _absurd_ focus on the language, and in lesser part Phobos
instead of _community_ and DUB things (ie: libraries, making sure
they exist and make some sense while not putting more work on
core developers). What if the language was "good enough" while
the ecosystem wasn't?
Example:
A best example of this is std.experimental:
* "to develop something for std.experimental, put it on DUB
it will be able to be used and upgraded!"
* "to update something in std.experimental, put it back on
DUB it will be able to be upgraded while keeping
backward-compatibility!"
Example:
The solution is (still subjectively) obviously to offload as much
as possible to the community, simply because there are more
people making libraries than core developers so why core
developers should take ownership of an ever growing amount of
"big Phobos"?
Phobos shouldn't even be a thing, we always read "hopefully this
will be moved into Phobos" which is entirely wrong. People should
be pushed to use the community to their advantage. SemVer is
where it's at.
