3 ms·

We Switched from Python to Go (2017)

37 points by metadat 4y ago

obi1kenobi 4y ago
Needs a (2020) since that's when it was last updated. Originally posted in 2017 and updated in 2019 and 2020.
jacktheturtle 4y ago
good article - I’d love an excuse to use go
jimbokun 4y ago
How is the dependency handling situation today? Not being able to refer to specific versions seems like a deal breaker for serious production applications.
- cyphar 4y ago
  You've been able to refer to specific versions for as long as vendoring has been used (Godep was first released in 2013 so at least that long, if not longer) and Go has supported it natively with Go modules since Go 1.11 (2019).
- yawaramin 4y ago
  Go today has arguably the best dependency handling story: https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain
deleted 4y ago
[deleted]
bee_rider 4y ago
Huh, as a non-go programmer, I was pretty shocked to see it doesn't have operator overloading. How have experiences with that been? Seems like a big omission but it is a pretty well regarded language, so I guess they must have thought this out.
- dilyevsky 4y ago
  It’s hard to design good operator overloading. In c++ it’s difficult to do correctly to the point of being considered an antipattern in many shops
  - masklinn 4y ago
    C++ making bad choices more or less universally impugns on operator overloading no more than on anything else.
  - boxed 4y ago
    It's all about culture. I learned that operator overloading is evil when I worked in C++. Then I worked in python and it's actually fine. Python has much more powerful overloading capabilities (you can overload a LOT more), and yet it's not a total mess like in C++.
- gautamdivgi 4y ago
  I don’t like operator overloading much. I think it hides a lot of what’s happening behind the scenes. It’s good syntactic sugar but wouldn’t be a deal breaker for me. I love python. My personal complaints about it - speed, gil and static typing. Other than that I love using it.
- mikepurvis 4y ago
  It's cute for trivial cases like algebra libraries, but very ripe for abuse (std::cout) and hard to get right for scenarios where it’s two different types being operated on, especially if a) the leftmost one is a built-in or b) various combinations of casts could get you to a supported operator. Rust obviously does do operator overloading, but it addresses (a) mostly through culture, and (b) by insisting on explicit casts everywhere.
  - suremarc 4y ago
    > It's cute for trivial cases like algebra libraries I don't understand this wording. Algebra libraries are nontrivial to implement, as the algorithms that operate on such structures can be exceedingly complex, and there are many types of algebra relevant to computer programming. Linear algebra (and its big brother, tensor algebra), boolean algebras, polynomials...
pvg 4y ago
Big thread a few months ago https://news.ycombinator.com/item?id=31516013 https://news.ycombinator.com/item?id=31516013 And a few years ago https://news.ycombinator.com/item?id=15495562 https://news.ycombinator.com/item?id=15495562
- metadat 4y ago
  Thank you, @pvg, for pointing out the recent thread, I hadn't seen it!
herpderperator 4y ago
Can someone explain how this is "simple" to understand? type openWeatherMap struct{} ... var d struct { Main struct { Kelvin float64 `json:"temp"` } `json:"main"` } if err := json.NewDecoder(resp.Body).Decode(&d); err != nil { return 0, err } There is a "type" struct at the top, but then another struct without a type later on. Then there's a nested struct, and then backticks with double quotes and json with colons - one with the backticks after float64, and the other after a brace. Then rather than returning the result of the json response with an equal sign, the json decoder line takes in both the response and the output as function parameters! And one of them has an ampersand in front?! Time and time again Go is said to be a simple language, but can you really say that the Python equivalent of that example is more difficult to understand? >>> decoded_json = json.load(urllib.request.urlopen('https://httpbin.org/get')) >>> print(decoded_json) Come on now.
- deleted 4y ago
  [deleted]
- zbobet2012 4y ago
  I believe you're conflating "simple in design" with "simple/easy to learn". Go is simple is design. It's not targeted to be easy to learn for someone without basic cs knowledge. As a meta some time spent watching simple made easy https://www.youtube.com/watch?v=kGlVcSMgtV4 https://www.youtube.com/watch?v=kGlVcSMgtV4 will help on the difference. For example: > There is a "type" struct at the top, but then another struct without a type later on. 1) You not being familiar with anonymous types, does not make go complex. Anonymous types (var d struct) have been around for a _very_ long time. > Then there's a nested struct, and then backticks with double quotes and json with colons - one with the backticks after float64, and the other after a brace. 2) Anonymous types and tagging. The tags are a convenient, orthogonal language feature. > Then rather than returning the result of the json response with an equal sign, the json decoder line takes in both the response and the output as function parameters! And one of them has an ampersand in front?! The json decoder in go works on structs by reference to improve speed. You'll need to understand passing by reference vs value to understand why this code is structured the way it is. All three of these things are _simple_ features but they may not be easy to understand. By the way the equivalent go code for the python you posted is actually: d := make(map[string], interface{}) json.Unmarshal(resp.Body, d) fmt.Println(d)
chaostheory 4y ago
I feel python’s performance pain with anything related to pandas. The issue with this post is that Go isn’t an obvious substitute due to its more verbose syntax.
eweise 4y ago
Seems like any statically typed language would be a big win over python.
danieltanfh95 4y ago
From the article it seems they were needlessly using classes and doing funky stuff with Python everywhere. It speaks more about the quality of team than the move to Go. I've used both and maintaining legacy Go code is still quite a nightmare with the bazillion ways people can fuck up dependencies, error handling, and non existent types. Python is ok in comparison, not good, just ok. If I wanted a dynamic language that offers speed I would have just stuck with Common Lisp tbh.
tschellenbach 4y ago
Author here, this post is ancient by now. Definitely time for an update since people keep on posting it. Go has been great at Stream. We are hiring atm. No go experience required and various levels of seniority.

37 points by metadat 4y ago

obi1kenobi 4y ago

Needs a (2020) since that's when it was last updated. Originally posted in 2017 and updated in 2019 and 2020.

jacktheturtle 4y ago

good article - I’d love an excuse to use go

jimbokun 4y ago

How is the dependency handling situation today? Not being able to refer to specific versions seems like a deal breaker for serious production applications.

cyphar 4y ago
You've been able to refer to specific versions for as long as vendoring has been used (Godep was first released in 2013 so at least that long, if not longer) and Go has supported it natively with Go modules since Go 1.11 (2019).
yawaramin 4y ago
Go today has arguably the best dependency handling story: https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain

deleted 4y ago

[deleted]

bee_rider 4y ago

Huh, as a non-go programmer, I was pretty shocked to see it doesn't have operator overloading. How have experiences with that been? Seems like a big omission but it is a pretty well regarded language, so I guess they must have thought this out.

dilyevsky 4y ago
It’s hard to design good operator overloading. In c++ it’s difficult to do correctly to the point of being considered an antipattern in many shops
- masklinn 4y ago
  C++ making bad choices more or less universally impugns on operator overloading no more than on anything else.
- boxed 4y ago
  It's all about culture. I learned that operator overloading is evil when I worked in C++. Then I worked in python and it's actually fine. Python has much more powerful overloading capabilities (you can overload a LOT more), and yet it's not a total mess like in C++.
gautamdivgi 4y ago
I don’t like operator overloading much. I think it hides a lot of what’s happening behind the scenes. It’s good syntactic sugar but wouldn’t be a deal breaker for me. I love python. My personal complaints about it - speed, gil and static typing. Other than that I love using it.
mikepurvis 4y ago
It's cute for trivial cases like algebra libraries, but very ripe for abuse (std::cout) and hard to get right for scenarios where it’s two different types being operated on, especially if a) the leftmost one is a built-in or b) various combinations of casts could get you to a supported operator. Rust obviously does do operator overloading, but it addresses (a) mostly through culture, and (b) by insisting on explicit casts everywhere.
- suremarc 4y ago
  > It's cute for trivial cases like algebra libraries I don't understand this wording. Algebra libraries are nontrivial to implement, as the algorithms that operate on such structures can be exceedingly complex, and there are many types of algebra relevant to computer programming. Linear algebra (and its big brother, tensor algebra), boolean algebras, polynomials...

pvg 4y ago

Big thread a few months ago https://news.ycombinator.com/item?id=31516013 https://news.ycombinator.com/item?id=31516013 And a few years ago https://news.ycombinator.com/item?id=15495562 https://news.ycombinator.com/item?id=15495562

metadat 4y ago
Thank you, @pvg, for pointing out the recent thread, I hadn't seen it!

herpderperator 4y ago

Can someone explain how this is "simple" to understand? type openWeatherMap struct{} ... var d struct { Main struct { Kelvin float64 `json:"temp"` } `json:"main"` } if err := json.NewDecoder(resp.Body).Decode(&d); err != nil { return 0, err } There is a "type" struct at the top, but then another struct without a type later on. Then there's a nested struct, and then backticks with double quotes and json with colons - one with the backticks after float64, and the other after a brace. Then rather than returning the result of the json response with an equal sign, the json decoder line takes in both the response and the output as function parameters! And one of them has an ampersand in front?! Time and time again Go is said to be a simple language, but can you really say that the Python equivalent of that example is more difficult to understand? >>> decoded_json = json.load(urllib.request.urlopen('https://httpbin.org/get')) >>> print(decoded_json) Come on now.

deleted 4y ago
[deleted]
zbobet2012 4y ago
I believe you're conflating "simple in design" with "simple/easy to learn". Go is simple is design. It's not targeted to be easy to learn for someone without basic cs knowledge. As a meta some time spent watching simple made easy https://www.youtube.com/watch?v=kGlVcSMgtV4 https://www.youtube.com/watch?v=kGlVcSMgtV4 will help on the difference. For example: > There is a "type" struct at the top, but then another struct without a type later on. 1) You not being familiar with anonymous types, does not make go complex. Anonymous types (var d struct) have been around for a _very_ long time. > Then there's a nested struct, and then backticks with double quotes and json with colons - one with the backticks after float64, and the other after a brace. 2) Anonymous types and tagging. The tags are a convenient, orthogonal language feature. > Then rather than returning the result of the json response with an equal sign, the json decoder line takes in both the response and the output as function parameters! And one of them has an ampersand in front?! The json decoder in go works on structs by reference to improve speed. You'll need to understand passing by reference vs value to understand why this code is structured the way it is. All three of these things are _simple_ features but they may not be easy to understand. By the way the equivalent go code for the python you posted is actually: d := make(map[string], interface{}) json.Unmarshal(resp.Body, d) fmt.Println(d)

chaostheory 4y ago

I feel python’s performance pain with anything related to pandas. The issue with this post is that Go isn’t an obvious substitute due to its more verbose syntax.

eweise 4y ago

Seems like any statically typed language would be a big win over python.

danieltanfh95 4y ago

From the article it seems they were needlessly using classes and doing funky stuff with Python everywhere. It speaks more about the quality of team than the move to Go. I've used both and maintaining legacy Go code is still quite a nightmare with the bazillion ways people can fuck up dependencies, error handling, and non existent types. Python is ok in comparison, not good, just ok. If I wanted a dynamic language that offers speed I would have just stuck with Common Lisp tbh.

tschellenbach 4y ago

Author here, this post is ancient by now. Definitely time for an update since people keep on posting it. Go has been great at Stream. We are hiring atm. No go experience required and various levels of seniority.