www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can vibed be fast as Go or Python?

reply Suliman <evermind live.ru> writes:
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?
Mar 28
next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
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)
Mar 28
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-03-28 at 07:32 +0000, Suliman via Digitalmars-d wrote:
 I found very interesting Python async framework japronto=C2=A0
 https://github.com/squeaky-pl/japronto
=20
 Test show that in some cases japronto may work as fast as Go.
=20
 Can vibed be competitor (or even better) than Go and Python for=C2=A0
 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 =E2=80=93 well at least in the areas I have association wit= h. 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 =E2=80=93 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Mar 28
parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
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
Mar 28
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 29 March 2017 at 02:36:37 UTC, Laeeth Isharc wrote:

 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
That's exactly the best strategy: I strongly agree.
 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.
Do you have some practical suggestion on that? --- Paolo
Mar 29
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 28
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Mar 28
parent Jacob Carlborg <doob me.com> writes:
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
Mar 28
prev sibling next sibling parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
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.
Mar 28
parent Jacob Carlborg <doob me.com> writes:
On 2017-03-29 03:59, Laeeth Isharc wrote:

 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.
The Ruby implementation is pretty tied to Ruby on Rails, so unless Crystal can run Rails, it would be difficult to do a direct translation. -- /Jacob Carlborg
Mar 28
prev sibling next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
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.
Mar 28
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-03-29 08:09, XavierAP wrote:

 If this could be found in a very short blog post we could share it on
 LinkedIn and stuff.
Everything is closed source so I cannot share the source code. -- /Jacob Carlborg
Mar 28
parent XavierAP <n3minis-git yahoo.es> writes:
On Wednesday, 29 March 2017 at 06:54:21 UTC, Jacob Carlborg wrote:
 On 2017-03-29 08:09, XavierAP wrote:

 If this could be found in a very short blog post we could 
 share it on
 LinkedIn and stuff.
Everything is closed source so I cannot share the source code.
I think even only the performance comparison charts would be interesting... Then one can always link to other generic D and Vibe resources.
Mar 29
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/28/2017 08:16 PM, 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.
Just a matter of proper plotting ;). In German, but very funny http://katjadittrich.de/, pies of truth :). But seriously I can highly recommend to learn ggplot2, makes nice plotting easy and is actually worthwhile to learn. There is even a D version http://code.dlang.org/packages/ggplotd, though that one could use some string mixin DSL to reach R's brevity. -Martin
Mar 30
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
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
Mar 28
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/28/2017 09:32 AM, 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?
The answer is clearly yes, it's possible to build services that are significantly faster in D than in most other languages. The only thing that could be avoided w/ vibe.d, at the cost of a horrible callback based API, is the tiny stack switching overhead of Fibers (which go uses as well). Usually none of that matters as services are either I/O or processing bound. For the processing D has a lot of means to avoid additional memory allocations and indirections necessary in go or Java (not to speak of dynamic languages), it also offers easy access to SIMD powered array operations, and can go as low-level as assembly (though you'll unlikely ever need that). https://github.com/libmir/mir-glas https://github.com/kostya/benchmarks Vibe.d currently undergoes a major rewrite of it's internals that should result in even better performance figures (http://dlang.org/blog/2017/03/01/project-highlight-vibe-d/, https://github.com/vibe-d/vibe-core). Truth to be told, while people in the D community tend to write very fast code by default, sometimes almost obsessively, a lot more engineering power went into other projects, e.g. go has a fairly complex and optimized Fiber scheduler. Yet the fact that small D projects are capable to hold their grounds against major projects w/ dozens of engineers is indicative of the sweet spot D hits combining performance + productivity. You might find Liran's talk helpful http://dconf.org/2016/talks/zvibel.html, basically you can get a competitive advantage out of choosing D, but should be prepared to contribute back to the ecosystem and community. Why not let us know a bit more about what Microservice you have in mind, so that we can give you a much more specific answer? - -Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJY3NYIAAoJELJzgRYSuxk5pvgP/iPBlVWJl58+ooH94xU3JAiW GeKsPDATGlEM9HCwRGUaoH3v/+lj1DaNX4g12q6o/uUNc8uhc2rapJ2Bbxp58y2c H3gcV1lA6EJbsVi1M+FipNoUpvfq1AvBb1+knpX7adgNiD7DGe9tUd116XlQqhRN heUD6VUodgbJYAa8g+48Buu1stIMKx0qoNRZYePzYtVBlxJcOyee5Qq1XvEGkyF4 VcsuLLkm6lh5WfVDk6QSeUtL7OCGKjYVBmkOxua5lojbCYhvlPjzO54dxQ9CgJ8R xV922RIl2WMHW+A6vBN/n63Z0alM2WTe0kIGuDsB4MUA9A59/nCbMdt9QCRRsIUk hiPBAan3DUQoyAEwl10tzWATIIXa9RNjWV8RAbH1Q/fS31rI6IeC/1SZ1/2Z+2gk 0XLv6clZfk1oj9eL80Ba2kH/Rr5Db2j5KcFDXgewwlhP+x9ajUdMkXw/3Wawa8ye cS6haKcUpkCLdxfKDpmuCMPMdn3uVNC7Xd/5wsphPXWGzvwfjIh1MKC+Tr4qfh9r IgTZu0Y/raFW7s4ef7UXAjfc9F8+1oLJQE4wA7xbZiXuboE5iyIIGaj7NQZF18CP aKV21LDnkX4Q+2fF8vA0TqxMMd6QbCe4WBrinKvid0E1FTcUT6Ed4zGKS3nmQAak o6ubj1zt0VsEEBFbXaeC =Upyx -----END PGP SIGNATURE-----
Mar 30