Why we’re writing machine learning infrastructure in Go, not Python

Sounds like fairly generic deployment infrastructure that has nothing to do with machine learning.<p>But why pass up the opportunity to use a buzzword to get on the front page of HN?

I think the real lesson here is to choose the language that works best for your team.<p>On my team we use Python and Scala. For network critical I&#x2F;O stuff in Python, asyncio has worked out just fine for our needs. For massive CPU parallelism needs (at least in sporadic bursts), we&#x27;ve actually found that AWS&#x2F;Lambda does pretty well.<p>Golang seems to be really polarizing. Most engineers on my team have tried Golang in the past, but haven&#x27;t liked it, which is why we would never consider building anything on top of it. Everyone likes Python well-enough that it has kind of become the lingua franca for us.<p>Deployment is all based around containers or serverless&#x2F;lambda, and we have a pretty standardized way of deploying these things by now. Just because a bunch of k8s tooling is written in Golang doesn&#x27;t mean I need to rush out and write my stuff in Golang too.

I&#x27;m a bit green on infrastructure &amp; deployment but I don&#x27;t quite get this. If your ML algorithm code is still Python how does deployment with Go make that much difference? It sounds like you&#x27;re not replacing the Python ML code so why is this such a big deal?

I think, like TFA says, it comes down to ease of deployment for support tooling. A single executable is easier to distribute than a set of dependencies and a language runtime. These are tools that run outside containers to manage code that can run inside containers, where dependency management and isolation are easier. It makes total sense to me.

I would do it in python using one of the fast, modern ASGI servers like uvicorn.<p>Zero downtime model updates can be done using a redis cache to persist models.<p>In any case, that&#x27;s a solved problem using haproxy and kubernetes.<p>Not sure why go has these advantages

I would&#x27;ve chosen Erlang or Elixir for those reasons. Are we getting another Go package management solution this year? A pleasure to work with? I&#x27;ve been ditching Go for Nim recently. Other people seem to be enjoying Crystal. Rust is great, and coming down the road Zig looks excellent. I think Go has turned out to be a bit of a damp squib. Considering, unlike the other languages, it has Google behind it - unimpressed. After six years, I don&#x27;t expect to be using it at all within the next year or two.

Great, another one of these articles, but this time I feel more confident in my usual reply, having been working in Go exclusively for a while.<p>&gt; Implementing all of this functionality in Python may be doable with recent tools like asyncio, but the fact that Go is designed with this use case in mind makes our lives much easier.<p>This just makes me think about Armin Ronacher&#x27;s article on back pressure but, sure, whatever.<p>&gt; Building a cross-platform CLI is easier in Go<p>No, it isn&#x27;t.<p>&gt; The performance benefits of a compiled Go binary versus an interpreted language are also significant<p>Ah, yes, because performance is such a key feature of command line interfaces, as evidenced by bash and its <i>outstanding</i> performance in every benchmark.<p>&gt; The Go ecosystem is great for infrastructure projects<p>And the reality discussed in this point would be different if docker wasn&#x27;t written in Go. Had the docker developers chose <i>anything else</i>, this point would apply to that hypothetical language, so it isn&#x27;t an inherent advantage of Go as a language.<p>&gt; Go is just a pleasure to work with<p>No, it really, <i>really</i> isn&#x27;t, but that&#x27;s not the point.<p>This is ultimately the real reason they chose go: whoever made the original decision liked it and everything else is post-hoc rationalization.<p>Which is fine, most of this tends to be subjective.

All the stuff that requires speed is written in a language that compiles directly to machine code while the machine learning libraries are all python based. That seems standard, no?

&quot;in the land of the blind, the one-eyed man is king&quot;<p>Golang is probably a step up from Python, but it&#x27;s just that. There are a lot of issues with Golang. From the top of my head, lack of decent error handling (if err !=nil { return nil,err} ) or lack of decent polymorphism are the most annoying. There&#x27;s a github repo dedicated to what&#x27;s bugging people:<p><pre><code> https:&#x2F;&#x2F;github.com&#x2F;ksimka&#x2F;go-is-not-good</code></pre>

Why not Swift? (I think I know the answer).<p>Concurrency in Swift is not yet a solved problem, but libdispatch is quite workable (although not &quot;elegant, out of the box&quot; per the article).<p>With the work being done in Swift for TensorFlow [0], I&#x27;d imagine in a year or two both the infrastructure and the ML portions of a product like Cortex could be written in a single language.<p>[0] - <a href="https:&#x2F;&#x2F;www.tensorflow.org&#x2F;swift" rel="nofollow">https:&#x2F;&#x2F;www.tensorflow.org&#x2F;swift</a>

Not reading carefully the title might make one think that you are doing ML with Go which by the content of the article you are obviously not. This is almost click-bait.

&gt; Making all of these overlapping API calls in a performative, reliable way is a challenge.<p>Pythons asyncio is pretty hard to beat. For non-cpu intensive tasks, I find it a pleasure to work with. Goroutines can still have race conditions.<p>&gt; Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult<p>Sure, I get that go can cross-compile. But what makes python hard? Python works on every platform, and distributing is just a &quot;pip install&quot; and &quot;pip install -u&quot; Surely thats easier than &quot;Download the correct binary for the platform, unzip it, change permissions, add it to your path, then do it all over again for every update&quot;<p>I was the original author of the awseb cli and we found that pip install was significantly less of a hurdle than a go binary and decided to do it in Python instead. If a user on windows has a hard time installing python and pip, telling them to drop a binary and change their path isnt going to be any easier.

Anything is faster than CPython. Even PHP!