5 ms·

Simplicity in Go is one of it's most loved features. For the most part, there are fewer ways to do the same thing and I love that.

gher-shyu3i 6y ago
It's actually only superficial simplicity. There have been good comments on HN about this issue. Just because the language is "simple", it doesn't hide the complexity of reality, and written code ends up being harder and more verbose and more difficult to manage compared to powerful languages.
- philosopher1234 6y ago
  With all due respect those comments you’re referencing generally don’t know what they’re talking about. There is a lot hatred on this website for Go, which appears to have more to do with “I don’t understand why it’s designed this way, and I think all good languages should look like lisp/Haskell/rust” than “this design is net negative for developers”. Practical simplicity is all about hiding complexity. Unless you’re building a race car, you don’t need to know the differences between file handling in Linux Mac and windows. It just never comes up. And when it does, it’s possible to peak under the hood. A lot of the criticism of go mistakes “difficult to write” or “not trendy” for “bad design”, and again I assert this is because the critics don’t actually understand what Go is designed for, period.
  - stouset 6y ago
    With all due respect, I do understand why go was designed the way it was, and I vehemently disagree with those decisions. I used go for years, and with every passing day I grew more and more disenfranchised with the language. GP is right. Eschewing abstractions in a programming language forces users of that language to deal with it themselves on a recurring basis. Millions of lines of if res, err := fn(...); err != nil { return nil, fmt.Errorf("...") } don't help anyone, and only detract from readability which is bar none the most important part of a code base. Sadly, this is one of many symptoms in the language where problems that could have been solved in the language have instead been pushed down to its users to deal with over and over and over.
    - philosopher1234 6y ago
      You claim to understand the decisions, so I’ll push you on that. Why is go error handling designed the way it is? What are the intended benefits? What are the actual benefits? A follow up, on your abstraction point: why does go eschew abstraction? Intended upside? Actual upside? It’s very clear people in these threads can perceive downsides of some of Go’s decisions, but what about upsides? And further, can you recognize how Go copes with the downsides it’s choices produce?
      - philosopher1234 6y ago
        A lot of the criticism of go is a little bit like a guy who hates New York pizza saying “New York pizza sucks, it’s only 1”. Chicago pizza has 4 more inches which has been state of the art for years” Sure, it’s different, but that doesn’t mean it’s bad, and if your criticism only focuses on one detail and leaves out the whole picture, no kidding you produce a harsh judgement.
        stouset 6y ago
        Frankly your dismissal of people's legitimate concerns with the language as just uneducated griping by fools is one of the reasons I and so many others avoid it and its community like the plague. I don't know what it is about go, but for some reason it seems impossible to have reasoned—if passionate—disagreement about the language. Any criticisms are hand-waved away as just ranting. Everyone who actually uses it knows that none of these things are real problems. And... what are those real problems, anyway? Can't think of any! I love Rust, but I'm more than happy to dive into its warts and agree with legitimate complaints and concerns. Hell, I love Ruby too and that language is full of questionable decisions. Not only are language designers imperfect, but there's no such thing as a perfect language anyway. Great decisions have downsides, and there's no sense in acting like those downsides don't exist. Why is it that gophers never seem to be willing to admit that their language—like all others—has warts, bad tradeoffs, good tradeoffs with uncomfortable but acceptable downsides, and flat-out mistakes? To any criticism, the response is the same: "you don't understand the design", "go's simplicity is its strength", "I've never needed that feature", etc. Hell, the inventor of `nil` calls it his billion-dollar mistake and someone is in this wider discussion arguing that nil pointer dereferences aren't that big a deal. Where on earth are the gophers that will stand up and say, "Yeah, <X> part of golang sucks. I'd change <Y, Z> if I could. But I still really think it hits the right balance overall." Instead, it's all just regurgitation of the same Kool-Aid.
  - gher-shyu3i 6y ago
    I disagree. I've seen and wrote a lot of golang code, and it's a mess once the domain becomes complex. Those comments are saying the right thing. Golang was designed without any regard to language developments since the 70s, and it shows. It still has null, and for no good reason. No proper enums, let alone pattern matching. These are mainstream features. The only reason golang became popular was because of branding. Its predecessor didn't go anywhere. I admit that concurrency is somewhat ok, but it lacks the expressiveness to make it much more useful. Java is implementing green threads, and is much better equipped to tackle this area (proper concurrent types, immutable types via records, better profiling, hierarchy management, etc.). > Unless you’re building a race car, you don’t need to know the differences between file handling in Linux Mac and windows. And golang does a terrible job at that abstraction: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... > “I don’t understand why it’s designed this way, and I think all good languages should look like lisp/Haskell/rust” False dichotomy. It's possible for languages to be better designed than golang, yet not be lisp/haskell/rust. Java has been making great strides in this area.
    - philosopher1234 6y ago
      In the spirit of keeping this specific, and to demonstrate your understanding, I’d be curious how you’d answer these questions: 1. What is good about go’s file abstraction? What are the specific real world consequences (the article, which I was actually referencing in my comment, doesn’t deal with what happens in practice)? 2. What is the downside of increasing expressiveness? What is the downside of supporting sophisticated abstraction and type systems?
      - gher-shyu3i 6y ago
        1. golang provides a bare bones, yet not truly OS independent API, for accessing files. This makes it easy for the compiler writer, but difficult for the consumer 2. Increasing expressiveness, if not done correctly, can end up in a situation like C++ and Scala. This makes it more difficult to choose a subset of the language to work with, makes it more difficult for the compiler writer, and slows down compile times. We know that one of golang's supposed goals is fast compile times, seemingly at all costs. So they choose to keep the compiler dumb, while pushing complexity to the end user. Java has shown that it is possible to have expressivity, while not having an overburdening type system. This results in safer programs, and a language that has strong modeling capability. golang lacks on both fronts.
tsimionescu 6y ago
I don't think I know of a single thing where there are fewer ways of doing something in Go than there are in Java. There are multiple ways to declare a variable, to pass a value to a function, to declare a constant, to create something similar to an enum, to return errors, to check for errors, to handle closing, to synchronize parallel threads of execution, to initialize a struct, to create a list of items. I can probably go on. What are some examples where Go is simpler than Java, other than its current lack of generics which has always been a known-limitation?
- sagichmal 6y ago
  There is one way to iterate over things, for any kind of elementwise processing: a `for` loop. There is one way to format your code ;)
  - tsimionescu 6y ago
    There are still two ways: the C-style for loop and its variants (for initializer; condition; increment) and the range for loop with its variants (iterate by key, by value, or both). There's also the option of writing a recrusive function. Still less than Java's five (do-while, while, C-style for, range for, recursion), to be fair.
searchableguy 6y ago
For any complex codebase, people will build their own sugar and that may differ in implementation so it depends whether that is a good idea. Subtle differences in similar looking code can trip people and increase complexity. Fortunately, go has a good standard library to compensate for some of it.
stouset 6y ago
Which is simpler? if (ptr == null) { return nil, fmt.Errorf("bad"); } val := *ptr or let value = ptr? If `?` is unacceptable complexity, how on earth do you deal with functions—or, even worse—control flow keywords?

gher-shyu3i 6y ago

It's actually only superficial simplicity. There have been good comments on HN about this issue. Just because the language is "simple", it doesn't hide the complexity of reality, and written code ends up being harder and more verbose and more difficult to manage compared to powerful languages.

philosopher1234 6y ago
With all due respect those comments you’re referencing generally don’t know what they’re talking about. There is a lot hatred on this website for Go, which appears to have more to do with “I don’t understand why it’s designed this way, and I think all good languages should look like lisp/Haskell/rust” than “this design is net negative for developers”. Practical simplicity is all about hiding complexity. Unless you’re building a race car, you don’t need to know the differences between file handling in Linux Mac and windows. It just never comes up. And when it does, it’s possible to peak under the hood. A lot of the criticism of go mistakes “difficult to write” or “not trendy” for “bad design”, and again I assert this is because the critics don’t actually understand what Go is designed for, period.
- stouset 6y ago
  With all due respect, I do understand why go was designed the way it was, and I vehemently disagree with those decisions. I used go for years, and with every passing day I grew more and more disenfranchised with the language. GP is right. Eschewing abstractions in a programming language forces users of that language to deal with it themselves on a recurring basis. Millions of lines of if res, err := fn(...); err != nil { return nil, fmt.Errorf("...") } don't help anyone, and only detract from readability which is bar none the most important part of a code base. Sadly, this is one of many symptoms in the language where problems that could have been solved in the language have instead been pushed down to its users to deal with over and over and over.
  - philosopher1234 6y ago
    You claim to understand the decisions, so I’ll push you on that. Why is go error handling designed the way it is? What are the intended benefits? What are the actual benefits? A follow up, on your abstraction point: why does go eschew abstraction? Intended upside? Actual upside? It’s very clear people in these threads can perceive downsides of some of Go’s decisions, but what about upsides? And further, can you recognize how Go copes with the downsides it’s choices produce?
    - philosopher1234 6y ago
      A lot of the criticism of go is a little bit like a guy who hates New York pizza saying “New York pizza sucks, it’s only 1”. Chicago pizza has 4 more inches which has been state of the art for years” Sure, it’s different, but that doesn’t mean it’s bad, and if your criticism only focuses on one detail and leaves out the whole picture, no kidding you produce a harsh judgement.
      - stouset 6y ago
        Frankly your dismissal of people's legitimate concerns with the language as just uneducated griping by fools is one of the reasons I and so many others avoid it and its community like the plague. I don't know what it is about go, but for some reason it seems impossible to have reasoned—if passionate—disagreement about the language. Any criticisms are hand-waved away as just ranting. Everyone who actually uses it knows that none of these things are real problems. And... what are those real problems, anyway? Can't think of any! I love Rust, but I'm more than happy to dive into its warts and agree with legitimate complaints and concerns. Hell, I love Ruby too and that language is full of questionable decisions. Not only are language designers imperfect, but there's no such thing as a perfect language anyway. Great decisions have downsides, and there's no sense in acting like those downsides don't exist. Why is it that gophers never seem to be willing to admit that their language—like all others—has warts, bad tradeoffs, good tradeoffs with uncomfortable but acceptable downsides, and flat-out mistakes? To any criticism, the response is the same: "you don't understand the design", "go's simplicity is its strength", "I've never needed that feature", etc. Hell, the inventor of `nil` calls it his billion-dollar mistake and someone is in this wider discussion arguing that nil pointer dereferences aren't that big a deal. Where on earth are the gophers that will stand up and say, "Yeah, <X> part of golang sucks. I'd change <Y, Z> if I could. But I still really think it hits the right balance overall." Instead, it's all just regurgitation of the same Kool-Aid.
- gher-shyu3i 6y ago
  I disagree. I've seen and wrote a lot of golang code, and it's a mess once the domain becomes complex. Those comments are saying the right thing. Golang was designed without any regard to language developments since the 70s, and it shows. It still has null, and for no good reason. No proper enums, let alone pattern matching. These are mainstream features. The only reason golang became popular was because of branding. Its predecessor didn't go anywhere. I admit that concurrency is somewhat ok, but it lacks the expressiveness to make it much more useful. Java is implementing green threads, and is much better equipped to tackle this area (proper concurrent types, immutable types via records, better profiling, hierarchy management, etc.). > Unless you’re building a race car, you don’t need to know the differences between file handling in Linux Mac and windows. And golang does a terrible job at that abstraction: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... > “I don’t understand why it’s designed this way, and I think all good languages should look like lisp/Haskell/rust” False dichotomy. It's possible for languages to be better designed than golang, yet not be lisp/haskell/rust. Java has been making great strides in this area.
  - philosopher1234 6y ago
    In the spirit of keeping this specific, and to demonstrate your understanding, I’d be curious how you’d answer these questions: 1. What is good about go’s file abstraction? What are the specific real world consequences (the article, which I was actually referencing in my comment, doesn’t deal with what happens in practice)? 2. What is the downside of increasing expressiveness? What is the downside of supporting sophisticated abstraction and type systems?
    - gher-shyu3i 6y ago
      1. golang provides a bare bones, yet not truly OS independent API, for accessing files. This makes it easy for the compiler writer, but difficult for the consumer 2. Increasing expressiveness, if not done correctly, can end up in a situation like C++ and Scala. This makes it more difficult to choose a subset of the language to work with, makes it more difficult for the compiler writer, and slows down compile times. We know that one of golang's supposed goals is fast compile times, seemingly at all costs. So they choose to keep the compiler dumb, while pushing complexity to the end user. Java has shown that it is possible to have expressivity, while not having an overburdening type system. This results in safer programs, and a language that has strong modeling capability. golang lacks on both fronts.

tsimionescu 6y ago

I don't think I know of a single thing where there are fewer ways of doing something in Go than there are in Java. There are multiple ways to declare a variable, to pass a value to a function, to declare a constant, to create something similar to an enum, to return errors, to check for errors, to handle closing, to synchronize parallel threads of execution, to initialize a struct, to create a list of items. I can probably go on. What are some examples where Go is simpler than Java, other than its current lack of generics which has always been a known-limitation?

sagichmal 6y ago
There is one way to iterate over things, for any kind of elementwise processing: a `for` loop. There is one way to format your code ;)
- tsimionescu 6y ago
  There are still two ways: the C-style for loop and its variants (for initializer; condition; increment) and the range for loop with its variants (iterate by key, by value, or both). There's also the option of writing a recrusive function. Still less than Java's five (do-while, while, C-style for, range for, recursion), to be fair.

searchableguy 6y ago

For any complex codebase, people will build their own sugar and that may differ in implementation so it depends whether that is a good idea. Subtle differences in similar looking code can trip people and increase complexity. Fortunately, go has a good standard library to compensate for some of it.

stouset 6y ago

Which is simpler? if (ptr == null) { return nil, fmt.Errorf("bad"); } val := *ptr or let value = ptr? If `?` is unacceptable complexity, how on earth do you deal with functions—or, even worse—control flow keywords?