I think the author is a victim of the fallacy that Go looks simple, even though it's a very low-level language (think C without the quirks). Most of the — very valid — points they make are a consequence of Go not hiding complexity from the programer.
Problems with Go's design
71–80 of 88 posts
Re: Problems with Go's design
#72Earlier quoted context omitted.
RodericDay: Language design decisions by superstars like Robert Griesemer, Rob Pike, and Ken Thompson (the creators of Go) that may seem inconvenient or annoying when working on small to mid-size projects could very well make life much easier when working on giant projects which take years and do not fit on any single person's head. I'm reminded of this insight by Lawrence Kesteloot of Dreamworks: "What’s particularl…
I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional program…
The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC.
Are you aware of a 2M lines code base that fully relies on FP and immutable data?
Re: Problems with Go's design
#73Nailed it. I love Go, but all of the things listed in this article (and more) make me bash my head against the wall more often than I'd like to admit. That said, there are some fantastic things about Go that aren't listed in the article (I feel like gofmt changed my life). Don't let this article discourage you from investigating Go as a tool to use!
I've never understood this, every Go user swears on gofmt for some reason that I just dont get. Can you elaborate how gofmt changed your life? Its a really simple tool and lots of languages have those...
It also opens the door to automatic code modification (like goimports or gorename), and because the code is always formatted the same, you avoid "noise" in your diffs related to trivial changes (spacing, etc.).
Re: Problems with Go's design
#74Earlier quoted context omitted.
You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt jus…
The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no…
You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the next line, or whether... I could go on. All of these are things people tend to have preferences for, so when you work with multiple people, having a consistent style is a huge benefit to reading other people's code.
Imagine a simple CSS example: Some people like to do one line per element, while others like one line per style:
``` a { font-weight: bold; color: blue; text-decoration: none; } ```
vs
``` a { font-weight: bold; color: blue; text-decoration: none; } ```
That's a pretty trivial example, and for many people, both are acceptable. But when you get into large projects with hundreds or thousands of styles, or you have to code review that one change that was made off-screen on a really long line of CSS, one of those styles is going to be more conducive to code reviews and readability. Stylistic concerns are very real, and gofmt largely makes those go away.
Like kyrra said, you may not be opinionated on the matter, but other people are, and gofmt, et al, completely remove that concern from the table.
Re: Problems with Go's design
#75Earlier quoted context omitted.
I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional program…
The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?
Erlang's very existence is a pretty solid refutation of the claims you're putting forth. :P
Re: Problems with Go's design
#76Earlier quoted context omitted.
I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional program…
The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?
I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation.
LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide.
This chap claims to write very robust programs, entirely functionally that are worth billions in their operation.
http://logicaltypes.blogspot.co.uk/2015/08/pure-functional-p...
Re: Problems with Go's design
#77Earlier quoted context omitted.
The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no…
You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the nex…
erk, that totally screwed up my code example... sorry. :)
Re: Problems with Go's design
#78Earlier quoted context omitted.
The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no…
Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflic…
Any code reformatting tool helps remove that. Gofmt isn't the only code reformatting tool in existence.
Re: Problems with Go's design
#79Earlier quoted context omitted.
The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no…
You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the nex…
Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.
Re: Problems with Go's design
#80Earlier quoted context omitted.
The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?
Erlang's very existence is a pretty solid refutation of the claims you're putting forth. :P
I don't think so. An Erlang process has no mutable state. But it can communicate with another Erlang process to set/get some state. This is how a lot of mutable structures are implemented in Erlang.