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

31–40 of 76 posts

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

#31

Post by Jerry2 »

calebkaiser wrote: post #5
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

Swift is an interesting choice, one we haven't explored in depth. Out of curiosity, have you done any work with Swift for Tensorflow/what has your experience been?

Not him but the company I work for has moved most of our ML pipelines away from Python and over to Swift. We started the move after Google announced support for Swift for TF. Before the move over to Swift, we were rewriting a lot of the data paths in C++ but were generally unhappy with the state of TF for C++ libraries. The move to Swift hasn't been without hiccups, however, but the community has been extremely helpful and it was worth it overall. State of Swift for TF libraries today is quite good.

We looked at Go early on but quickly dismissed it because with the move from Python to Go, it didn't seem like we were getting enough benefits to warrant the amount of work that would be required.

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

#32

Post by jvolkman »

workthrowaway wrote: post #22
aequitas wrote: post #17

Earlier quoted context omitted.

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

Sure, but the most popular Python connectors for MySQL and PostgreSQL both utilize C or C++ extensions, whereas the equivalent connectors for Go are both written in pure Go. Even if it's not a problem with the language in its purest form, it is a problem with the ecosystem.

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

#33

Post by icandoit »

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

I like my code to look simple and behave as expected. Stability and "one right way to do it" are great language features.

I think this was why Python was able to overtake Perl, for example.

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

#34

Post by aequitas »

workthrowaway wrote: post #22
aequitas wrote: post #17

Earlier quoted context omitted.

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

It is a Python problem because we praise Python for how portable it is, that it binds with every C library out there to provide the functionality we need at the performance we want and how easy it is to install with Pip. But then forget all the problems people get in during installing.

A fairer comparison would be comparing the ease of how to create and install a cross platform Go binary compared to how to distribute a Python application as a single package/pseudo-binary (I've been down that rabbithole and many others with Python packages in the past 15 years).

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

#35

Post by icandoit »

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.

In some circles C has a better reputation than C++.

Surely you see that other people value other things than you do?

If you value simplicity check out the programming language zig.

https://ziglang.org/

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

#36

Post by vardump »

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

Well... there's also other side of the coin. There's value in visibility and lack of magic.

> lack of decent error handling (if err !=nil { return nil,err} )

Errors are in your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust.

> or lack of decent polymorphism...

Lack of polymorphism also means you don't have to guess about concrete types when reading code. When troubleshooting, you can see what's going on without going through whole inheritance tree.

Go encourages composition instead of inheritance. That's something I wish more C++ codebases would do as well. Composition makes code inherently more maintainable and easier to refactor.

Go tends to be easy to read and maintain. It does come with some cost. It's just a matter where your priorities lie. Software projects spend majority of their life as legacy, something that needs to be maintained.

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

#38

Post by calebkaiser »

tus88 wrote: post #26

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

This is a good point, and it’s something we think about a lot. In one sense, you can certainly think of Cortex as a tool for deploying/scaling/monitoring Python functions on AWS, but there are many ML-specific features that make it different.

It does things like prediction monitoring, and it supports models exported by ONNX and TF Serving. We also have designed Cortex to prioritize infrastructure needs specific to inference workloads (inference workloads are read only and memory hungry, for example). This is why we’ve prioritized things like GPU spot instances.

Our long-term plan includes more end-to-end ML workflows, including things like training, but for now we’re focused on getting model serving right.

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

#39

Post by allovernow »

vardump wrote: post #36
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

Well... there's also other side of the coin. There's value in visibility and lack of magic. > lack of decent error handling (if err !=nil { return nil,err} ) Errors are in your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust. > or lack of decent polymorphism... Lack of polymorp…

>Composition makes code inherently more maintainable and easier to refactor.

My understanding of composition comes from interfaces in C#. In my experience composition is actually more difficult to code and refactor, because it leads to bloat from repeated code as you cannot simply inherit. Refactoring then can become tedious as you may need to manually edit every repeated code block. Whereas with inheritance I define a function once and override it where necessary.

Am I misunderstanding something?

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

#40

Post by jrimbault »

icandoit wrote: post #35
jrimbault wrote: post #19

Earlier quoted context omitted.

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

In some circles C has a better reputation than C++. Surely you see that other people value other things than you do? If you value simplicity check out the programming language zig. https://ziglang.org/

I love C, loathe C++, but it is still valid issue that polymorphism in C is hard and error handling rely on convention ? (I know of Zig, Nim et al, I'm more oriented towards Rust this last year)
Post reply on HN