Why we’re writing machine learning infrastructure in Go, not Python
towardsdatascience.com
Why we’re writing machine learning infrastructure in Go, not Python
1–10 of 76 posts
Re: Why we’re writing machine learning infrastructure in Go, not Python
#2Re: Why we’re writing machine learning infrastructure in Go, not Python
#3Concurrency 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.
Re: Why we’re writing machine learning infrastructure in Go, not Python
#4All 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?
Re: Why we’re writing machine learning infrastructure in Go, not Python
#5Why 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
Re: Why we’re writing machine learning infrastructure in Go, not Python
#6Pythons 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" 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"
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.
Re: Why we’re writing machine learning infrastructure in Go, not Python
#7Re: Why we’re writing machine learning infrastructure in Go, not Python
#8> 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?…
Re: Why we’re writing machine learning infrastructure in Go, not Python
#9> 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?…
I was yelled at a few times for not using package and environment management tools (Conda, etc). So, when working with Python it is not just a "pip install" anymore
Re: Why we’re writing machine learning infrastructure in Go, not Python
#10Golang 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