Where will D sit in the web service space?

[via Digitalmars-d]

On Tuesday, 14 July 2015 at 05:00:47 UTC, Laeeth Isharc wrote:
> On Tuesday, 14 July 2015 at 00:22:21 UTC, Ola Fosheim Grøstad 
> wrote:
>> On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:
>>> Today, one wouldn't want to build a business around depending 
>>> on Andrei's allocator.
>>
>> Not really sure what you are referring to.
>
> It will be dependable soon enough, so I wanted to head off any 
> discussion centred around it not yet seasoned.

As I've written elsewhere. Ready-made-library-allocators don't 
solve any real world challenges I have.

I can make do with malloc and mmap where needed. I can write my 
own specialised allocator in 10-20 minutes, which I almost never 
need, and which is much more likely to perform well than a 
library solution since it is written for a specific scenario.

What makes D "need" library-allocators is that it was designed 
for having a GC and is perhaps over-focusing on generic 
programming that is agnostic to GC/non-GC. That may or may not be 
an interesting experiment, but it does not solve many real world 
problems. It might solve some problems D have aggregated by not 
addressing the GC issues at an early stage.


> bang! - when I am done.  In addition there is instrumenting etc 
> built into the allocators that I suppose will help track down 
> many kinds of problems.

If the language makes problems related to memory a likely issue, 
then you are already in a worse position than the competing 
solutions where such issues are very very unlikely. That means 
you are off-the-map.

There's a big advantage in having a coherent compiler-backed 
memory model and let the compiler optimize transparently based on 
static analysis, profiling and hints. That's basically what all 
high level languages should and do aim for.

(C is not a high level language)


> problem.  I suppose implicitly from what you write it must be 
> for web services on a large scale, and if you have anything you 
> can point me to on this then I would be curious to see it.

It applies to all scales. It has to do with having a system that 
is robust to modifications and affords agile evolutionary 
development over time.

Web services are updated, modified and extended several times 
every year over many years sometimes on short notice. Glitches, 
and especially hard to track down glitches, are very bad.

One good reason for going for a statically typed language with 
solid memory management is to get close to zero glitches with 
less development time spent on development, testing and debugging.

So if you cannot have a GC, then you need another solution that 
is equally robust, which is what new no-GC languages like Rust 
and Pony try to offer. That does give  them an advantage.


Client side game development has completely different 
requirements since you don't have to ship on a few hours notice 
if the architecture is reasonable. So I agree with weaselcat that 
D could be better of gearing itself towards that use scenario 
where linear typing is more likely to be a liability than an 
advantage.

But either way, you have to provide a feature set that maximise 
utility within a domain that is sizeable in order to grow an eco 
system. Otherwise you get all these libraries with 1-2 developers 
behind them that end up rotting because nobody are willing to 
maintain them long term.