5 ms·

> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual critic

> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual criticism. Typically Go is faulted for being too opinionated, and it’s projects too predictable. In fact, this is why I took to the language—no need to see past every maintainer’s personal flourishes just to build the code or run the tests. No ceremoniously nested directory structure. No figuring out how to point the build tool to the source files or how to convince the build tool to output or run a test target. Everything is right there, rather plainly and consistently across all projects. This does mean I have less room for creativity which is an okay tradeoff for me because I have just enough creativity to spend on the application and its architecture and the rest should just work, but I recognize that some may disagree and that’s okay too.

Felz 8y ago
This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.
- gcb0 8y ago
  in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
  - kerng 8y ago
    Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
- jonathanstrange 8y ago
  As if powerful abstractions lead to more consistency...
- weberc2 8y ago
  A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.
  - zeugmasyllepsis 8y ago
    > Pretty sure abstraction power drives _less_ consistency, not more. It depends, I think. Abstractions allow users to specify part of a program's behavior independently from others. This is not intended to start a flamewar or pick on Go, but for better or worse Go does not support user defined generic functions. One consequence is that certain kinds of methods are difficult to write in a generic, performant, and type-safe way. If users want performance and type safety, they need multiple implementations of those methods for each desired type. This leads to multiple copies of very similar code (which can evolve independently, lowering consistency) or the use of on of the community-driven code generators (which all have their own differences, again lowering consistency). Adding generics could largely make all of this inconsistency go away, but as you point out would enable a whole slew of other programming patterns more ways to make a mess. I prefer to think of abstraction techniques as shifting consistency. Ideally, they provide an obvious way to factor out one piece of a program's behavior, allowing developers to focus on the rest of the behavior independently.
    - weberc2 8y ago
      I largely agree, but I think people generally underestimate the abstractive power of (typesafe) Go and overestimate the cost of its abstractions. Generally Go's abstractions are based on dynamic dispatch (virtual function calls) which are quite cheap and are the basis for most other languages' abstractions. There are languages like Rust and C++ which offer zero-cost abstractions and generally beat Go in performance and abstraction power, but lose in other ways. If you're comparing Go to Java, C#, Haskell, OCaml, Python, JS, and Ruby, Go performs on par or better. As far as abstractive power, Go does quite well, although there is still some _boilerplate_ (for loops and closures); however, this is generally not where your bugs come from (certainly not your troublesome bugs) and boilerplate is consistent by definition. I think the biggest reason Go's lack of generics irks people is because they want _terse_ code, because terseness is the most obvious (but least useful) kind of DRYness. The next biggest reason is more legitimate--getting a lot of typesafe abstractive power out of Go requires a different bag of tricks (and a different way of thinking about abstraction) than languages with generics.
- the_clarence 8y ago
  You mean 50 layers of abstraction?
anonfunction 8y ago
If you frequent reddit/r/golang you'll see this question pops up quite frequently and the comments have many differing suggestions.
- andy_ppp 8y ago
  Great! What are they?
  - skolsuper 8y ago
    Comments are snippets of text, typically short, written by consumers of content in order to share their opinion of or reaction to that content with other consumers.
fouc 8y ago
When I hear "opinionated" I think of Ruby on Rails. Would be nice if Go had more opinions on structure and conventions perhaps.
- Someone 8y ago
  Frameworks provide structure; Ruby on Rails is a framework, Go is not.
  - fouc 8y ago
    Go is already halfway there ;)
- randomdata 8y ago
  Even Rails only manages to be opinionated for a small set of aspects about building CRUD web applications. If you can stay within those boundaries, it is useful. But as soon as your application needs to deviate from that, it seems that every project goes off and does its own thing again.
kodablah 8y ago
>> Not in the fundamental "this is how you should indent" bit but in the "this is how you should unpack dynamic json content" sense > Typically Go is faulted for being too opinionated, and it’s projects too predictable The parent addressed this. You are confusing inflexibility of language with inconsistency of ecosystem. Devs can want both more flexibility in the language, syntax, and type system and more commonly accepted project-level structures/approaches at the same time. I definitely don't see projects being too predictable at a general level as each lib has its own way of doing many things.
calgoo 8y ago
I agree, I love it even more for making small tools where i can just skip the whole folder structure and just have a .go file in a directory and compile it to a bin without all the fuzz of build tools, special folder structures etc. Of course for bigger, shared projects i know these tools help, but sometimes when you just want to make something small, or test something, i find these tools just get in my way.
- jjtheblunt 8y ago
  go build -o whatever.exe whatever.go works just fine.

Felz 8y ago

This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.

gcb0 8y ago
in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
- kerng 8y ago
  Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
jonathanstrange 8y ago
As if powerful abstractions lead to more consistency...
weberc2 8y ago
A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.
- zeugmasyllepsis 8y ago
  > Pretty sure abstraction power drives _less_ consistency, not more. It depends, I think. Abstractions allow users to specify part of a program's behavior independently from others. This is not intended to start a flamewar or pick on Go, but for better or worse Go does not support user defined generic functions. One consequence is that certain kinds of methods are difficult to write in a generic, performant, and type-safe way. If users want performance and type safety, they need multiple implementations of those methods for each desired type. This leads to multiple copies of very similar code (which can evolve independently, lowering consistency) or the use of on of the community-driven code generators (which all have their own differences, again lowering consistency). Adding generics could largely make all of this inconsistency go away, but as you point out would enable a whole slew of other programming patterns more ways to make a mess. I prefer to think of abstraction techniques as shifting consistency. Ideally, they provide an obvious way to factor out one piece of a program's behavior, allowing developers to focus on the rest of the behavior independently.
  - weberc2 8y ago
    I largely agree, but I think people generally underestimate the abstractive power of (typesafe) Go and overestimate the cost of its abstractions. Generally Go's abstractions are based on dynamic dispatch (virtual function calls) which are quite cheap and are the basis for most other languages' abstractions. There are languages like Rust and C++ which offer zero-cost abstractions and generally beat Go in performance and abstraction power, but lose in other ways. If you're comparing Go to Java, C#, Haskell, OCaml, Python, JS, and Ruby, Go performs on par or better. As far as abstractive power, Go does quite well, although there is still some _boilerplate_ (for loops and closures); however, this is generally not where your bugs come from (certainly not your troublesome bugs) and boilerplate is consistent by definition. I think the biggest reason Go's lack of generics irks people is because they want _terse_ code, because terseness is the most obvious (but least useful) kind of DRYness. The next biggest reason is more legitimate--getting a lot of typesafe abstractive power out of Go requires a different bag of tricks (and a different way of thinking about abstraction) than languages with generics.
the_clarence 8y ago
You mean 50 layers of abstraction?

anonfunction 8y ago

If you frequent reddit/r/golang you'll see this question pops up quite frequently and the comments have many differing suggestions.

andy_ppp 8y ago
Great! What are they?
- skolsuper 8y ago
  Comments are snippets of text, typically short, written by consumers of content in order to share their opinion of or reaction to that content with other consumers.

fouc 8y ago

When I hear "opinionated" I think of Ruby on Rails. Would be nice if Go had more opinions on structure and conventions perhaps.

Someone 8y ago
Frameworks provide structure; Ruby on Rails is a framework, Go is not.
- fouc 8y ago
  Go is already halfway there ;)
randomdata 8y ago
Even Rails only manages to be opinionated for a small set of aspects about building CRUD web applications. If you can stay within those boundaries, it is useful. But as soon as your application needs to deviate from that, it seems that every project goes off and does its own thing again.

kodablah 8y ago

>> Not in the fundamental "this is how you should indent" bit but in the "this is how you should unpack dynamic json content" sense > Typically Go is faulted for being too opinionated, and it’s projects too predictable The parent addressed this. You are confusing inflexibility of language with inconsistency of ecosystem. Devs can want both more flexibility in the language, syntax, and type system and more commonly accepted project-level structures/approaches at the same time. I definitely don't see projects being too predictable at a general level as each lib has its own way of doing many things.

calgoo 8y ago

I agree, I love it even more for making small tools where i can just skip the whole folder structure and just have a .go file in a directory and compile it to a bin without all the fuzz of build tools, special folder structures etc. Of course for bigger, shared projects i know these tools help, but sometimes when you just want to make something small, or test something, i find these tools just get in my way.

jjtheblunt 8y ago
go build -o whatever.exe whatever.go works just fine.