www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and microservices

reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
Has anyone got a small example of microservices using D, with Vibe.d or
otherwise, that I can make use of? I need some examples of small
microservices for a session at =CE=BCCon 2015.

--=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.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
Oct 06 2015
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with 
 Vibe.d or otherwise, that I can make use of? I need some 
 examples of small microservices for a session at μCon 2015.
As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
Oct 06 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with=20
 Vibe.d or otherwise, that I can make use of? I need some=20
 examples of small microservices for a session at =CE=BCCon 2015.
=20 As far as I know, there is no implementation of microservices as=20 we see in the Java world. IMHO, D community should come up with a=20 good microservices architecture. As you pointed out, it could be=20 based on vibed.
Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but=E2=80=A6 many pe= ople are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.=C2=A0 --=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.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
Oct 06 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
 On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with
 Vibe.d or otherwise, that I can make use of? I need some
 examples of small microservices for a session at μCon 2015.
As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but… many people are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.
Felt stupid for not being hip to this "microservices" thing you say, so just looked it up. But it sounds to me like it's basically just a buzz-driven rediscovery of the basic principles of proper encapsulation and Unix philosophy ("do one thing and do it well"). (Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted". Or "Facade design pattern" vs plain old "It's a thin wrapper".) Does that sound about accurate, or am I missing something?
Oct 06 2015
next sibling parent reply Mengu <mengukagan gmail.com> writes:
On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
 On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
 On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via 
 Digitalmars-d wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
 wrote:
 Has anyone got a small example of microservices using D, with
 Vibe.d or otherwise, that I can make use of? I need some
 examples of small microservices for a session at μCon 2015.
As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but… many people are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.
Felt stupid for not being hip to this "microservices" thing you say, so just looked it up. But it sounds to me like it's basically just a buzz-driven rediscovery of the basic principles of proper encapsulation and Unix philosophy ("do one thing and do it well"). (Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted". Or "Facade design pattern" vs plain old "It's a thin wrapper".) Does that sound about accurate, or am I missing something?
a half of it is the buzz and other half of is not. remember people talking about reactjs, go and rails being buzz? they were the same. we have built an online payment gateway and we are about to decouple our application and switch to microservices architecture. we have an api, a dashboard, a checkout page, mobile flow. we have to deal with accounting and reporting as well. and there is no way that this application will turn into a giant monolith. i don't want that. nobody wants that. it will become something we cannot handle. another thing is whenever we do deployments we have to take down the whole application and go offline. i know there are other workarounds but when we only want to deploy mobile payments or the api, other functionalities should continue working and our customers should be able to pay. nobody suggests starting with microservices architecture because you'll never know where things will lead you however when it becomes a giant the suggestion is to use microservices. one other benefit of using this microservice is that you don't have to look for specific language programmers. you only need to hire good programmers as the only requirement is to do one thing and and doing it well. the rest is about communication.
Oct 06 2015
parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
 a half of it is the buzz and other half of is not. remember 
 people talking about reactjs, go and rails being buzz? they 
 were the same. we have built an online payment gateway and we 
 are about to decouple our application and switch to 
 microservices architecture. we have an api, a dashboard, a 
 checkout page, mobile flow. we have to deal with accounting and 
 reporting as well. and there is no way that this application 
 will turn into a giant monolith. i don't want that. nobody 
 wants that. it will become something we cannot handle.
now a question for you. do you wish you had built it from components from day one? or do you see creating it as a blob to start with and then when the right divisions are clear factoring these out into micro-services as simply a natural part of the design process? because you know much more by having started, and it's not so hard to refactor at this stage.
 another thing is whenever we do deployments we have to take 
 down the whole application and go offline
pretend I'm asking you before it was deployed in production...
 nobody suggests starting with microservices architecture 
 because you'll never know where things will lead you however 
 when it becomes a giant the suggestion is to use microservices.
some people do. but I would have thought the point I made above is the real reason. it doesn't take very long to write it that way from the beginning IFF you know what you want it to look like before you start. and maybe you don't. but I am interested in what your experience has been.
Oct 06 2015
parent Mengu <mengukagan gmail.com> writes:
On Tuesday, 6 October 2015 at 23:01:43 UTC, Laeeth Isharc wrote:
 On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
 a half of it is the buzz and other half of is not. remember 
 people talking about reactjs, go and rails being buzz? they 
 were the same. we have built an online payment gateway and we 
 are about to decouple our application and switch to 
 microservices architecture. we have an api, a dashboard, a 
 checkout page, mobile flow. we have to deal with accounting 
 and reporting as well. and there is no way that this 
 application will turn into a giant monolith. i don't want 
 that. nobody wants that. it will become something we cannot 
 handle.
now a question for you. do you wish you had built it from components from day one? or do you see creating it as a blob to start with and then when the right divisions are clear factoring these out into micro-services as simply a natural part of the design process? because you know much more by having started, and it's not so hard to refactor at this stage.
it's the latter for me. i am glad we have everything coupled together. this way we are able to see what parts can live by themselves and what parts cannot. and when you're building a start-up, i hardly believe designing microservices is the way to go. if you have time, if you have resources then go and design your microservices architecture. take your time, use your resources. but i didn't. i was one man and i did not have the time. now we are 4 people. we are not adding new features anymore and we know what kind of future is out there for our application. right now almost 95% of our application can be decoupled, do not depend on each other in terms of code. they can just communicate and get things done. also it means more uptime, more developers, more resources, etc. we already have two microservices. one is for card vaulting and the other one is for end of day and cash report download/process service from the banks and other payment gateways. sometimes the industry you are in will push you that way. and... one of the most important things for me with microservices is that now I can get Haskell and D in our codebase. :-)
 another thing is whenever we do deployments we have to take 
 down the whole application and go offline
pretend I'm asking you before it was deployed in production...
 nobody suggests starting with microservices architecture 
 because you'll never know where things will lead you however 
 when it becomes a giant the suggestion is to use microservices.
some people do. but I would have thought the point I made above is the real reason. it doesn't take very long to write it that way from the beginning IFF you know what you want it to look like before you start. and maybe you don't. but I am interested in what your experience has been.
nobody, in their right minds, then. :)
Oct 07 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via Digitalmars-d
wrote:
=20
[=E2=80=A6]
=20
 Felt stupid for not being hip to this "microservices" thing you say,
 so=20
 just looked it up. But it sounds to me like it's basically just a=20
 buzz-driven rediscovery of the basic principles of proper
 encapsulation=20
 and Unix philosophy ("do one thing and do it well").
Yes there is an element of just using encapsulation and single purpose tool, but there is a lot of trying to do cluster computing well by keeping the components small and manageable. The downside is the potential communications complexity. BTW microservices doesn't mean just Web services/applications per se (they are a subset), it is any protocol. The Web services/applications people conveniently forget there are protocols other than HTTP.
 (Kinda like how "cloud" sounds like a big fancy new revolution until
 you=20
 realize it's just the hip new word for "internet" or "hosted". Or=20
 "Facade design pattern" vs plain old "It's a thin wrapper".)
"Cloud" is really a destruction of personal computing in favour of re- centralization of all computing: put the computing power back in the hands of the people who want to control what you may or may not do with computers. Beyond this is gets political.=C2=A0
 Does that sound about accurate, or am I missing something?
I think you are missing some aspects of why there is sanity to what is happening, but you are not wrong that there is a lot of "buzz" and "hype", but that tends to go along with anything "trendy" and "hip". And there is a lot of reinventing the wheel because the hipsters create cool new stuff, but have failed to study the last 60 years of computing before doing so. --=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
Oct 07 2015
parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:
 On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via
 (Kinda like how "cloud" sounds like a big fancy new revolution 
 until you realize it's just the hip new word for "internet" or 
 "hosted".
Yes - technically it is nothing new perhaps. But it's a commercial phenomenon, and so whilst the marketing hype is regrettable, if inevitable, it's the commercial aspects that are important here, much more than technical ones. Big technological shifts (speaking about things viewed from a societal level, not from a practitioner's perspective) have two components - big relative price shift (which might be infinite in practical terms to a large fortune or from cheap to very cheap depending on the situation), and then the new activities and new ways of doing old things that become possible as a consequence of this price shift. Business people take a long time to figure it out (see Brynjolfsson's work on organisational architecture), and that's why we have a period of hand-wringing between the new technology arriving and us seeing its broader benefits. Solow, an expert on growth, observed in 1987 that "computers are everywhere but in the productivity statistics". (My theory then was that people were too busy fiddling with fonts on their Macs to actually do any work!). A decade later, we had a different view of their influence. Similarly we have people saying today "how many jobs has Twitter created?". But it's not the people that Twitter directly employ, but those that benefit both from using it, and from the broader set of shifts of which Twitter is only the beginning. Blyth Masters, for example, is doing some interesting work on exploring possibilities from using blockchain type technologies for wholesale finance. There are some obvious problems there, but I wouldn't care to bet nothing interesting comes out of it. But it's much bigger than that, even though I can only be aware of a part of it. In any case, we have now inconceivable amounts of computing power on tap for very affordable prices and the tools to manage it. When a little instance is 0.7 cents an hour, and a usable one is 1.5 cents and you can scale up and down as quickly as you like, many things become possible that weren't before. The world is only slowly beginning to figure out what, judging by what I see in finance.
 "Cloud" is really a destruction of personal computing in favour 
 of re- centralization of all computing: put the computing power 
 back in the hands of the people who want to control what you 
 may or may not do with computers. Beyond this is gets political.

 Does that sound about accurate, or am I missing something?
Since I am foolish enough to run my own mail server, you can be sure that my sympathies are with you. I think people are reckless - both individuals and corporations - in what they unthinkingly cede to companies that really have few incentives to act as one might wish. It's one thing to be the customer, and quite another to be the product. I saw Eric Schmidt speak some years back, and he really didn't give me a feeling that we have a similar idea about what evil means! This being said, the world has always been broken in some respect, and we shouldn't let that stop us looking at the situation objectively even if one would wish in some respects things were other than they are. The cloud may be centralising things for the individual, but at the corporate level it's less clear. In particular, it's a classic case of the accounting being pretty clear that the economies of scale mean you should centralise IT infrastructure and it's management, but the practical experience of the people actually generating value within the enterprise often being rather different. Things even in quite small firms of 150+ people start being more about internal bureaucratic logic and much less about ROI. And the problem is that it's hard to make a convincing case for something that doesn't yet exist, and yet many big things have the tiniest beginnings. So the current enterprise technology environment discourages those little experiments that drive real innovation, as well as getting in the way of larger projects. The cloud, by commoditising compute, and making the price much more transparent then is a force for breaking down central structures that no longer serve their needs well. When you can get whatever you need from Amazon today, waiting months and paying 10x more starts to seem a little stiff, and people start asking questions when before they had no choice but to grin and bear it. Of course the questions about privacy and commercial confidentiality are there, but perhaps solutions are arriving, and business people need to be practical. Even an overpriced internal cloud gives much more power to internal entrepreneurs than did the old way.
 I think you are missing some aspects of why there is sanity to 
 what is happening, but you are not wrong that there is a lot of 
 "buzz" and "hype", but that tends to go along with anything 
 "trendy" and "hip". And there is a lot of reinventing the wheel 
 because the hipsters create cool new stuff, but have failed to 
 study the last 60 years of computing before doing so.
It may not be new, but it's new that it's so cheap and so easy. (And when any idiot can, any idiot will... Which is mostly for the best, but not always) Laeeth
Oct 07 2015
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 8 October 2015 at 06:43:24 UTC, Laeeth Isharc wrote:
 In any case, we have now inconceivable amounts of computing 
 power on tap for very affordable prices and the tools to manage 
 it.  When a little instance is 0.7 cents an hour, and a usable 
 one is 1.5 cents and you can scale up and down as quickly as 
 you like, many things become possible that weren't before.  The 
 world is only slowly beginning to figure out what, judging by 
 what I see in finance.
It is amazing how much compute is on tap these days and we do almost nothing with it. Forget about the cloud, just look at how powerful all these mobile devices are. The problem is that software development has lagged leagues behind hardware development.
 Since I am foolish enough to run my own mail server, you can be 
 sure that my sympathies are with you.
I used to do that, but what would stop them from getting into your server either? Just as they go after email hosts, they can go after server hosts. Unless you're running it out of your own house, which has other problems, most notably port-blocking by ISPs.
 I think people are reckless - both individuals and corporations 
 - in what they unthinkingly cede to companies that really have 
 few incentives to act as one might wish.  It's one thing to be 
 the customer, and quite another to be the product.  I saw Eric 
 Schmidt speak some years back, and he really didn't give me a 
 feeling that we have a similar idea about what evil means!
They are reckless until they're personally hurt by it. There will be a backlash when some scandal or hack forces people to change. The recent ad-blocking and router security scandals are good examples, both of which have been festering for a _long_ time: http://fortune.com/2015/09/20/apple-ad-block-ios9/ http://blog.codinghorror.com/welcome-to-the-internet-of-compromised-things/
 within the enterprise often being rather different.  Things 
 even in quite small firms of 150+ people start being more about 
 internal bureaucratic logic and much less about ROI.  And the 
 problem is that it's hard to make a convincing case for 
 something that doesn't yet exist, and yet many big things have 
 the tiniest beginnings.  So the current enterprise technology 
 environment discourages those little experiments that drive 
 real innovation, as well as getting in the way of larger 
 projects.
Interesting article along the same vein, that goes in a fairly radical direction until near the end, when it shifts course to point out how Apple is trying to account for this: http://www.asymco.com/2015/08/31/fluid-coupling/
 The cloud, by commoditising compute, and making the price much 
 more transparent then is a force for breaking down central 
 structures that no longer serve their needs well.  When you can 
 get whatever you need from Amazon today, waiting months and 
 paying 10x more starts to seem a little stiff, and people start 
 asking questions when before they had no choice but to grin and 
 bear it.  Of course the questions about privacy and commercial 
 confidentiality are there, but perhaps solutions are arriving, 
 and business people need to be practical.  Even an overpriced 
 internal cloud gives much more power to internal entrepreneurs 
 than did the old way.
Heh, a more centralized external cloud allows more agility than the centralized internal IT systems that were in place before? Perhaps. Given all the data breaches, I don't think the problems with data security will ever go away though.
Oct 08 2015
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
 Felt stupid for not being hip to this "microservices" thing you 
 say, so just looked it up. But it sounds to me like it's 
 basically just a buzz-driven rediscovery of the basic 
 principles of proper encapsulation and Unix philosophy ("do one 
 thing and do it well").

 (Kinda like how "cloud" sounds like a big fancy new revolution 
 until you realize it's just the hip new word for "internet" or 
 "hosted". Or "Facade design pattern" vs plain old "It's a thin 
 wrapper".)

 Does that sound about accurate, or am I missing something?
Heh, funny you say that, since Russel's post just got me to look up the term too. :) I had encountered the term before, when I was talking to a dev shop about a project earlier this year, but figured it was exactly what it sounded like and didn't bother looking it up till now. Looks like I was right. Whatever hype may be involved, at least they're re-branding something _useful_, just be grateful for that. ;) On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:
 (Kinda like how "cloud" sounds like a big fancy new revolution 
 until
 you
 realize it's just the hip new word for "internet" or "hosted". 
 Or
 "Facade design pattern" vs plain old "It's a thin wrapper".)
"Cloud" is really a destruction of personal computing in favour of re- centralization of all computing: put the computing power back in the hands of the people who want to control what you may or may not do with computers. Beyond this is gets political.
I wouldn't go that far. Users want to access their data from anywhere on their mobile devices, and given that those mobile devices can't store much, the cloud is just the most convenient place to put the data, now that 4G speeds are comparable to wired broadband from just a couple years ago (except for the much lower quotas on wireless, which only really limit you with video). You could have made the same argument a couple decades ago, that PCs were a step back from workstations, because the old UNIX workstations came with compilers and a toolchain that let you build your own software whereas you had to go get the tools for your PC, ie they weren't bundled. Some people make the same argument with the even more locked-down tablets today, where you can't even develop software using them. But the truth is that most PC users weren't developing software or exerting much "control" over their desktops/laptops, and almost nobody wants to develop software or create on a mobile device. They welcome more locked-down systems, because it lets them do the lighter tasks they actually want to get done much easier, without worrying about configuring the system just right, ie complexity, or viruses. However, I do agree with you that the cloud is way overplayed, just for different reasons. I think decentralized computing is going to take off instead, with a decentralized social network, like Diaspora except running peer-to-peer on your mobile devices, replacing centralized Facebook. Cloud will merely be one of the nodes in that decentralized network, one where you offload heavy computing activity or data that you need from everywhere else, but not the center of mass that many treat it as today.
Oct 07 2015
prev sibling parent reply extrawurst <stephan extrawurst.org> writes:
On Tuesday, 6 October 2015 at 17:54:48 UTC, Russel Winder wrote:
 On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via 
 Digitalmars-d wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
 wrote:
 [...]
As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but… many people are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.
I have never used Go, but isn't what you describe exactly what vibe.d is doing using Fibers ?
Oct 07 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2015-10-07 at 07:15 +0000, extrawurst via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 I have never used Go, but isn't what you describe exactly what=20
 vibe.d is doing using Fibers ?
As I understand it, vibe.d is a single threaded event-loop with fibres. In this sense it is equivalent in architecture to Node except that vibe.d allows for blocking fibres where Node required non-blocking approaches. Thus I would choose vibe.d over Node any day, except=E2=80=A6 Go has a task pool (goroutines), but underneath is a thread pool not a single thread. =C2=A0This means that multiple goroutines can be executing concurrently, that means in parallel (*). GPars has an approach similar to Go. Go is way more efficient though as it uses the kernel threads directly, GPars has to fight with the JVM threads. (*) It is a pity that computing and the rest of the world have different meaning for concurrent and parallel, it leads to lots of wonderful confusion. --=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
Oct 07 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 7 October 2015 at 10:48:02 UTC, Russel Winder wrote:
 On Wed, 2015-10-07 at 07:15 +0000, extrawurst via Digitalmars-d 
 wrote:
 […]
 
 I have never used Go, but isn't what you describe exactly what 
 vibe.d is doing using Fibers ?
As I understand it, vibe.d is a single threaded event-loop with fibres. In this sense it is equivalent in architecture to Node except that vibe.d allows for blocking fibres where Node required non-blocking approaches. Thus I would choose vibe.d over Node any day, except…
vibe.d supports multiple threads and will schedule tasks on separate threads if asked to. Each of those threads will in turn have several fibres. The main difference from Go's runtime for me are twofold: 1. vibe.d is a library, goroutines are part of the library 2. vibe.d (like D itself) uses the actor model, go is (sort of, according to some) CSP My "Go vs D vs C vs Erlang" MQTT shootout was based on a colleague claiming that Go would win because concurrency is its thing. I called his bluff since despite Go having a (AFAIK) very good scheduler, I didn't see how vibe.d wouldn't give me the same performance. I was right. Atila
Oct 07 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 7 October 2015 at 17:31:12 UTC, Atila Neves wrote:
 My "Go vs D vs C vs Erlang" MQTT shootout was based on a 
 colleague claiming that Go would win because concurrency is its 
 thing. I called his bluff since despite Go having a (AFAIK) 
 very good scheduler, I didn't see how vibe.d wouldn't give me 
 the same performance. I was right.
Yes, Go is unlikely to have any throughput advantages compared to a systems level programming language. Go's advantages: - a more mature compiler - robust runtime features - lower latency GC - infrastructure support - simple syntactical constructs I would consider Go-routines a convenience feature. If C++17 does stackless coroutines right then it probably will surpass both Go and D in terms of memory locality, initialization performance and memory usage; and therefore throughput as well.
Oct 07 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Wednesday, 7 October 2015 at 19:58:55 UTC, Ola Fosheim Grøstad 
wrote:
 If C++17 does stackless coroutines right then it probably will 
 surpass both Go and D in terms of memory locality, 
 initialization performance and memory usage; and therefore 
 throughput as well.
We might be able to reuse the existing delegate capture mechanism to create continuations. Then await would "simply" rewrite the rest of the body as delegate, similar to how the foreach body can be transformed into a delegate. There is some use-case for HPC code where stackless coroutines make a huge differences (used with a work stealing scheduler), for basic networking code it will only be a small difference.
Oct 07 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 03:12:03 UTC, Martin Nowak wrote:
 We might be able to reuse the existing delegate capture 
 mechanism to create continuations.
 Then await would "simply" rewrite the rest of the body as 
 delegate, similar to how the foreach body can be transformed 
 into a delegate.
Not sure how that works? What is needed is to preallocate a "continuation" that is large enough to cover all "stack allocated" state that has to be retained when the coroutine yields, at all yield points. But with reuse of memory for dead variables (like in optimized stack usage where you reuse stack memory that is dead). Then use those areas of the continuation during computation rather than the stack. So basically all functions that may yield have to be available for static analysis before you start up the coroutine and all reachable yield points have to be analysed. So you basically have one big stack frame at the "top of the stack" as a separate object (the "continuation") and everything that has to survive a yield has to go onto that frame. That's how I would do it anyway.
 There is some use-case for HPC code where stackless coroutines 
 make a huge differences (used with a work stealing scheduler), 
 for basic networking code it will only be a small difference.
The current D implementation can run out of stack. That's much less of an issue if the system/thread stack is used in combination with a fixed size preallocated "continuation".
Oct 08 2015
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with 
 Vibe.d or otherwise, that I can make use of? I need some 
 examples of small microservices for a session at μCon 2015.
What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.
Oct 06 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-10-06 at 18:56 +0000, Dicebot via Digitalmars-d wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with=20
 Vibe.d or otherwise, that I can make use of? I need some=20
 examples of small microservices for a session at =CE=BCCon 2015.
=20 What do you mean by microservice examples? It is infrastructure=20 methodology, not specific code thing, any simple network service=20 can be viewed as microservice.
At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,=E2=80=A6 packets. Basica= lly RESTful services. At a non HTTP level I guess you can say all networking is microservices except that you want a protocol over TCP/IP or UDP/IP and shouldn't there be frameworks to assist building these things? --=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
Oct 07 2015
next sibling parent Dicebot <public dicebot.lv> writes:
On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
 What do you mean by microservice examples? It is 
 infrastructure methodology, not specific code thing, any 
 simple network service can be viewed as microservice.
At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,… packets. Basically RESTful services.
Even web microservices are not necessarily RESTful ones. Nick has correctly pointed out that there is a lot of spiritual similariy between concept of microservice and traditional UNIX way of designing small single-purpose command lines apps. It basically gets down to "do as few things as possible in one application (but do it good) and build a pipeline".
 At a non HTTP level I guess you can say all networking is 
 microservices except that you want a protocol over TCP/IP or 
 UDP/IP and shouldn't there be frameworks to assist building 
 these things?
What utility would you expect from such framework?
Oct 07 2015
prev sibling parent Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
 On Tue, 2015-10-06 at 18:56 +0000, Dicebot via Digitalmars-d 
 wrote:
 On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
 wrote:
 Has anyone got a small example of microservices using D, 
 with Vibe.d or otherwise, that I can make use of? I need 
 some examples of small microservices for a session at μCon 
 2015.
What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.
At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,… packets. Basically RESTful services. At a non HTTP level I guess you can say all networking is microservices except that you want a protocol over TCP/IP or UDP/IP and shouldn't there be frameworks to assist building these things?
Zeromq plus msgpack or the like (maybe cerealed!) gives you quite a lot. I use nanomsg, which is still beta but nicer in some ways. In any case it gives you survey, request/reply, bus, publish / subscribe patterns. And it's very light and has decent throughput. What kind of framework were you thinking of ? (nanomsg doesn't do UDP, but I think zeromq does. You can write your own protocol or pattern if the existing ones don't work for you, and sounds like that's work, but not much more than it needs to be).
Oct 07 2015
prev sibling parent Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
 Has anyone got a small example of microservices using D, with 
 Vibe.d or otherwise, that I can make use of? I need some 
 examples of small microservices for a session at μCon 2015.
on your email, in case it fits. nanomsg and a little vibed
Oct 06 2015