3 ms·

Every time I read an article criticizing Go I end up appreciating it even more. Maybe it's because I've never felt the need to use generics and in all these ar

by gws 12y ago

Every time I read an article criticizing Go I end up appreciating it even more. Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug... Maybe it's because of the bogus examples they give like criticizing > file, _ = os.Open("file.txt") > file.Chmod(777) for not handling explicitly a possible error when it's just because the example is ill written and the proper code is > file, err = os.Open("file.txt") > if err != nil { > ... handle error ... And here I stopped reading the article, it's always the same arguments over and over: more elegant and complex code vs. the un(cool) but oh my, so much simpler Go code. What I find really amusing though it's how people are so smug in their writing, pointing out the "obvious errors" (billion dollar mistakes!) that the Go authors made and their "ignorance" of proven modern programming language constructs they could implement in Go. There are two possibilities here, pick your preferred one. 1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude 2) These bloggers claiming obvious errors in Go design don't really fully understand the trade-offs involved in what they ask for and ignore the fact that the Go authors have carefully thought about them and optimized accordingly I will go back to programming in Go, I'd take writing for loops all the time vs. writing a one liner in Haskell and then agonize over using the lazy or strict version of it :)

kasey_junk 12y ago
I think there is a third option that you are ignoring. Pike, Thompson & Co. are designing for a different problem set than the blog authors. Golang seems to shine at very simple, concurrent tasks that can be passed from one set of developers to another regardless of sophistication levels of those teams. It seems to fail pretty miserably at making a single sophisticated developer vastly more productive. It's what Java would have been if they'd thrown away the write once/run anywhere goal and never gone down the J2EE box canyon. There is nothing wrong with either goal btw, they just are in some ways opposites.
gclaramunt 12y ago
OTOH, I think is part of the point: > file, err = os.Open("file.txt") > if err != nil { > ... handle error ... A type system with generics can use types to make an error a different type and produce a compile error if you don't handle the case without making the code more complex.
TheHydroImpulse 12y ago
> Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Uhmm, what? That seems entirely ignorant for ignoring an expressive concept and rather "do it the hard way". And, "remembering the generic syntax" is no different from remembering any other features' syntax, and I don't imagine you have issues remembering those, do you?
lmm 12y ago
> 1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude Go was designed by a team at Google, where there is a policy that the only languages you're allowed to code in are C++, Java, and Python. I think the resulting language reflects that; it has many of the strengths of C++, Java and Python, and might even be a better language than all three. But it is also missing really obvious improvements that could be taken from e.g. the ML language family - which shouldn't be surprising, given that no-one at Google is allowed to use those languages!
gnuvince 12y ago
> Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug... Why do you even need `for` loops? Comparison + labels + jumps are good enough. You want to know the reason? It's easier to understand the intent of the programmer when there is a loop. `for i = 1 to n do ... done` means that the programmer wants the body to be executed n times. `while not (list.is_empty()) do ... done` means the body should be executed as long as the list isn't empty. If those are acceptable, why not also abstract away applying an operation to a collection, or removing elements from a collection, etc.? Basically it boils down to: I like Go, and everything it has needs to be there, and everything it doesn't have is unnecessary complexity.

by gws 12y ago

kasey_junk 12y ago

I think there is a third option that you are ignoring. Pike, Thompson & Co. are designing for a different problem set than the blog authors. Golang seems to shine at very simple, concurrent tasks that can be passed from one set of developers to another regardless of sophistication levels of those teams. It seems to fail pretty miserably at making a single sophisticated developer vastly more productive. It's what Java would have been if they'd thrown away the write once/run anywhere goal and never gone down the J2EE box canyon. There is nothing wrong with either goal btw, they just are in some ways opposites.

gclaramunt 12y ago

OTOH, I think is part of the point: > file, err = os.Open("file.txt") > if err != nil { > ... handle error ... A type system with generics can use types to make an error a different type and produce a compile error if you don't handle the case without making the code more complex.

TheHydroImpulse 12y ago

> Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Uhmm, what? That seems entirely ignorant for ignoring an expressive concept and rather "do it the hard way". And, "remembering the generic syntax" is no different from remembering any other features' syntax, and I don't imagine you have issues remembering those, do you?

lmm 12y ago

> 1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude Go was designed by a team at Google, where there is a policy that the only languages you're allowed to code in are C++, Java, and Python. I think the resulting language reflects that; it has many of the strengths of C++, Java and Python, and might even be a better language than all three. But it is also missing really obvious improvements that could be taken from e.g. the ML language family - which shouldn't be surprising, given that no-one at Google is allowed to use those languages!

gnuvince 12y ago

> Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug... Why do you even need `for` loops? Comparison + labels + jumps are good enough. You want to know the reason? It's easier to understand the intent of the programmer when there is a loop. `for i = 1 to n do ... done` means that the programmer wants the body to be executed n times. `while not (list.is_empty()) do ... done` means the body should be executed as long as the list isn't empty. If those are acceptable, why not also abstract away applying an operation to a collection, or removing elements from a collection, etc.? Basically it boils down to: I like Go, and everything it has needs to be there, and everything it doesn't have is unnecessary complexity.