Is GO fast enough for infrastructure programming?

<p>Hey guys,</p> <p>I&#39;m very interested and trying to break into infrastructure programming. I&#39;d like to develop infrastructure components such as loadbalancers, caches, etc...</p> <p>Most of the main stream tools are written in C, I&#39;m assuming for the speed and memory handling. </p> <p>I personally do not want to write in C, but I&#39;m totally willing to learn it if this is necessary. However would Go be an applicable language for this type of work also? I&#39;ve started playing around with Go and I love the syntax and concepts of the language thus far. </p> <hr/>**评论：**<br/><br/>mwholt: <pre><p>Go was designed for this.</p></pre>BraveNewCurrency: <pre><blockquote> <p>Is GO fast enough for infrastructure programming?</p> </blockquote> <p><a href="https://groups.google.com/forum/#!msg/golang-nuts/BNUNbKSypE0/E4qSfpx9qI8J">Yes.</a></p> <blockquote> <p>trying to break into infrastructure programming</p> </blockquote> <p>I am confused by this comment. You make it sound like Infrastructure Programming is a cabal that you break into. Instead, you should think of it as a skill that you learn. Infrastructure programming requires more knowledge than typical programming.</p> <blockquote> <p>I&#39;d like to develop infrastructure components such as loadbalancers, caches,</p> </blockquote> <p>Again, that&#39;s an odd thing to want. Do you have someone lined up to pay you to develop that? If not, your target should be to <em>learn</em> about infrastructure components. It&#39;s much more likely that companies will pay you to <a href="https://github.com/vulcand/vulcand">grab </a> one <a href="https://github.com/mholt/caddy">off</a> the <a href="https://github.com/golang/groupcache">shelf</a> instead of re-inventing the wheel.</p> <p>Don&#39;t get me wrong, I&#39;m not saying you shouldn&#39;t write those programs. Just that writing those is not an end, it&#39;s a means to an end of understanding infrastructure. If you have to ask others if a language is any good, you are too much of a novice to write the next great load balancer. But learning infrastructure programming will make you a better programmer.</p></pre>ldelossa: <pre><p>Well that&#39;s an interesting way of putting things. </p> <p>Right now I come from infrastructure architecture, for many years I&#39;ve setup off the shelf solutions, I&#39;ve designed load balancing tiers, data centers, countless networks and performant environments. I&#39;ve recently began to do a lot of development in this space also. I do a lot of coding for operational things.</p> <p>To me, my perfect job is now to move into the actual development OF these solutions, and I need to start somewhere. </p> <p>Just taking a look now Uber, Adobe, square space, and digital ocean all have openings specifically looking for software infrastructure engineers. These jobs really get me excited but I need to begin to practice this type of work and get a feel for what it consists of. So I&#39;m looking to give myself some projects and I need to decide on a language. </p></pre>metarx: <pre><p>What about contributing to open source infra projects, such as kubernetes, docker, hashicorp stuff and many other open source infrastructure. All written in go btw</p> <p>I think those would be a better foot in the door to those positions than writing your own from scratch. </p></pre>ldelossa: <pre><p>That&#39;s a great idea actually. I will take that advice. </p></pre>BraveNewCurrency: <pre><blockquote> <p>my perfect job is now to move into the actual development OF these solutions</p> </blockquote> <p>OK. Let me warn you that there are only a handful of companies big enough to employ people to work on LBs and caches. Most companies just string together existing solutions, and write some glue code to get it all working. That&#39;s the reality.</p> <p>I think part of the problem is terminology. When I hear &#34;Infrastructure Software Engineering&#34; it sounds like DevOps type stuff (writing Chef, setting up monitoring and alerts, etc). I&#39;m not sure I can think of a Job Title that is specific to writing low-level infrastructure like you want.</p> <p>(Source: I am a hiring manager for a cloud-based company with millions of users. I am looking to hire what HR calls &#34;Software Engineering - Infrastructure&#34;. A.K.A. Systems Engineering / DevOps. I just need a good programmer who really knows Linux and Networking.)</p></pre>ldelossa: <pre><p>I can completely understand that. SquareSpace right now has a very awesome job posting for &#34;Edge Infrastructure&#34; engineer. That is a perfect description of what I&#39;d like to be doing in year or so as I get my skills up. </p> <p><a href="https://www.squarespace.com/about/careers/?gh_jid=245517" rel="nofollow">https://www.squarespace.com/about/careers/?gh_jid=245517</a></p> <p>I actually currently have a DevOps title. </p></pre>BraveNewCurrency: <pre><p>I admit that the job description does <em>imply</em> that you will be writing load balancers. But if you look at their <a href="http://highscalability.com/squarespace-architecture-grid-handles-hundreds-millions-requests-month" rel="nofollow">technology stack</a>, you&#39;ll see that they use a commercial product for balancing and caching. So writing code for a LB/cache might be out of the question.</p> <p>(I admit this link is from 2009, so maybe it&#39;s changed by now. But my point is that you might be reading too much into job descriptions. It&#39;s very rare that companies write these things from scratch.)</p></pre>ldelossa: <pre><p>No I agree, I think most of the time it will be off the shelf. But even writing the glut code sounds awesome. I think a lot of times custom code will be in lua and manipulating internal structures </p></pre>professorGroblin: <pre><p>Docker, Kubernetes, etcd, prometheus, Vitess: all written in go</p></pre>ldelossa: <pre><p>I would argue none of these are performant by necessity. Docker is just a wrapper around an underlying containers library. Prometheus is a pull based model. And kubernetes is just a scheduler for the most part. This doesn&#39;t strict me the same as a piece of software responsible for pushing bits in different directions as near as real time as possible. But I could be wrong </p></pre>TheMerovius: <pre><blockquote> <p>Docker is just a wrapper around an underlying containers library.</p> </blockquote> <p>Is it? I thought docker issues raw syscalls for container management and <code>ldd docker</code> doesn&#39;t give me anything I would identify as a &#34;container library&#34;. I might be wrong, but I actually think the &#34;container library&#34; it wraps is go too.</p> <blockquote> <p>Prometheus is a pull based model.</p> </blockquote> <p>That&#39;s only the collection-part. It is also a performant time series database that need to support interactive live queries over relatively large datasets. It doesn&#39;t help at all to have collection, if I then can&#39;t use that data interactively in an outage to drill down into the problem, because it is too slow.</p> <blockquote> <p>And kubernetes is just a scheduler for the most part.</p> </blockquote> <p>Again, I don&#39;t see how this means it doesn&#39;t need to be performant. One instance can manage thousands of nodes and tens of thousands of pods while still being performant. That also means a lot of QPS to and from the master itself (after all, consensus over the state of all those pods must be maintained), while still being performant.</p> <blockquote> <p>This doesn&#39;t strict me the same as a piece of software responsible for pushing bits in different directions as near as real time as possible.</p> </blockquote> <p>What about <a href="https://github.com/Netflix/rend" rel="nofollow">rend</a>, a memcached-proxy in use at netflix? Scott Mansfield mentioned on <a href="https://changelog.com/gotime-9/" rel="nofollow">gotime</a> that they achieve sub-ms latency on most requests (he is more specific with the percentiles, but I don&#39;t remember).</p> <p>Maybe, instead of handwaving that all the existing infrastructure projects written in go in production at some of the largest internet companies in the world might not be fast enough, you should be more specific about why you think they are slow? I see no reason to doubt that they are more than fast enough.</p> <p>You asked if go is fast enough. The answer was pretty much unanimously yes, with specific examples of the kind of projects you mentioned, written in go. I&#39;d say the ball is in your court to either accept that answer or prove how they aren&#39;t fast enough :)</p></pre>ldelossa: <pre><p>I understand what you&#39;re saying here. And I think you&#39;re correct. I&#39;m coming from a heavy &#39;network infrastructure&#39; perspective, where I&#39;m worried about the ability to handle packet rates of data. Which I typically see done in C. I&#39;m biasing these questions and examples on my perspective. I think these are all valid points. </p> <p>My intention was not to downplay go&#39;s current projects. </p></pre>professorGroblin: <pre><p>OK, perhaps i don&#39;t agree with your assessment of what infrastructure software is then. If you mean real-time software,then, essentially thats just software with deadlines for processing events. And if real-time is what you meant, then Vitess absolutely falls into your bracket. I would say that any software that manages the run state of an application (and that definitely includes scheduling, monitoring and logging) <strong>is</strong> infrastructure software</p></pre>ldelossa: <pre><p>I think your definition here is valuable. I haven&#39;t actually tried to identity what it IS, and that was well put. Appreciated</p></pre>exch: <pre><p>Youtube uses a <a href="https://github.com/youtube/vitess">Go service</a> to do load balancing between its users and mysql databases. It seems to work well enough with millions of users.</p></pre>ldelossa: <pre><p>Thank you this is a great example </p></pre>fakeNAcsgoPlayer: <pre><p>I am one such platform engineer who write Caches and load balancers and geofencing aggregators and distributors and such stuff in C.</p> <p>Given a choice I would rewrite a lot if stuff in Go or C++. It is in C because legacy reasons .</p> <p>Here is what I learnt over a period of time. Measure every god damn thing, do not trust what you read on Internet, it is just a ball park figure, measure it yourself. Every single thing you need, test it for your use case. Only move when you understand the tradeoffs.</p> <p>Oh and also, performance is subjective and very easily misinterpreted. Beware of it.</p></pre>ldelossa: <pre><p>Thank you! This is great to hear from someone with experience. </p> <p>I understand the problems with performance analysis, I&#39;ve spent years now tracking down performance issues, understanding the synergy between different components and so on. But I find it highly valuable to still ask and get responses like yours. </p></pre>TheMerovius: <pre><p>I think so, but I also think, that the architecture is much more important than the language. You have inherent limits when scaling on a single instance, even if you handroll assembler and run on bare metal to edge out the smallest bit of performance. So, in today&#39;s world, being able to scale horizontally to multiple instances is much more important; if you can do that, the actual raw performance is just a constant cost multiplier (e.g. you might need 10% more CPUs or something with Language A than with language B, to handle the same workload). I think go makes it reasonably easy to write these kinds of scalable networked services with competitive enough performance to not increase the costs over C too much.</p> <p>BTW, if you believe you actually going to need the raw performance, I&#39;d recommend rust a billion times over C, especially if you start something fresh and need to learn the language anyway. It&#39;s just as fast (and probably faster, if not now, then soon, due to better guarantees to the compiler), but it&#39;s safe and there really is no excuse to write networked software in C these days. More to the point: I assume most of the current infrastructure software is written in C, not because it&#39;s best suited, but because there where no alternatives when they started.</p></pre>ldelossa: <pre><p>Thanks for the response. </p> <p>Rust is definitely under consideration but it seems to not have that much proliferation in the tech space. The only guys that I see using it are Mozilla themselves. This doesn&#39;t necessarily mean it&#39;s not worth wild, but community is a big deal with these things. I realllyyyy like the idea of rust but I&#39;m wondering if I can achieve the same thing with go whether that&#39;s a better route to take.</p></pre>chowmeined: <pre><p>Dropbox is using rust now for part of their storage backend.</p></pre>TheMerovius: <pre><p>&#34;The same thing&#34; probably not (there are a couple of things that work much better in rust, for example interaction with the C world in either direction), but as I said, cloud-infrastructure-thingies probably fare better with go. I&#39;m just saying you definitely shouldn&#39;t use C. I know it&#39;s a cliche, but I <em>do</em> actually consider C to be harmful :)</p></pre>ldelossa: <pre><p>I&#39;d like to avoid C if possible. I&#39;m coming into this with little C experience and I feel the ramp up to write C code that could actually be released into production would be rather long compared to a safe language. </p></pre>jocull: <pre><p>Rust also has a mode that lets you strip out the StdLib I believe. As far as I understand (never tried it) this lets you write embedded Rust that wouldn&#39;t even need an OS to power it. Complete lack of StdLib would be a real challenge, though. I can&#39;t imagine it being a very productive work environment.</p></pre>MrRichyPants: <pre><p>I am a big fan of the Caddy webserver, which is in Go. Look at their benchmarks, it&#39;s really really fast. Like nearly Nginx fast. I think it&#39;s certainly fast enough for systems where the bulk of the waiting is in network communication.</p></pre>ldelossa: <pre><p>Great example project! Thanks a ton. </p></pre>fakeNAcsgoPlayer: <pre><p>Caddy is nowhere close to nginx. Why do you say so?</p></pre>MrRichyPants: <pre><p>I&#39;ve found it to be in the same performance tier as Nginx, and it looks like others do too. See the Caddy FAQ, near the bottom.</p> <p>From the FAQ:</p> <p>How does Caddy perform compared to nginx or Apache?</p> <p>It&#39;s fast. If your site only serves tens of thousands of requests per second on good hardware, then don&#39;t worry about it. In our tests—which have been confirmed by multiple trial runs on different hardware, verified independently by different developers—we&#39;ve found that Caddy and nginx generally perform similarly for most static file needs, a notch above Apache. But this depends on many factors including system environment, hardware capabilities, network, software tuning, etc. We&#39;ve also seen some tests where Apache performs better than nginx. Given the high degree of variance among these factors combined with your own needs and configurations, we&#39;d rather you discover Caddy&#39;s performance for yourself. If you require extremely high throughput and you know what you&#39;re doing, do your own benchmarks. If you verify that Caddy is a bottleneck, we welcome your pull request to make it faster.</p></pre>anacrolix: <pre><p>I just started <a href="https://github.com/anacrolix/goproxy" rel="nofollow">https://github.com/anacrolix/goproxy</a> this morning because HAProxy has terrible defaults and was more trouble than it&#39;s worth to set up again on a new box. So far it&#39;s working great. I also have a lot of custom tools that do all the things typically some from C.</p></pre>ldelossa: <pre><p>This is fantastic. I&#39;m going to review this. Looks fun!