4 ms·

I don't have a ton of Go experience (intentionally), but I don't find it very good for ease of code or safety. It's a simple language to a fault, but I would n

by paholg 2y ago

I don't have a ton of Go experience (intentionally), but I don't find it very good for ease of code or safety. It's a simple language to a fault, but I would not call it easy. There are so many footguns in the language itself and the standard library. I just reviewed a PR that added a bunch of `defer response.Body.Close()` calls after http requests to fix leaks. I don't know why Go is allergic to RAII, but I hate it. I also find it very hard to read. There's so much boilerplate sprinkled throughout everything, it's hard to follow what code is actually doing. While I am very in favor of a good static type system, I think dynamically typed languages like Ruby or Python win over Go by any metric except speed.

benhoyt 2y ago
I think those are worthwhile criticisms ... right up until you said "Ruby or Python win over Go by any metric except speed". As someone who has written a ton of Python and a ton of Go (and likes both languages), I still prefer Python for small scripts due to its terseness and beautiful syntax. Side note: Go's static typing is so much better than Python's type annotations. Python typing is difficult to use and a mess: it's constantly changing ("improving"), Pyright and MyPy never agree, Pyright doesn't agree with itself between versions, and much more. The bolted-on, late-in-the-game nature of Python's typing really shows. One place where I have a real side-by-side comparison of the two languages solving the same problem is: I wrote a streaming websocket client with both Go and Python. Go's was so much easier to reason about due to the simplicity and ubiquity of io.Reader and io.Writer. Compare that to the mess that is Python "file-like objects" (https://docs.python.org/3/library/io.html https://docs.python.org/3/library/io.html). Should I use BufferedIOBase, or TextIO, or maybe RawIOBase, and what do I override in my subclass? It was quite painful. My take is that, in addition to its speed, Go wins on its type system, I/O interfaces, concurrency, package management, and test/benchmark tooling. Python wins in its beautiful syntax, [list|dict|set|generator] comprehensions, and quantity of 3rd party libraries.

by paholg 2y ago

benhoyt 2y ago

I think those are worthwhile criticisms ... right up until you said "Ruby or Python win over Go by any metric except speed". As someone who has written a ton of Python and a ton of Go (and likes both languages), I still prefer Python for small scripts due to its terseness and beautiful syntax. Side note: Go's static typing is so much better than Python's type annotations. Python typing is difficult to use and a mess: it's constantly changing ("improving"), Pyright and MyPy never agree, Pyright doesn't agree with itself between versions, and much more. The bolted-on, late-in-the-game nature of Python's typing really shows. One place where I have a real side-by-side comparison of the two languages solving the same problem is: I wrote a streaming websocket client with both Go and Python. Go's was so much easier to reason about due to the simplicity and ubiquity of io.Reader and io.Writer. Compare that to the mess that is Python "file-like objects" (https://docs.python.org/3/library/io.html https://docs.python.org/3/library/io.html). Should I use BufferedIOBase, or TextIO, or maybe RawIOBase, and what do I override in my subclass? It was quite painful. My take is that, in addition to its speed, Go wins on its type system, I/O interfaces, concurrency, package management, and test/benchmark tooling. Python wins in its beautiful syntax, [list|dict|set|generator] comprehensions, and quantity of 3rd party libraries.