4 ms·

Can someone explain how this is "simple" to understand? type openWeatherMap struct{} ... var d struct { Main struct { Kelvin float64 `json:"tem

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)
- ternaryoperator 4y ago
  > It's not targeted to be easy to learn. Not sure where you get that idea. "Easy to learn" is literally the second bullet point on the go home page. [0] The golang authors (Russ Cox, etc.) in Communications of the ACM (May 2022): "Go is efficient, easy to learn, and freely available..."[1] ...and many other places similarly. [0] https://go.dev/ https://go.dev/ [1] https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...
  - zbobet2012 4y ago
    _without basic cs knowledge_ is the second part of that sentence you cut out. Go is easy to learn, for developers who already have fluency with notions such as pass by reference, typing, etc.
cpuguy83 4y ago
That's not even close to the same thing.
jrockway 4y ago
`type` declares a type alias. `struct` defines a struct. If you're going to use your struct more than once, give it a name. If not, feel free not to. The library "encoding/json" reads struct tags to figure out how to map names in JSON objects to the fields in the struct. It can guess, but you can also tell it. The convention `library:"expression"` is enforced by static analysis and is used throughout the standard library and ecosystem. It's not just for JSON. Decode doesn't return the decoded value because it can't know the desired message type to return. "encoding/json" predates generics, but even with generics, it's not quite as simple as you think. With a decoding function like `func Decode[T any](data []byte) (T, error)`, you still have to invoke it as Decode[MessageType](data) in many circumstances. Have a play with: https://go.dev/play/p/uKdS47KrsyR https://go.dev/play/p/uKdS47KrsyR. You don't have to pass the result as an argument to decode, and there are no struct tags. Finally, if you don't want a typed message, decode into a map[string]any. {"foo":{"bar"{"baz":123}}} decodes into an object that you can use like message["foo"]["bar"]["baz"]. Just hope that the server returned data according to the spec; it's shocking how often they don't.
NAHWheatCracker 4y ago
It doesn't matter if it's easier or harder to understand when the point is they are doing different things. The Go code is enforcing some sort of primitive schema, which is why you have the struct definition and the error handling. The ampersand is moving allocation up the stack and making a pointer to the local object. Pointers can complicate things from the perspective of a higher-level language, but I think that's more of a matter of experience. I agree that the `json:` choice is something that puts me off Go a bit, but the alternative in other languages usually delve into hard to understand magic with decorators and reflection, so it makes sense from a simplicity standpoint. Lastly, who ever said Go is simpler than Python? I'd say Go is more like a simpler C. It makes lower level programming more palatable.

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)

ternaryoperator 4y ago
> It's not targeted to be easy to learn. Not sure where you get that idea. "Easy to learn" is literally the second bullet point on the go home page. [0] The golang authors (Russ Cox, etc.) in Communications of the ACM (May 2022): "Go is efficient, easy to learn, and freely available..."[1] ...and many other places similarly. [0] https://go.dev/ https://go.dev/ [1] https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...
- zbobet2012 4y ago
  _without basic cs knowledge_ is the second part of that sentence you cut out. Go is easy to learn, for developers who already have fluency with notions such as pass by reference, typing, etc.

cpuguy83 4y ago

That's not even close to the same thing.

jrockway 4y ago

`type` declares a type alias. `struct` defines a struct. If you're going to use your struct more than once, give it a name. If not, feel free not to. The library "encoding/json" reads struct tags to figure out how to map names in JSON objects to the fields in the struct. It can guess, but you can also tell it. The convention `library:"expression"` is enforced by static analysis and is used throughout the standard library and ecosystem. It's not just for JSON. Decode doesn't return the decoded value because it can't know the desired message type to return. "encoding/json" predates generics, but even with generics, it's not quite as simple as you think. With a decoding function like `func Decode[T any](data []byte) (T, error)`, you still have to invoke it as Decode[MessageType](data) in many circumstances. Have a play with: https://go.dev/play/p/uKdS47KrsyR https://go.dev/play/p/uKdS47KrsyR. You don't have to pass the result as an argument to decode, and there are no struct tags. Finally, if you don't want a typed message, decode into a map[string]any. {"foo":{"bar"{"baz":123}}} decodes into an object that you can use like message["foo"]["bar"]["baz"]. Just hope that the server returned data according to the spec; it's shocking how often they don't.

NAHWheatCracker 4y ago

It doesn't matter if it's easier or harder to understand when the point is they are doing different things. The Go code is enforcing some sort of primitive schema, which is why you have the struct definition and the error handling. The ampersand is moving allocation up the stack and making a pointer to the local object. Pointers can complicate things from the perspective of a higher-level language, but I think that's more of a matter of experience. I agree that the `json:` choice is something that puts me off Go a bit, but the alternative in other languages usually delve into hard to understand magic with decorators and reflection, so it makes sense from a simplicity standpoint. Lastly, who ever said Go is simpler than Python? I'd say Go is more like a simpler C. It makes lower level programming more palatable.