30 ms·

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. The same goes with the Go ecosystem and tools. You might not like how gofmt forces your code or the documentation conventions used by golint but the fact that we all use the same convention and documentation is awesome and it's what allows things like godoc.org. I think the proverb is "gofmt's style is no one's favorite, yet gofmt is everyone's favorite". And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. So, yeah, I like that they didn't fragment the community around something as arbitrary as this. And I get that some people won't like it, just as they don't like the lack of generics, but there is strength in some of these approaches that isn't immediately obvious.

inlined 7y ago
> errors being values Though with generics we could have the error values be less invasive. Learning the Scala mindset was eye opening. For e.g. the design patterns of an Optional[T]’s primary code flow are the same as a Try[T,E]. With common transformation idioms, you learn to recognize code patterns the same way one might recognize data structures. It’s no less magical and it simplifies greatly.
- bmurphy1976 7y ago
  But it doesn't simplify, it just moves the complexity around. That's not necessarily bad, you get better safety guarantees as a result but you also spend more time fighting the compiler and locked in design space trying to get a model that works (and even MORE time is spent if you want it to be readable and something that other people can grok quickly). I don't see this as an either/or situation. There's a continuum between do whatever the hell you want C and rigorously defined Idris code. Picking a spot on that line involves many trade-offs and everybody has to choose what's right for their situation. That means Go approach is sometimes superior to the Scala approach for a certain class of problems in certain domains. Edit: don't downvote me, tell me how I'm wrong.
  - UK-AL 7y ago
    Honestly I think moving to towards Idris/coq level type systems saves more time in the long run. Being close c means you discover errors at run time, then you have to come back to cover them.
    - bmurphy1976 7y ago
      For humongous projects or critically important ones I'd agree with you, but for smaller/mid sized projects I can't agree. I think it's total overkill in many instances. Would be nice if there was a language that scaled from C to Idris gracefully, but C++ and Scala make me think that's a pipe dream.
KirinDave 7y ago
> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sticky label that's difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.
- wybiral 7y ago
  > I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that adding generics or other dramatic features to a language can cause with the 2to3 move. There are still projects based on 2.7. It was hard to get people all on the same page once the community was split. What's also interesting is to watch the same thing happen with asyncio, which is practically an all-or-nothing thing to use in your Python project, so much so that most Python code still doesn't use it. Just an observation, but breaking changes to a language can really do a number on the community.
  - KirinDave 7y ago
    I don't think folks are on 2.7 because they love it. I think they're there because it's difficult and expensive to migrate Python code.
    - wybiral 7y ago
      There were multiple reasons based on my experience. New people were still using 2.7 tutorials because there was way more information out there than for 3. And package managers in Linux systems took a long time to change. But the asyncio example is probably a better example of a fundamental program design change that's causing weird fracturing and incompatible library designs. Trying to use non-async from an async framework is a mess, trying to use async from a non-async is hard to integrate, etc.
leshow 7y ago
> It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. All of this is also true of the generic implementation with Result. Except that (IMO) it's much nicer to work with.
nkozyra 7y ago
> and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. Is it fair to compare external packages to core language features? There is nothing preventing a go mod/dep left-pad
- wybiral 7y ago
  Language choices like lacking generics make the over-reliance on dependencies less.
  - qtplatypus 7y ago
    Isn't that a nice way of saying "lacking generics makes people reimplement the same code?". If they are not using some sort of dependency then the code is being duplicated.
pbreit 7y ago
If it matters to anyone, this novice finds “if” easier to understand than “try”. Very refreshing for novice to agree on expert on a topic.
- tdb7893 7y ago
  I don't think many people think that "if" is hard to understand. My problem with the "if" statements is that a third to half of the lines in a couple of my codebase are roughly the same copy pasted error handling (the codebases use the os package, which has pretty much every function return errors) and having all of that same boilerplate just clutters the code and makes it harder to read. It would be a real readability win to have less boilerplate in Go.
  - Someone 7y ago
    Had anybody ever thought about using ‘go generate’ to insert missing ‘if err… return’ clauses with descriptive error messages? If so, where’s (s)he buried? :-)
crimsonalucard 7y ago
The problem with this is that code that can potentially produce errors cannot compose. You need a value that is either correct or an error, not something that returns two values.
shanemhansen 7y ago
Do I like verbose errors? No. Do I like explicit errors? Yes. This is why generics and a Result<T> type will be nice because we will be able to factor out that explicit error handling.
kerng 7y ago
There were languages like that in last millenium, like C. Maybe something like vectored error handling (like in Basic) would fit the language better - was curious why Golang didnt implement that - seems a natural pattern their model would work well with.
abtinf 7y ago
> It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Along these lines, I would have much preferred to see the opposite of this proposal: the total removal of named returns. They add magic and confusion, and they are redundant with normal returns. Except in the absolute simplest and shortest functions, I always reject named returns during code review. They are currently the only example of C++ style policy declaring we-don’t-use-that-feature-in-our-org I’ve run into with Go. Try/check would’ve been the second.
smcl 7y ago
> And things like the lack of abstractions and generics are what create a community > that's less reliant on dependencies. "A little copying is better than a little > dependency" and you can see it in stark contrast to something like the JS community > with its require('left-pad') NPM ecosystem. The dependency-hell of node projects is in no way whatsoever related to sensible, accepted programming paradigms like generics. Their absence from Go is a widely accepted shortcoming of the language. It doesn't make Go a bad language, and it doesn't reflect on you or anyone in the Go community who enjoy using the language, but you don't have to try so hard to rationalise their absence, especially since they're one of the more prominent things in the Go 2 drafts.
fredmorcos 7y ago
> And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. "A little copying", "less reliant on dependencies"... do you even vendor bro
neop1x 7y ago
I agree. Handling errors is difficult and that is what it is. Many times errors can be handled properly in the function and "if" helps you think about it. Programmers shouldn't be lazy to handle errors, just forwarding them to the caller. That way it may end up like Java, where many functions throw something but lots of programmers don't care so programs simply crash with a long, confusing, unhandled exception stacktrace. How many ppl handle I/O errors in Python for example? Since I started using Go, my software is much more stable.

inlined 7y ago

> errors being values Though with generics we could have the error values be less invasive. Learning the Scala mindset was eye opening. For e.g. the design patterns of an Optional[T]’s primary code flow are the same as a Try[T,E]. With common transformation idioms, you learn to recognize code patterns the same way one might recognize data structures. It’s no less magical and it simplifies greatly.

bmurphy1976 7y ago
But it doesn't simplify, it just moves the complexity around. That's not necessarily bad, you get better safety guarantees as a result but you also spend more time fighting the compiler and locked in design space trying to get a model that works (and even MORE time is spent if you want it to be readable and something that other people can grok quickly). I don't see this as an either/or situation. There's a continuum between do whatever the hell you want C and rigorously defined Idris code. Picking a spot on that line involves many trade-offs and everybody has to choose what's right for their situation. That means Go approach is sometimes superior to the Scala approach for a certain class of problems in certain domains. Edit: don't downvote me, tell me how I'm wrong.
- UK-AL 7y ago
  Honestly I think moving to towards Idris/coq level type systems saves more time in the long run. Being close c means you discover errors at run time, then you have to come back to cover them.
  - bmurphy1976 7y ago
    For humongous projects or critically important ones I'd agree with you, but for smaller/mid sized projects I can't agree. I think it's total overkill in many instances. Would be nice if there was a language that scaled from C to Idris gracefully, but C++ and Scala make me think that's a pipe dream.

KirinDave 7y ago

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sticky label that's difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.

wybiral 7y ago
> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that adding generics or other dramatic features to a language can cause with the 2to3 move. There are still projects based on 2.7. It was hard to get people all on the same page once the community was split. What's also interesting is to watch the same thing happen with asyncio, which is practically an all-or-nothing thing to use in your Python project, so much so that most Python code still doesn't use it. Just an observation, but breaking changes to a language can really do a number on the community.
- KirinDave 7y ago
  I don't think folks are on 2.7 because they love it. I think they're there because it's difficult and expensive to migrate Python code.
  - wybiral 7y ago
    There were multiple reasons based on my experience. New people were still using 2.7 tutorials because there was way more information out there than for 3. And package managers in Linux systems took a long time to change. But the asyncio example is probably a better example of a fundamental program design change that's causing weird fracturing and incompatible library designs. Trying to use non-async from an async framework is a mess, trying to use async from a non-async is hard to integrate, etc.

leshow 7y ago

> It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. All of this is also true of the generic implementation with Result. Except that (IMO) it's much nicer to work with.

nkozyra 7y ago

> and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. Is it fair to compare external packages to core language features? There is nothing preventing a go mod/dep left-pad

wybiral 7y ago
Language choices like lacking generics make the over-reliance on dependencies less.
- qtplatypus 7y ago
  Isn't that a nice way of saying "lacking generics makes people reimplement the same code?". If they are not using some sort of dependency then the code is being duplicated.

pbreit 7y ago

If it matters to anyone, this novice finds “if” easier to understand than “try”. Very refreshing for novice to agree on expert on a topic.

tdb7893 7y ago
I don't think many people think that "if" is hard to understand. My problem with the "if" statements is that a third to half of the lines in a couple of my codebase are roughly the same copy pasted error handling (the codebases use the os package, which has pretty much every function return errors) and having all of that same boilerplate just clutters the code and makes it harder to read. It would be a real readability win to have less boilerplate in Go.
- Someone 7y ago
  Had anybody ever thought about using ‘go generate’ to insert missing ‘if err… return’ clauses with descriptive error messages? If so, where’s (s)he buried? :-)

crimsonalucard 7y ago

The problem with this is that code that can potentially produce errors cannot compose. You need a value that is either correct or an error, not something that returns two values.

shanemhansen 7y ago

Do I like verbose errors? No. Do I like explicit errors? Yes. This is why generics and a Result<T> type will be nice because we will be able to factor out that explicit error handling.

kerng 7y ago

There were languages like that in last millenium, like C. Maybe something like vectored error handling (like in Basic) would fit the language better - was curious why Golang didnt implement that - seems a natural pattern their model would work well with.

abtinf 7y ago

> It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Along these lines, I would have much preferred to see the opposite of this proposal: the total removal of named returns. They add magic and confusion, and they are redundant with normal returns. Except in the absolute simplest and shortest functions, I always reject named returns during code review. They are currently the only example of C++ style policy declaring we-don’t-use-that-feature-in-our-org I’ve run into with Go. Try/check would’ve been the second.

smcl 7y ago

> And things like the lack of abstractions and generics are what create a community > that's less reliant on dependencies. "A little copying is better than a little > dependency" and you can see it in stark contrast to something like the JS community > with its require('left-pad') NPM ecosystem. The dependency-hell of node projects is in no way whatsoever related to sensible, accepted programming paradigms like generics. Their absence from Go is a widely accepted shortcoming of the language. It doesn't make Go a bad language, and it doesn't reflect on you or anyone in the Go community who enjoy using the language, but you don't have to try so hard to rationalise their absence, especially since they're one of the more prominent things in the Go 2 drafts.

fredmorcos 7y ago

> And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. "A little copying", "less reliant on dependencies"... do you even vendor bro

neop1x 7y ago

I agree. Handling errors is difficult and that is what it is. Many times errors can be handled properly in the function and "if" helps you think about it. Programmers shouldn't be lazy to handle errors, just forwarding them to the caller. That way it may end up like Java, where many functions throw something but lots of programmers don't care so programs simply crash with a long, confusing, unhandled exception stacktrace. How many ppl handle I/O errors in Python for example? Since I started using Go, my software is much more stable.