Hacker News Reader

Comment by weberc2 | Hacker News Reader

> 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.

View on HN

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.

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.

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".

As if powerful abstractions lead to more consistency...

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.

> 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.

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.

> never use monads

I think "powerful abstractions" fall into other categories, e.g. ORMs. While gORM kinda-sorta works in the context of golang limitations, it's missing a lot of stuff that doesn't currently fit into the go model.

Can you elaborate? I can't think of anything in Go that would preclude ORMs. I'm not familiar with gORM, however.

You mean 50 layers of abstraction?

>> 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.

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.

go build -o whatever.exe whatever.go works just fine.

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

Frameworks provide structure; Ruby on Rails is a framework, Go is not.

Go is already halfway there ;)

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.

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

Great! What are they?

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.

Reply on news.ycombinator.com