11–20 of 76 posts
Zero downtime model updates can be done using a redis cache to persist models.
In any case, that's a solved problem using haproxy and kubernetes.
Not sure why go has these advantages
> Making all of these overlapping API calls in a performative, reliable way is a challenge. 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. > Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult Sure, I get that go can cross-compile. But what makes python hard?…
You ever tried setting up Python on a new machine? https://xkcd.com/1987/
Why not Swift? (I think I know the answer). Concurrency in Swift is not yet a solved problem, but libdispatch is quite workable (although not "elegant, out of the box" per the article). With the work being done in Swift for TensorFlow [0], I'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. [0] - https://www.tensorflow.org/swift
> Making all of these overlapping API calls in a performative, reliable way is a challenge. 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. > Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult Sure, I get that go can cross-compile. But what makes python hard?…
Also, when we had the Python CLI, some of our users complained that in their CI systems which ran `cortex deploy`, they didn’t need Python/Pip in their images, and installing them was inconvenient
> Making all of these overlapping API calls in a performative, reliable way is a challenge. 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. > Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult Sure, I get that go can cross-compile. But what makes python hard?…
Until you have a dependency which has a C dependency (like a crypto framework, SQL connector, etc). Suddenly you need an entire compiler toolchain, dev dependencies, all the library headers, and a decent amount of time. Also the errors thrown when these compile steps fail are anything but helpful for new users. If you are lucky there is already a wheel for your platform/arch.
> Surely thats easier than "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"
This is trivial to automate using a script and has a ton less failure modes to deal with than Pip would have (do you have the correct Python version?, is there a compiler installed for C modules?, etc).
"in the land of the blind, the one-eyed man is king" Golang is probably a step up from Python, but it'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's a github repo dedicated to what's bugging people: https://github.com/ksimka/go-is-not-good
In day to day work it's really not an issue.
"in the land of the blind, the one-eyed man is king" Golang is probably a step up from Python, but it'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's a github repo dedicated to what's bugging people: https://github.com/ksimka/go-is-not-good
These two issues are usually brought up by people who haven't written a lot of Go. In day to day work it's really not an issue.
>In day to day work it's really not an issue.
Polymorphism and error handling, these are issues, address them. Go's a fine language, but don't dismiss actual real issues that have been addressed in other languages for 40+? years.
On my team we use Python and Scala. For network critical I/O stuff in Python, asyncio has worked out just fine for our needs. For massive CPU parallelism needs (at least in sporadic bursts), we've actually found that AWS/Lambda does pretty well.
Golang seems to be really polarizing. Most engineers on my team have tried Golang in the past, but haven'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.
Deployment is all based around containers or serverless/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't mean I need to rush out and write my stuff in Golang too.