6 ms·

This is in line with Go's philosophy, they try to keep the language as simple as possible. Sometimes it means an easy thing in most other languages is difficul

This is in line with Go's philosophy, they try to keep the language as simple as possible. Sometimes it means an easy thing in most other languages is difficult or tiresome to do in Go. Sometimes it means hard-coded values/decisions you can't change (only tabs anyone?). But overall this makes for a language that's very easy to learn, where code from project to project and team to team is very similar and quick to understand. Like anything, it all depends on your needs. We've found it suits ours quite well, and migrating from a Ruby code base has been a breath of fresh air for the team. But we don't have the same performance requirements as Discord.

andai 7y ago
Offtopic but what are you missing when you have to use tabs instead of spaces? I can understand different indentation preferences but I can change the indentation width per tab in my editor. And then everyone can read the code with the indentation they prefer, while the file stays the same.
- nickserv 7y ago
  It's just an example of something that the Go team took a decision on, and won't allow you to change. I mean, even Python lets you choose. I don't really have a problem with it however, even if I do prefer spaces.
  - giancarlostoro 7y ago
    Python chose spaces a la PEP8 by the way.
    - dragonwriter 7y ago
      PEP8 isn't a language requirement, but a style guide. There are tools to enforce style on Python, but the language itself does not.
      - giancarlostoro 7y ago
        Same thing with Go... Tabs aren't enforced, but the out of the box formatter will use tabs. PyCharm will default to trying to follow PEP8, and GoLand will do the same, it will try to follow the gofmt standards. See: https://stackoverflow.com/questions/19094704/indentation-in-go-tabs-or-spaces https://stackoverflow.com/questions/19094704/indentation-in-...
    - marsokod 7y ago
      You can use tabs to indent your python code. Ok, you might be lynched if you share your code but as long as you don't mix tabs and spaces, it is fine.
      - giancarlostoro 7y ago
        Same with Go, you can use spaces.
        _wldu 7y ago
        Or none at all: https://play.golang.org/p/VeEaJbJ6sYT https://play.golang.org/p/VeEaJbJ6sYT
  - monocasa 7y ago
    There's a difference between making decisions that are really open to bikeshedding, and making sweeping decisions in contexts that legitimately need per app tuning like immature GCs. The Azul guys get to claim that you don't need to tune their gc, golang doesn't.
    - geodel 7y ago
      Hmm ..this is why Azul's install and configure guide run in hundreds of pages. All the advanced tuning, profiling and configuring OS commands, setting contingency memory pools are perhaps for GCs which Azul does not sell.
      - monocasa 7y ago
        I mean, they'll let you because the kind of customers want to be able to are the kinds of customers that Azul targets. But everything I've heard from their engineers is that they've solved a lot of customer problems by resetting things to defaults and just letting it have a giant heap to play with. Not sure how that makes the golang position any better.
- tasty_freeze 7y ago
  > everyone can read the code with the indentation they prefer, while the file stays the same. Have you ever worked in a code base with many contributors that changed over the course of years? In my experience it always ends up a jumble where indentation is screwed up and no particular tab setting makes things right. I've worked on files where different lines in the same file might assume tab spacing of 2, 3, 4, or 8. For example, say there is a function with a lot of parameters, so the argument list gets split across lines. The first line has, say, two tabs before the start of the function call. The continuation line ideally should be two tabs then a bunch of spaces to make the arguments line up with the arguments from the first line. But in practice people end up putting three or four tabs to make the 2nd line line up with the arguments of the first line. It looks great with whatever tab setting the person used at that moment, but then change tab spacing and it no longer is aligned.
  - Will_Parker 7y ago
    > In my experience it always ends up a jumble where indentation is screwed up and no particular tab setting makes things right. Consider linting tools in your build.
  - _ph_ 7y ago
    On the good side, the problem of mixing tabs and spaces does normally not appear in Go sources, as gofmt always converts spaces to tabs, so there is no inconsistant indentation. Normally I prefer spaces to tabs because I dislike the mixing, but gofmt solves this nicely for me.
    - tasty_freeze 7y ago
      Please explain to me how this works for the case I outlineed, eg: some_function(arg1, arg2, arg3, arg4, arg5, arg6); For the sake of argument, say tabstop=4. If the first line starts with two tabs, will the second line also have two tabs and then a bunch of spaces, or will it start with five tabs and a couple spaces?
      - 7y ago
- Uristqwerty 7y ago
  I don't know about anyone else, but I like aligning certain things at half-indents (labels/cases half an indent back, so you can skim the silhouette of both the surrounding block and jump targets within it; braceless if/for bodies to emphasize their single-statement nature (that convention alone would have made "goto fail" blatantly obvious to human readers, though not helped the compiler); virtual blocks created by API structure (between glBegin() to glEnd() in the OpenGL 1.x days)). Thing is, few if any IDEs support the concept, so if I want to have half-indents, I must use spaces. Unfortunately, these days that means giving up and using a more common indent style most of the time, as the extra bit of readability generally isn't worth losing automatic formatting or multi-line indent changes.
  - mntmoss 7y ago
    You can use empty scope braces for this task in most languages. It's not a "half-indent" but it gives you the alignment and informs responsible variable usage.
  - takeda 7y ago
    So you are the person that ruins it for everyone (are you emacs user by any chance?). Tabs are more versatile, you can even use proportional fonts with them. Projects end up using tabs because many people end up mixing them together (unknowingly or in your case knowingly using configuration that is unavailable in many IDEs). BTW when you mix spaces with tabs you eliminate all benefits that tabs give (for example you no longer can dynamically change tab size without ruining formatting.
    - Uristqwerty 7y ago
      If I were an emacs user, I'd figure out how to write a plugin to display tab-indented code to my preferences. No, I used to be a notepad user (on personal projects, not shared work) (you can kinda see it in the use of indentation to help convey information that IDEs would use font or colour to emphasize), and these days use tabs but longingly wish Eclipse, etc. had more options in their already-massive formatting configuration dialogues.
kerkeslager 7y ago
"Simple" when used in programming, doesn't mean anything. So let's be clear here: what we mean is that compilation occurs in a single pass and the artifact of compilation is a single binary. These are two things that make a lot of sense at Google if you read why they were done. But unless you're working at Google, I struggle to guess why you would care about either of these things. The first requires sacrificing anything resembling a reasonable type system, and even with that sacrifice Go doesn't really deliver: are we really supposed to buy that "go generate" isn't a compilation step? The second is sort of nice, but not nice enough to be a factor in choosing a language. The core language is currently small, but every language grows with time: even C with its slow-moving, change-averse standards body has grown over the years. Currently people are refreshed by the lack of horrible dependency trees in Go, but that's mostly because there aren't many libraries available for Go: that will also change with time (and you can just not import all of CPAN/PyPy/npm/etc. in any language, so Go isn't special anyway). If you like Go for some aesthetic of "simplicity", then sure, I guess I can see how it has that. But if we're discussing pros and cons, aesthetics are pretty subjective and not really work talking about.
- papaf 7y ago
  I don't agree with your definition of simplicity. I like Go and I consider it a simple language because: 1. I can keep most of the language in my head and I don't hit productivity pauses where I have to look something up. 2. There is usually only one way to do things and I don't have to spend time deciding on the right way. For me, these qualities make programming very enjoyable.
  - kerkeslager 7y ago
    > I don't agree with your definition of simplicity. You mean where I explicitly said that "simple" didn't mean anything, so we should talk about what we mean more concretely? > 1. I can keep most of the language in my head and I don't hit productivity pauses where I have to look something up. The core language is currently small, but every language grows with time: even C with its slow-moving, change-averse standards body has grown over the years. > 2. There is usually only one way to do things and I don't have to spend time deciding on the right way. Go supports functional programming and object-oriented programming, so pretty much anything you want to do has at least two ways to do it--it sounds like you just aren't familiar with the various ways. The problem with having more than one way to do things isn't usually choosing which to use, by the way: the problem is when people use one of the many ways differently within the same codebase and it doesn't play nicely with the way things are done in the codebase. This isn't really a criticism of Go, however: I can't think of a language that actually delivers on there being one right way to do things (most don't even make that promise--Python makes the promise but certainly doesn't deliver on it).

andai 7y ago

Offtopic but what are you missing when you have to use tabs instead of spaces? I can understand different indentation preferences but I can change the indentation width per tab in my editor. And then everyone can read the code with the indentation they prefer, while the file stays the same.

nickserv 7y ago
It's just an example of something that the Go team took a decision on, and won't allow you to change. I mean, even Python lets you choose. I don't really have a problem with it however, even if I do prefer spaces.
- giancarlostoro 7y ago
  Python chose spaces a la PEP8 by the way.
  - dragonwriter 7y ago
    PEP8 isn't a language requirement, but a style guide. There are tools to enforce style on Python, but the language itself does not.
    - giancarlostoro 7y ago
      Same thing with Go... Tabs aren't enforced, but the out of the box formatter will use tabs. PyCharm will default to trying to follow PEP8, and GoLand will do the same, it will try to follow the gofmt standards. See: https://stackoverflow.com/questions/19094704/indentation-in-go-tabs-or-spaces https://stackoverflow.com/questions/19094704/indentation-in-...
  - marsokod 7y ago
    You can use tabs to indent your python code. Ok, you might be lynched if you share your code but as long as you don't mix tabs and spaces, it is fine.
    - giancarlostoro 7y ago
      Same with Go, you can use spaces.
      - _wldu 7y ago
        Or none at all: https://play.golang.org/p/VeEaJbJ6sYT https://play.golang.org/p/VeEaJbJ6sYT
- monocasa 7y ago
  There's a difference between making decisions that are really open to bikeshedding, and making sweeping decisions in contexts that legitimately need per app tuning like immature GCs. The Azul guys get to claim that you don't need to tune their gc, golang doesn't.
  - geodel 7y ago
    Hmm ..this is why Azul's install and configure guide run in hundreds of pages. All the advanced tuning, profiling and configuring OS commands, setting contingency memory pools are perhaps for GCs which Azul does not sell.
    - monocasa 7y ago
      I mean, they'll let you because the kind of customers want to be able to are the kinds of customers that Azul targets. But everything I've heard from their engineers is that they've solved a lot of customer problems by resetting things to defaults and just letting it have a giant heap to play with. Not sure how that makes the golang position any better.
tasty_freeze 7y ago
> everyone can read the code with the indentation they prefer, while the file stays the same. Have you ever worked in a code base with many contributors that changed over the course of years? In my experience it always ends up a jumble where indentation is screwed up and no particular tab setting makes things right. I've worked on files where different lines in the same file might assume tab spacing of 2, 3, 4, or 8. For example, say there is a function with a lot of parameters, so the argument list gets split across lines. The first line has, say, two tabs before the start of the function call. The continuation line ideally should be two tabs then a bunch of spaces to make the arguments line up with the arguments from the first line. But in practice people end up putting three or four tabs to make the 2nd line line up with the arguments of the first line. It looks great with whatever tab setting the person used at that moment, but then change tab spacing and it no longer is aligned.
- Will_Parker 7y ago
  > In my experience it always ends up a jumble where indentation is screwed up and no particular tab setting makes things right. Consider linting tools in your build.
- _ph_ 7y ago
  On the good side, the problem of mixing tabs and spaces does normally not appear in Go sources, as gofmt always converts spaces to tabs, so there is no inconsistant indentation. Normally I prefer spaces to tabs because I dislike the mixing, but gofmt solves this nicely for me.
  - tasty_freeze 7y ago
    Please explain to me how this works for the case I outlineed, eg: some_function(arg1, arg2, arg3, arg4, arg5, arg6); For the sake of argument, say tabstop=4. If the first line starts with two tabs, will the second line also have two tabs and then a bunch of spaces, or will it start with five tabs and a couple spaces?
    - 7y ago
Uristqwerty 7y ago
I don't know about anyone else, but I like aligning certain things at half-indents (labels/cases half an indent back, so you can skim the silhouette of both the surrounding block and jump targets within it; braceless if/for bodies to emphasize their single-statement nature (that convention alone would have made "goto fail" blatantly obvious to human readers, though not helped the compiler); virtual blocks created by API structure (between glBegin() to glEnd() in the OpenGL 1.x days)). Thing is, few if any IDEs support the concept, so if I want to have half-indents, I must use spaces. Unfortunately, these days that means giving up and using a more common indent style most of the time, as the extra bit of readability generally isn't worth losing automatic formatting or multi-line indent changes.
- mntmoss 7y ago
  You can use empty scope braces for this task in most languages. It's not a "half-indent" but it gives you the alignment and informs responsible variable usage.
- takeda 7y ago
  So you are the person that ruins it for everyone (are you emacs user by any chance?). Tabs are more versatile, you can even use proportional fonts with them. Projects end up using tabs because many people end up mixing them together (unknowingly or in your case knowingly using configuration that is unavailable in many IDEs). BTW when you mix spaces with tabs you eliminate all benefits that tabs give (for example you no longer can dynamically change tab size without ruining formatting.
  - Uristqwerty 7y ago
    If I were an emacs user, I'd figure out how to write a plugin to display tab-indented code to my preferences. No, I used to be a notepad user (on personal projects, not shared work) (you can kinda see it in the use of indentation to help convey information that IDEs would use font or colour to emphasize), and these days use tabs but longingly wish Eclipse, etc. had more options in their already-massive formatting configuration dialogues.

kerkeslager 7y ago

"Simple" when used in programming, doesn't mean anything. So let's be clear here: what we mean is that compilation occurs in a single pass and the artifact of compilation is a single binary. These are two things that make a lot of sense at Google if you read why they were done. But unless you're working at Google, I struggle to guess why you would care about either of these things. The first requires sacrificing anything resembling a reasonable type system, and even with that sacrifice Go doesn't really deliver: are we really supposed to buy that "go generate" isn't a compilation step? The second is sort of nice, but not nice enough to be a factor in choosing a language. The core language is currently small, but every language grows with time: even C with its slow-moving, change-averse standards body has grown over the years. Currently people are refreshed by the lack of horrible dependency trees in Go, but that's mostly because there aren't many libraries available for Go: that will also change with time (and you can just not import all of CPAN/PyPy/npm/etc. in any language, so Go isn't special anyway). If you like Go for some aesthetic of "simplicity", then sure, I guess I can see how it has that. But if we're discussing pros and cons, aesthetics are pretty subjective and not really work talking about.

papaf 7y ago
I don't agree with your definition of simplicity. I like Go and I consider it a simple language because: 1. I can keep most of the language in my head and I don't hit productivity pauses where I have to look something up. 2. There is usually only one way to do things and I don't have to spend time deciding on the right way. For me, these qualities make programming very enjoyable.
- kerkeslager 7y ago
  > I don't agree with your definition of simplicity. You mean where I explicitly said that "simple" didn't mean anything, so we should talk about what we mean more concretely? > 1. I can keep most of the language in my head and I don't hit productivity pauses where I have to look something up. The core language is currently small, but every language grows with time: even C with its slow-moving, change-averse standards body has grown over the years. > 2. There is usually only one way to do things and I don't have to spend time deciding on the right way. Go supports functional programming and object-oriented programming, so pretty much anything you want to do has at least two ways to do it--it sounds like you just aren't familiar with the various ways. The problem with having more than one way to do things isn't usually choosing which to use, by the way: the problem is when people use one of the many ways differently within the same codebase and it doesn't play nicely with the way things are done in the codebase. This isn't really a criticism of Go, however: I can't think of a language that actually delivers on there being one right way to do things (most don't even make that promise--Python makes the promise but certainly doesn't deliver on it).