On Friday, 5 June 2015 at 14:17:35 UTC, Ola Fosheim Grøstad wrote:
On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer
wrote:
I think I'll go with Liran's experience over your hypothetical
anecdotes. You seem to have a lot of academic knowledge, but
I'd rather see what actually happens. If you have that data,
please share.
There is absolutely no reason to go personal. I address weak
arguments when I see them. Liran claimed there were no benefits
to migrating fibers. That's not true. He is speaking for his
particular use case, that is fine. It is easy to create a
benchmark where locking fibers to a thread is beneficial. But
it is completely orthogonal to my most likely D use case which
is in low-latency web-services.
There will be no data that benefits D until D is a making
itself look like a serious contender and do it well in
aggressive external benchmarking. You don't get the luxury to
choose what workload D's performance is benchmarked with!
D is an underdog compared to C++/Rust/Go. That means you need
to get that 10-20% performance edge in benchmarks to make D
look attractive.
I agree, but I dare doubt that a slight performance edge will
make the difference. There are load of factors (knowledge base,
infrastructure, complacency, C++-Guruism, marketing etc.) why D
is an underdog.
If you want D to succeed you need to figure out what is D's
main selling point and make it a compiler-based feature. If it
is a library only solution, then any language can steal your
thunder...
The "problem" D has is that it has loads of selling points. Rust
and Go were designed with very specific goals in mind, thus it's
easy to sell them "You want X? We have X!". D has been developed
over the years by a community not a committee. D is more like
"You want X? Yeah, we have X, actually a slightly improved
version of X we call it EX, and Y and Z on top of that. And A B C
too! And templates!" - "Sorry, man! Too complicated for me! Can I
just have a for-loop, please? Milk, no sugar, thanks." I know, as
usual I simplify things and exaggerate! He he he. But programming
languages are like everything else, only because something is
good doesn't mean that people will buy it.
As regard compiler-based features, as soon as features are
compiler-based people will complain "Why is it built-in? That
should be handled by a library! I want more freedom!" I know for
sure.
