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?

Dne 28.3.2017 v 09:32 Suliman via Digitalmars-d napsal(a):

> 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?
Yes, it should be possible to make vibed as fast as Go or Python (or even faster)

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?

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2017-03-28 09:32, Suliman wrote:

> Can vibed be competitor (or even better) than Go and Python for
> micro-services?

I create a test at work, compared an existing Ruby implementation of an API end point to a Go implementation and a D implementation. The D implementation was five times faster. Unfortunately my colleagues paid more attention to the result that showed that the Ruby implementation was twice as fast as the Go implementation.

-- 
/Jacob Carlborg

On Tuesday, 28 March 2017 at 18:16:49 UTC, Jacob Carlborg wrote:
> On 2017-03-28 09:32, Suliman wrote:
>
>> Can vibed be competitor (or even better) than Go and Python for
>> micro-services?
>
> I create a test at work, compared an existing Ruby implementation of an API end point to a Go implementation and a D implementation. The D implementation was five times faster. Unfortunately my colleagues paid more attention to the result that showed that the Ruby implementation was twice as fast as the Go implementation.

In their defence, that was far more surprising ;)

Atila

On Tuesday, 28 March 2017 at 18:16:49 UTC, Jacob Carlborg wrote:
> On 2017-03-28 09:32, Suliman wrote:
>
>> Can vibed be competitor (or even better) than Go and Python for
>> micro-services?
>
> I create a test at work, compared an existing Ruby implementation of an API end point to a Go implementation and a D implementation. The D implementation was five times faster. Unfortunately my colleagues paid more attention to the result that showed that the Ruby implementation was twice as fast as the Go implementation.

I'd be really curious to know what performance of the Ruby implementation would be like in Crystal (which might mean changing, but I don't know).  They seem to somehow quite often top language benchmarks, though it's hardly a mature language and ecosystem.

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

On Tuesday, 28 March 2017 at 07:32:15 UTC, Suliman 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?

http://dconf.org/2013/talks/panteleev.pdf

On Tuesday, 28 March 2017 at 18:16:49 UTC, Jacob Carlborg wrote:
>
> I create a test at work, compared an existing Ruby implementation of an API end point to a Go implementation and a D implementation. The D implementation was five times faster. Unfortunately my colleagues paid more attention to the result that showed that the Ruby implementation was twice as fast as the Go implementation.

If this could be found in a very short blog post we could share it on LinkedIn and stuff.

On 2017-03-28 22:59, Atila Neves wrote:

> In their defence, that was far more surprising ;)

Yes, for me as well. Unfortunately that took the spotlight away from D :(

-- 
/Jacob Carlborg