4 ms·

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 clu

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.

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.