We Switched from Python to Go (2017)
getstream.io
getstream.io
https://news.ycombinator.com/item?id=31516013
And a few years ago
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.
Go has been great at Stream. We are hiring atm. No go experience required and various levels of seniority.
I love python. My personal complaints about it - speed, gil and static typing. Other than that I love using it.
Rust obviously does do operator overloading, but it addresses (a) mostly through culture, and (b) by insisting on explicit casts everywhere.
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...
But the comment was specifically about the interface to those operations, that it's convenient and non-harmful ("cute") to have an infix operator just work, because no one would expect that multiplying vectors is going to secretly be a function call that could block or throw or have other unknown side effects the way something like using "stream insertion" on a logger object might. Or have an uncertain effect, like defining operator+ for just one of the multiple possible schemes by which two dicts may be combined.
It's just... not a good feature for the most part.
Well, I guess the lack of an overload for <, >, and == is somewhat annoying. But I don't think those as are essential as arithmetic overloads are for mathematical code.
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
}
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)
> 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)
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/ [1] https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...
Go is easy to learn, for developers who already have fluency with notions such as pass by reference, typing, etc.
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. 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.
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.