5 ms·

> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such gro

> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community. Very true. This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but rather to create one that has a high enough abstraction to be productive but simple enough so that people coming from different backgrounds can acquaint themselves with it quickly. In other words, it is a language for teams.

bkeroack 11y ago
I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).
- tptacek 11y ago
  That's true, but it's also (sometimes) liberating. In extremely flexible languages, you can find yourself burning lots of time finding the most "elegant" way to express simple concepts, like "how am I going to write this SQL column to this series of DIVs". Not coincidentally, Golang sucks at this problem. But there is something about writing in Golang that makes it easier to dive into meatier code. For instance: I've written programmable assemblers in Ruby and in Golang. With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler.
  - tomp 11y ago
    > With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler. That is a great way to compare languages. Incidentally, that's the same way I feel about Scala vs Python.
  - danieldk 11y ago
    With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler. Same experience here. I am working on a neural net dependency parser and pretty much started C++ and Go implementations in parallel, because this was one of my first larger Go projects and I had my doubts about using Go for this. In the meanwhile, the Go implementation is a complete and fast parser (the number crunching is done using OpenBLAS via gonum), which I now use for research. In C++ I am still tweaking the abstractions for the basic stuff (word embeddings, transition systems). Of course, I could make a simple, straightforward implementation in C++, but the language encourages you to finetune the abstractions and you have to the choice between template-heavy/light code (with its respective downsides). I also found that Go encourages me more to break stuff up more in different packages. In C++, every separate library means new build machinery, some way to roll it out on systems, etc. In Go it's as simple as creating a new repository and adding imports.
- danieldk 11y ago
  I agree that the number of possible solutions is often smaller than in other languages. But there are still often multiple ways which are considered idiomatic Go (in the sense that they are all widely used). E.g. if you build some iterable type, you could provide iteration via: 1. Go channels: send every value over a channel. 2. Callbacks: provide an iteration function which takes a callback function. 3. Closures: let a closure return the next value when called. 4. Iterators: create a separate iterator type with e.g. HasNext()/Next() methods. In this respect C was much simpler, because only (2) and (4) were really possible (and sometimes indexing).
  - Merovius 11y ago
    1 is a misconception. Go channels are fundamentally useless for iteration, because you leak goroutines with break or return inside the loop. Same goes for 3 probably. 2 and 4 are the idiomatic ways (and afaict the only ones used in the stdlib). edit: Okay, 3 should work too, sorry.
scriptproof 11y ago
But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.
- doomrobo 11y ago
  >Linux (1991) >KDE (1996) >LibreOffice (based on StarOffice, 6.0 released in 2002) >VLC (2001) >LLVM (2003) I think you have a point r.e there being more smaller projects than large projects with large teams. But this is a terrible argument. Go was released in 2007. Are you being facetious or are you suggesting that porting a mature codebase to Go is that easy? CoreOS was released in 2013 and so was Docker. I know that Docker actually ported to Go after the fact, but it was still relatively young and Go was already mature by then.
  - insertnickname 11y ago
    Go was released in late 2009.
- danieldk 11y ago
  This is a weird argument to make, since Go was first introduced in 2009 and the first stable version was released in 2012. All those projects precede Go by a decade or more. Also, despite Go's short existence, there are already a surprising number of large Go project (Docker, Syncthing, etcd).
qznc 11y ago
"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels" Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.
- discardorama 11y ago
  I don't think you can say "Reminds me of Java" with "Simple enough". Java is too complicated now.
  - sz4kerto 11y ago
    Java as a language is still very simple. Frameworks are complicated -- but I doubt this can be avoided in the long run, Go will have similar problems.
XorNot 11y ago
The most pleasant thing about learning Go for me has been that largely, if the compiler is happy, my code works. At times the compiler feels nitpicky, but so far that opinionation has tended to make me write better code that is unquestionably very readable so far.
deleted 11y ago
[deleted]

bkeroack 11y ago

I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).

tptacek 11y ago
That's true, but it's also (sometimes) liberating. In extremely flexible languages, you can find yourself burning lots of time finding the most "elegant" way to express simple concepts, like "how am I going to write this SQL column to this series of DIVs". Not coincidentally, Golang sucks at this problem. But there is something about writing in Golang that makes it easier to dive into meatier code. For instance: I've written programmable assemblers in Ruby and in Golang. With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler.
- tomp 11y ago
  > With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler. That is a great way to compare languages. Incidentally, that's the same way I feel about Scala vs Python.
- danieldk 11y ago
  With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler. Same experience here. I am working on a neural net dependency parser and pretty much started C++ and Go implementations in parallel, because this was one of my first larger Go projects and I had my doubts about using Go for this. In the meanwhile, the Go implementation is a complete and fast parser (the number crunching is done using OpenBLAS via gonum), which I now use for research. In C++ I am still tweaking the abstractions for the basic stuff (word embeddings, transition systems). Of course, I could make a simple, straightforward implementation in C++, but the language encourages you to finetune the abstractions and you have to the choice between template-heavy/light code (with its respective downsides). I also found that Go encourages me more to break stuff up more in different packages. In C++, every separate library means new build machinery, some way to roll it out on systems, etc. In Go it's as simple as creating a new repository and adding imports.
danieldk 11y ago
I agree that the number of possible solutions is often smaller than in other languages. But there are still often multiple ways which are considered idiomatic Go (in the sense that they are all widely used). E.g. if you build some iterable type, you could provide iteration via: 1. Go channels: send every value over a channel. 2. Callbacks: provide an iteration function which takes a callback function. 3. Closures: let a closure return the next value when called. 4. Iterators: create a separate iterator type with e.g. HasNext()/Next() methods. In this respect C was much simpler, because only (2) and (4) were really possible (and sometimes indexing).
- Merovius 11y ago
  1 is a misconception. Go channels are fundamentally useless for iteration, because you leak goroutines with break or return inside the loop. Same goes for 3 probably. 2 and 4 are the idiomatic ways (and afaict the only ones used in the stdlib). edit: Okay, 3 should work too, sorry.

scriptproof 11y ago

But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.

doomrobo 11y ago
>Linux (1991) >KDE (1996) >LibreOffice (based on StarOffice, 6.0 released in 2002) >VLC (2001) >LLVM (2003) I think you have a point r.e there being more smaller projects than large projects with large teams. But this is a terrible argument. Go was released in 2007. Are you being facetious or are you suggesting that porting a mature codebase to Go is that easy? CoreOS was released in 2013 and so was Docker. I know that Docker actually ported to Go after the fact, but it was still relatively young and Go was already mature by then.
- insertnickname 11y ago
  Go was released in late 2009.
danieldk 11y ago
This is a weird argument to make, since Go was first introduced in 2009 and the first stable version was released in 2012. All those projects precede Go by a decade or more. Also, despite Go's short existence, there are already a surprising number of large Go project (Docker, Syncthing, etcd).

qznc 11y ago

"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels" Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.

discardorama 11y ago
I don't think you can say "Reminds me of Java" with "Simple enough". Java is too complicated now.
- sz4kerto 11y ago
  Java as a language is still very simple. Frameworks are complicated -- but I doubt this can be avoided in the long run, Go will have similar problems.

XorNot 11y ago

The most pleasant thing about learning Go for me has been that largely, if the compiler is happy, my code works. At times the compiler feels nitpicky, but so far that opinionation has tended to make me write better code that is unquestionably very readable so far.

deleted 11y ago

[deleted]