Can vibed be fast as Go or Python?

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 28 March 2017 at 08:08:11 UTC, Russel Winder wrote:
> On Tue, 2017-03-28 at 07:32 +0000, Suliman via Digitalmars-d 
> wrote:
>> I found very interesting Python async framework japronto 
>> https://github.com/squeaky-pl/japronto
>> 
>> Test show that in some cases japronto may work as fast as Go.
>> 
>> Can vibed be competitor (or even better) than Go and Python for
>> micro-services?
>
> Go is clearly a big player in the arenas where microservices is 
> a key word. Python less so. Do not forget that JVM and JVM 
> languages are the biggest players – well at least in the areas 
> I have association with. Also C#/F# are players, of course.  
> This is maybe why Go is becoming a big player there, just as it 
> has in Web applications.
>
> Node, at least in the microservices arena I have association 
> with, is not a big player: single threaded event loops without 
> processes are seen as a liability not a benefit. Multi-threaded 
> services are still the expectation, and a further reason why Go 
> is taking share from the JVM languages – no callback hell.
>
> The JVM languages (and to a lesser extent C#/F#) are though 
> deeply embedded in the psyche of most people "doing 
> microservices". It is harder to get them to switch that for 
> them to write a new framework.
>
> Go has created market share by some people who were believers 
> in Go doing stuff and then telling people about it, preferably 
> in JVM or .NET oriented conferences.
>
> So the question is: has anyone done microservices with 
> D/Vibe.d, and have they been talking about it at Go, JVM, and 
> .NET conferences?

One has to know oneself, ones strengths and weaknesses,  when 
trying to persuade another. At this stage in its development, D 
is much more appealing to places that have a technical mentality 
where people can afford to make decisions based on merits and 
afford to take calculated risks where the true economic downside 
is much smaller than the social cost of doing something 
unconventional and not getting it right on the first attempt. It 
seems to me that characterises the situation of those I have met 
in the D world who add using it within the enterprise.  Maybe 
that's true of many people at those conference circuits, but I am 
not sure if it's the case.  If one doesn't have the ability to do 
this kind of thing, one shouldnt try - so these sorts of people 
will be later adopters by which time the ecosystem will be more 
mature and it will be a socially respectable thing to use D.

In the meantime it's an opportunity for those who are able to 
make decisions based on genuinely technical questions and for 
whom the social factors mean you simply need to explain it, and 
where you have the social context where its okay to get some 
things visibly wrong now and then - but you need to have earned 
this, and keep earning it, obviously.

I do use D services written in vibe for my stuff.  My 
responsibilities have increased lately, so now there are things I 
look after that are written in some of those other languages.  
But at the margin I am doing more in D, not less.  The immaturity 
of the ecosystem is sometimes frustrating - notably for us with 
dub - and I do what I can to contribute, but then I go look at 
something written in another language and I think it would really 
be so much simpler had it been in D.  I was talking about this to 
John Colvin earlier and I think the main benefit of D is a 
cognitive one.  It's much easier to have abstractions that fit 
the problem domain and have an intuitive meaning that makes it 
easy to reason about; and yet these abstractions don't hide 
what's going on from you.  We have these words on the front page 
- modelling power and plasticity.  If you know what they point to 
they are good words, but they are not very evocative if you don't 
already get it. I think those things plus performance and control 
are where D shines, but they favour an organic kind of growth 
because recognising the importance depends on having good taste, 
and most people don't have good taste so they rely on other 
people to be their arbiters and that's a process that converges 
to reality, but slowly in the beginning.  I don't think for most 
people C# and D are competitors, for example.

>
> The line to take to do this is to do the same service in 
> D/Vibe.d and one of Go/Java/Clojure/Kotlin/Scala/C#/F# and then 
> do a session at an appropriate conference showing how D/Vibe.d 
> is better and thus that Go/Java/Clojure/Kotlin/Scala/C#/F# 
> needs to be improved in this area. I.e. do not present D/Vibe.d 
> as the solution, but as the threat.

Why would you want to encourage people to take you seriously as a 
threat  when you are a stealth emerging technology?  You just 
give others motivation to put a tick in the box, when the other 
stuff is unlikely to change because of cultural questions.  You 
want to tell them the truth, which is that in the current year, D 
isn't a language for everyone, but for a certain group it really 
is, and that happens to be a set of people that for other reasons 
punches above their weight over time.  It's elites that drive 
things in the beginning, not broad movements.

Education isn't a bad idea, but I think hearing from people who 
are using it to do things is most powerful in persuading people 
at this stage.  So the talks from Ethan of Remedy and Liran of 
Weka were very important

I think Walter's insight gained from practical experience applies 
here.  Don't try and make people love you who aren't minded that 
way anyway.  Instead find people who are looking for just what 
you do, and maybe use D already and would like you do more, but 
there is some obstacle.

Maybe D users in the enterprise should organise themselves a 
little because perhaps there are some such obstacles and 
frictions that are well worth solving and it's simply a 
coordination problem to figure out how. Reality isn't potentially 
Pareto optimal and life always falls short of the production 
possibility frontier. That's probably best done at this stage by 
people talking to each other directly and collaborating on things 
rather than starting with something formal.

Laeeth