What is idiomatic Go?

[Brenden]

I've heard a lot of strong opinions of some Go software projects based on how idiomatic they are, but from what I can tell these idioms are highly subjective. Some coders say using Go reflect is not idiomatic and yet Go's own JSON package uses it (and couldn't really work without it). For example, how is one Go web framework less Go idiomatic than the next? Why is "magic" bad? And so on.

I just want to know who/what/where the authority of what great Go code is (aka idiomatic Go code) can be found.

Thanks.

[Tamás Gulácsi]

Primarily in the standard library.

I'd even say camlistore.org (Brad has strong opinions about maintainable code but he is a member of the Go Authors.)

[Robert Melton]

On Wed, Oct 15, 2014 at 1:14 AM, Brenden <bso...@gmail.com> wrote:
> I've heard a lot of strong opinions of some Go software projects based on
> how idiomatic they are, but from what I can tell these idioms are highly
> subjective.

Idioms are naturally subjective. They are patterns that are NOT
built-in to the language. They have a lot of value, as they form a
pattern-oriented shorthand useful for both reading and writing code.

> Some coders say using Go reflect is not idiomatic and yet Go's
> own JSON package uses it (and couldn't really work without it). For example,
> how is one Go web framework less Go idiomatic than the next? Why is "magic"
> bad? And so on.

Again, this is all very subjective. If you are experienced with Go
when you open idiomatic Go, it should be very comfortable. The way
errors are handed, the way the code is organized, none of it should be
particularly surprising. This lets you focus on the problem at hand,
rather than all that other nonsense. Idioms provide shorthand.

Go values explicitness (in both code and costs), and hence attracted
developers who value the same. So having "magic" (non-explicit, hard
to understand costs) naturally goes against the grain of the
community. I don't think reflection (or any other feature) is
inherently non-idiomatic, but nearly any feature can be abused and
turned into a mess.

> I just want to know who/what/where the authority of what great Go code is
> (aka idiomatic Go code) can be found.

Start with How to Write Go Code, Effective Go and of course the
standard library. But in the end, the authority will be what the
community accepts and rejects.

--
Robert Melton | http://robertmelton.com

[luz...@gmail.com]

On Wednesday, October 15, 2014 7:14:40 AM UTC+2, Brenden wrote:

I just want to know who/what/where the authority of what great Go code is (aka idiomatic Go code) can be found.

A helpful resource: https://code.google.com/p/go-wiki/wiki/CodeReviewComments 

[tomwilde]

On Wednesday, October 15, 2014 7:14:40 AM UTC+2, Brenden wrote:

For example, how is one Go web framework less Go idiomatic than the next? Why is "magic" bad? And so on.

In my own opinion frameworks are fundamentally misaligned with what one would consider idiomatic Go. The frameworks I have encountered in other languages are mostly making up for the low signal-to-noise ratio of the language itself. Go is very expressive and hence it's also difficult to build a meaningful framework on top of it; the value provided is not nearly as much as you can do in other languages.

Reflection is necessary for some components to work (like JSON and so forth) but also sometimes abused to do type-related stuff that obscures a program's effect to the reader.

 

I just want to know who/what/where the authority of what great Go code is (aka idiomatic Go code) can be found.

 In strict terms the authority are the users of the language but you'll find sparse opinions in the Go community.

[adam]

Idiomatic is just another way of saying conventional. It is just a generally accepted way of doing things in the language. Kind of overused, like epic.

[Benjamin Measures]

On Wednesday, 15 October 2014 06:14:40 UTC+1, Brenden wrote:

I've heard a lot of strong opinions of some Go software projects based on how idiomatic they are, but from what I can tell these idioms are highly subjective.

I've been mulling over the question of what it means to be "idiomatic" for some time.

Recently, I've come to settle on a definition by contrast:

* Software "patterns" are accepted best-practice designs for solving common language problems (such as sub-classing and instantiation).

* Software "idioms" are beautiful designs that fall out of language characteristics.

Idiomatic Go is beautiful design as a consequence of a set of language characteristics peculiar to Go. Of course, beauty is in the eye of the beholder but there can be consensus.

Some of my favourite examples of idiomatic Go include:
* The concurrent prime sieve[1] as enabled by first-class channels and lightweight concurrency; and

* Functional options (for friendly APIs)[2] as enabled by higher-order functions and variadic parameters.

So whilst idioms are solutions as a consequence of language characteristics, patterns are solutions to problems themselves a consequence of language characteristics.

[1] Concurrent prime sieve: <https://golang.org/ref/spec#An_example_package>

[2] Functional options: <http://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis>

[egon]

On Thursday, 16 October 2014 19:45:05 UTC+3, adam wrote:

Idiomatic is just another way of saying conventional. It is just a generally accepted way of doing things in the language. Kind of overused, like epic.

We should all strive for idiomatically epic code.

+ egon

[Luke Scott]

Stick with patterns found in the core packages whenever possible. For example, use the http.Handler interface for web requests. If you stick with core interfaces your code is reusable/compatible with other packages.

What's wrong with reflect? Nothing. Go's reflect package is awesome. You can do so much with it. But you can do _too much_ with it. Therein lies the problem. What is too much? Bypassing the static typing system to the point where errors are not caught at build time. Encoding packages like encoding/json don't take it that far.

Dependency injection, as cool as it is, is taking it too far. I've learned this the hard way.

[akwillis]

trite on!