GopherCon 2014

Buenas prácticas para crear sistemas de alto rendimiento con Go

Derek Collison  · 

Presentación

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

I was introduced as the CEO of EPs era but hopefully that won't freak anybody out I'm going to talk a lot about some low-level high performance messaging systems that I've built in the past a little bit about me of why you would even listen to

me about messaging systems my architect didn't built a lot of the high speed messaging systems for TIBCO both rendezvous and EMS which was the enterprise messaging system a JMS system I also designed and built cloud foundry the original version of that

at VMware and was at Google for about five years and was feeling a lot of the pain that Rob was going through with I didn't have 45-minute builds but I had about 30 minutes and I had three gig you know Java big blobs of things that we were trying to move

around and so when I was leaving Google and I saw that you know go was actually going to come out I immediately started playing with it quite a bit so why go I think everyone in this room and this is pretty exciting by the way I'm gonna take a picture

really quick of why that's pretty cool you like the language is in you know you're here that's why especially for a first conference I have seven hundred people with Brian and Eric setting this up it's a simple compiled language has a great

standard library the concurrency angle that Rob talked about is important it's a synchronous programming model so I played a lot with nodejs and for very small things I actually liked it quite a bit was into Ruby for a long time as well but spent the majority

of my career in C low-level C which I still have a fond heart for but moving from an asynchronous callback baked based methodology which by the way I've actually implemented in C on purpose the synchronous programming model on the co routines that are

in Go was really nice garbage collection was important to me but the thing that really got me excited about go was stacks I used Java when it was called oak and it was a supposedly built for a control language for set-top boxes and I really didn't understand

why everything had to be on the heap stacks make a lot of sense right you can use them they're very very important the fact that go had them for me was a really really big deal why go well it's not seen C++ I'm not a fan of C++ never have been

and he kept getting more and more onerous and harder to actually work with and it's not Java or any JVM based language I think some of the most amazing low-level computer science technology came out of Sun around Java because of the fact that everything

was they on the heap and what was really neat to me was when go came out it had a very very you know old-style sweet mark-and-sweep garbage collector because it had stacks and the first program I ever wrote was I want to test that the stacks were real then

that they didn't touch the heap they did a little bit on promotion and things like that but I was really really impressed with why that was it's also not Ruby Python or nodejs no disrespect to Python but I got bit really bad at Google in a production

push on white space that was not where I was supposed to be yet I had passed my code on it and got the coach MIT's for Python I still love Ruby I like playing around with it deploying it into a production system and doing the dependency management on the

fly like we did to Cloud Foundry was very very painful and difficult and unless you're pushing into dynamic libraries and and see structures or see libraries go build static executables so if you're running a production system your deployment mechanism

over simplified a little bit but it's still true is SCP right copy it there and you're away you go which is really nice and again nodejs I still like JavaScript but once you get very very big the the callbacks spaghetti gets hard for people to understand

and maintain and understand and reason about even like a week after they wrote the the code some of you might have seen this I usually don't do any of these type of things but I felt really strong about the pain I had gone through trying to design deploy

and manage the production system around Cloud Foundry built in Ruby and the fresh air of go made me put a tweet out like this which I put out on September 11th of 2012 that said I believe there's going to be the dominant language for you know cloud infrastructure

systems infrastructure paas orchestration whatever was the buzzword bingo at the time and you figure we're only about about three months away or so four months away from that two-year mark but the fact that there's so many people here is pretty pretty

amazing in terms of how it's come up so what about high performance there's a messaging system that I wrote to underlie Cloud Foundry called Nats I've been doing messaging systems for about 25 years so it's an open source MIT Friesen beer open

source lightweight publish/subscribe distributed queueing messaging system and it serves the control plane basis for a lot of the distributed systems architectures that I've built including Cloud Foundry Baidu uses it quite a bit and of course the stuff

we do at UPS arrow so it's subject base meaning messages are routed based on subjects and subject hierarchies with wildcards it has the notion of publish/subscribe which again I don't think for a lot of applications is an endpoint consumable anymore

but since go is more around the system's language I thought it was interesting to talk about what we did with it this tcp/ip overlay it's not udp-based multicast based which I participated and and dealt with and helped kind of form you know in the

routers of the current big iron so to speak the only thing that single path these days is tcp/ip and with 40 gig and Hunter gig on the horizon or actually there on the optical side it doesn't make a lot of sense to actually charge you anything special

[ ... ]

Nota: se han omitido las otras 2.893 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.