Where will D sit in the web service space?

[via Digitalmars-d]

On Saturday, 18 July 2015 at 02:45:54 UTC, Laeeth Isharc wrote:
> On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
> wrote:
>> For what domain is D the best choice?
>
> You are switching the question without recognizing this - some 
> kind of fallacy of composition.

There is no fallacy here.

You cannot compete until you have something that is the best 
possible starting point for a range of commercially- or 
community-backed frameworks.

You don't have growth until you have clearly increasing presence 
on Github and StackOverflow.


> time and location.  There aren't only a few sensible choices 
> for hedge fund data processing generally.  It's a big world, 
> and there are many more variations between the needs of 
> different teams than it is possible to imagine.

Large scale batch-processing cannot drive adoption. Specialized 
solutions like Chapel and C++/extensions will take the 
batch-throughput market.


> The work of Austrian economists on entrepreneurship demonstrate 
> that it simply is not possible to know which people will use a 
> product and how.  The future is unknown, if not unimaginable.

It isn't. The historical success-stories within the domain of 
programming languages are pretty clear.


> The bigger picture is not D in a death match with any 
> identifiable languages.

All languages are on a long-tail death match against all the 
other languages. History is pretty clear on that too.

It is long-tail because legacy source code bases will keep the 
languages alive until the product is replaced.


> If you presume programmer productivity is the only thing that 
> matters and treat efficiency like a free resource, it's a dead 
> cert that at some point efficiency will no longer be free.

More and more problems are solved by less and less efficiency. 
Development time, reliability, maintainability, evolution and 
perceived responsiveness are the most important factors.

In the 80s lots of software was close to theoretical throughput. 
Today, almost no software is anywhere close, because it is waaaay 
too expensive in terms of developer time as code base sizes 
increase.

D's primary selling point is that it is more familiar to C++ 
programmers than Rust. But there are other C++-like languages 
that are getting to the same technical quality (thanks to LLVM).


> probably at that point, and that Facebook's experience with 
> tradeoffs is not an edge case, but a leading edge for what more 
> people will experience in future.

No, in the future the processor will be integrated with RAM. 
You'll have lots and lots and lots of local processing power. The 
bottleneck will be communication between compute-nodes. (It 
already is, in many settings.)


> Furthermore, just rhetorically, gentle and constructive 
> suggestions for improvement that come from within are likely to

D has a chance to gain adoption by picking a direction and 
focusing on improving the process. But it is a long road, that 
also requires some cleanup of language.