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

41–50 of 76 posts

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

#41

Post by vardump »

allovernow wrote: post #39
vardump wrote: post #36

Earlier quoted context omitted.

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…

Composition tends to lead to more code reuse. And to more code that's still usable in unpredictable future.

Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid.

Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.

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

#42

Post by hnaccy »

sandGorgon wrote: post #11

I would do it in python using one of the fast, modern ASGI servers like uvicorn. 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

If you do model inference in web server process it will be compute bound and lock up the web server, is there a preferred/clean way to req/rec or similar pass the jobs to second process and allow web server process to non-blocking wait for response?

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

#43

Post by mrbrowning »

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…

> Errors are on 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.

Errors as values is a great idea. Errors as values without sum types or pattern matching, though, gives you twice the tedium and a tenth of the benefit, so once again Golang's slavish adherence to "worse is better" really just makes things...worse. The real problem here, though, is that those invisible gotos still exist: because of how limited Go's type system is, it's very easy to cause a panic with e.g. a nil pointer. Of course, the answer is to rigorously check the cases where a pointer could be nillable, but that trivially contradicts the idea that, when reading Go code, you can feel confident reasoning locally about its resilience if it handles all potential error values appropriately. IMO, this false sense of safety is even worse than just making exceptions first class citizens of the language, and it belies the notion that Go is especially maintainable.

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

#44

Post by woeirua »

hnaccy wrote: post #42
sandGorgon wrote: post #11

I would do it in python using one of the fast, modern ASGI servers like uvicorn. 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

If you do model inference in web server process it will be compute bound and lock up the web server, is there a preferred/clean way to req/rec or similar pass the jobs to second process and allow web server process to non-blocking wait for response?

Yes, use a dedicated job server/process like Celery.

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

#45

Post by PeterisP »

Runawaytrain2 wrote: post #2

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?

All the popular machine learning libraries are a Python API to more conveniently communicate with the CUDA code that actually does the calculations on GPUs. The API can be in any other language, but the choice of that language does not really affect performance much, as the heavy lifting in any "Python machine learning library" does not happen in Python anyway.

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

#46

Post by shrimpx »

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…

Try/catch vs explicitly checking error values is like implementing sandboxing with os-level isolation versus with programming discipline. Why one would prefer offering guarantees like "will never crash/panic" using the latter technique instead of a guaranteed catch-all is incomprehensible to me.

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

#47

Post by arwhatever »

allovernow wrote: post #39
vardump wrote: post #36

Earlier quoted context omitted.

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…

I don't see that composition should be cause for repeated code blocks.

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

#48

Post by loicd »

apta wrote: post #30
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.

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.

Out of curiosity, would you share those flaws you have found?

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

#49

Post by apta »

loicd wrote: post #48
apta wrote: post #30

Earlier quoted context omitted.

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.

Out of curiosity, would you share those flaws you have found?

I will hopefully later today, not able to type much now.

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

#50

Post by _y5hn »

mrbrowning wrote: post #43
vardump wrote: post #36

Earlier quoted context omitted.

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…

> Errors are on 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. Errors as values is a great idea. Errors as values without sum types or pattern matching, though, gives you twice the tedium and a tenth of the benefit, so once again Golang's slavish adherence to "worse is b…

Accessing nil would be a programming error, not normal errorhandling and code logic should inherently avoid the scenario, not hide or do coverup silently. If it breaks, let the process die.

The cost of simpler tools is you need to target better, simpler designs and refactor. This requires more from programmers but produces better code.

Post reply on HN