Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

towardsdatascience.com

Post reply on HN
Print view View original

21–30 of 76 posts

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

#21

Post by cigaaa »

cutler wrote: post #7

I'm a bit green on infrastructure & deployment but I don'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're not replacing the Python ML code so why is this such a big deal?

I don’t think people who work in infrastructure currently will be surprised that Go is a better choice than Python for infra, but for those who are newer to the field of ML or only work on model development (vs deployment), it is likely surprising that a major part of production ML is best done in a language other than Python.

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

#22

Post by workthrowaway »

aequitas wrote: post #17
nhumrich wrote: post #6

> 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?…

> Python works on every platform, and distributing is just a "pip install" and "pip install -u" 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…

> Until you have a dependency which has a C dependency (like a crypto framework, SQL connector, etc).

but... that's not a python problem.

every time people say they are having a hard time installing a python module, it's almost always a non-pure python module. it has an extension in c or c++. if that tells us anything, it's that mixing c and c++ makes software hard to install...

a fairer comparison with go here is with a go package that has extensions or bindings written in another language.

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

#23

Post by threeseed »

cigaaa wrote: post #21
cutler wrote: post #7

I'm a bit green on infrastructure & deployment but I don'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're not replacing the Python ML code so why is this such a big deal?

I don’t think people who work in infrastructure currently will be surprised that Go is a better choice than Python for infra, but for those who are newer to the field of ML or only work on model development (vs deployment), it is likely surprising that a major part of production ML is best done in a language other than Python.

I don't buy this comment at all.

I've worked with hundreds of Data Scientists, many new to the industry and they all know that R and Scala are important and popular languages for ML.

Majority of Data Engineering today is using Spark, which is written in Scala and even when you write Python code using it you can't escape Java/Scala internals being exposed.

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

#24

Post by sterwill »

vincentmarle wrote: post #13
nhumrich wrote: post #6

> 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?…

> But what makes python hard? You ever tried setting up Python on a new machine? https://xkcd.com/1987/

I do it all the time:

  apt install python3 python3-pip python3-virtualenv
Python packaging is one of its worst warts, but the Python runtime itself is very easy to install.

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

#25

Post by carteloupe »

jrimbault wrote: post #19
dewey wrote: post #18

Earlier quoted context omitted.

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.

>These two issues are usually brought up by people who haven't written a lot of C. >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.

Status quo is good because it's status quo, sure.

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

#27

Post by threeseed »

oflannabhra wrote: post #3

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

Tensorflow which is for Deep Learning is a very tiny part of the overall ML requirements.

To do large scale data preparation and engineering which necessitates clustering you would need to reinvent Spark. And then how about for the more common algorithms like boosted trees etc. Those algorithms are provided by Apple for iOS/MacOS but not sure if they exist for everyone else.

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

#28

Post by cle »

jrimbault wrote: post #19
dewey wrote: post #18

Earlier quoted context omitted.

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.

>These two issues are usually brought up by people who haven't written a lot of C. >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.

I have written a lot of Go (hundreds of thousands of LOC), and appreciate Go's approach to both of these. I disagree that these are major issues.

A bigger issue, IMO, is that people coming to Go from other languages expect it to have similar features to what they're used to. Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages.

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

#29

Post by apta »

cutler wrote: post #7

I'm a bit green on infrastructure & deployment but I don'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're not replacing the Python ML code so why is this such a big deal?

> It sounds like you're not replacing the Python ML code so why is this such a big deal?

How would you write an article about moving to a hipster language then? :-)

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

#30

Post by apta »

dewey wrote: post #18
toolslive wrote: post #10

"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.

I write a lot of code in golang, and if anything, my views before using the language were even further cemented by even more flaws I found while using it.
Post reply on HN