[Sir_Cmpwn]

They may not appear that way if you mesh well with the core ideas of Go. I once mentioned that Go does not fit into my usual project setup - I keep git repos in ~/sources. Go requires me to instead dedicate an entire directory structure to my entire Go workspace, which I have to keep seperate from the other sources. This could easily be avoided by letting me set enviornment variables that would relocate some of these folders (especially bin and pkg) to different places.

This is an example of how Go as a language is pretentious. It's way is the best way, even when no one else does it that way. The community becomes pretentious whenever you draw criticism against these core choices (note this mostly comes from #go-nuts, I haven't spent a lot of time on the mailing list). I like to believe that I can engage in well-reasoned discourse about these things, and I don't think I have seen the same degree of defensiveness and close-mindedness you might see from most other communities.

[MetaCosm]

It is opinionated (a more useful word than pretentious), and it is this way across many things. From style to directory structure to versioning of dependencies to generics. If you actually read the reasoning behind them, I think they are rather well defended by very smart people, but to each their own.

If you really have an issue with some of the very opinionated ideas that come to a large degree bundled with Go, that is fair. That is great even! It probably isn't a good fit for you. Which is fine, there are hundreds of other programming languages that work for you, most are the wild west.

For certain people (like myself) the sanity of Go is striking -- each decision is made for unremarkable and straightforward defensible reasons... a lot of them are community driven over personal preference... it is better for the herd (think: herd immunity) if everyone uses one style and everyone uses one layout... etc. It isn't about being "right" or "needed" by every person, it is about being consistent so you can move from project to project and focus on learning the code, not layout or style, just what the code does.

Go was designed from inside Google, with large teams in mind with many projects.

[coldtea]

>It is opinionated (a more useful word than pretentious), and it is this way across many things.

Well, opinionated doesn't mean much quality wise. Either you have the right opinions or the wrong ones. If you have the wrong opinions on something AND are opinionated about it, then you're stupid.

[Sir_Cmpwn]

You make some good points, and I agree with most of them. The thing that troubles me is that Go seems like an exellent language for the most part. I really like it. That being said, it's unfortunate that in order to use it, I feel like some basic choices that I've come to expect as a programmer are taken from me.

[MetaCosm]

Lots of things that are good for communities are restricting for individuals. Even more interesting, some of them lose significant value when anything less than a super-majority fall in line with them (This for example is why I think the Go community sometimes is very "passionate" about getting people on the right path, they are threatening the herd immunity of sane code and layout... one person goes off, others see their example and copy it... chaos!). I think the Go team was wise enough to see that the value of having sane baked in standards from day one FAR outweighed the complaints they knew would follow.

I think many people put too little value on communal norms, they have substantial value and are worth the adaption time. When in Windows C++ -- follow the conventions, when in Linux C -- again, follow the conventions -- and when in Go -- do that same. Fighting the dominant style for established platforms and languages is a mostly pointless, exhausting and sometimes debilitating task generally only done by those too inexperienced to realize how ridiculous it is. Team leads more experienced tend to just choose whatever is the dominate style / layout (preferably per-written up) for that platform/language realizing the benefits for getting ease of reading, consistency, hiring, firing, flexible labor (consultants) and most importantly not having absolutely worthless debates about style and layout.

[abofh]

For what its worth, go the language doesn't force that structure. Go the tool does most of that. Most languages (in their pubescent state) don't have self-referential build tools, and so tools get added by third parties (make, scons, etc).

This is not a bad thing -- but it does mean that when a language chooses to ship "opinionated" tools as the default supporting toolset, users gain from the 'convention over code' as rails would call it - you run go build and the tool does the math -- but accomplishing source-tree validation across arbitrary maintainers trees is less trivial than "package-path == path" -- so if you name your code "com.foo.baz.bar", you'll be hurt by its opinions.

That said - if you want to learn the toolchain, 6c/6g/6l (and its 5/8 counterparts) will act like the simplest gcc tools - so long as the benefit you gain from manual definition outweighs the cost, you still win without "go build".

[Sir_Cmpwn]

I like the idea of writing Go independently from the Go tool. Could you offer some brief insight into how dependency resolution might work, and link to some projects that break the mold?

[burntsushi]

Dependency resolution is done by the `go` tool automatically. If your project isn't compatible with the conventions established by the `go` tool, then it cannot infer your project's dependencies automatically.

I'm not aware of any projects that break the mold. Almost everyone that writes Go perceives the benefits of the `go` tool to be greater than the cons.

In another comment, I suggested using symlinks. I do it. Is there a reason why that doesn't work for you?

[abofh]

it's been a while, but something approximating:

-- HN has eaten my asterisks, sed {asterisk} appropriately.

(locate your {5,6,8}{c,l,g} per your go install, or use 'go tool' if you want to go half-way in, I'll use go tool '6' (amd64) for reference).

go tool 6g {asterisk}.go

if you're linking to a final binary:

go tool 6l -o outname {asterisk}.6

Then run ./outname

I'm eliding over linking and includes, but if you run 'go tool 6l -help', you'll find all your expected 'include' and 'link' directory type parameters.

...

All of that aside, I've found it rare that I actively link go code to languages outside of C, and even then, only rarely do I need to share the C subset outside of the 'go' repo. So I'd step back for a second before you go down this road and ask _why_ it must conform. I assume you have a reason -- and if you have a reason and want go as well, exploring the nitty-gritty of 'go tool' is going to be a must. I found it easier to conform with go in a different repository - that may not be an option for you.

[Sir_Cmpwn]

One of the biggest "why" answers is software distribution. I distribute my code in source form and users expect to ./configure && make && make install. I feel like there's far too much manual intervention in "the Go way" that I'd be asking my non-Go-savvy users to embark upon.

[burntsushi]

> Go requires me to instead dedicate an entire directory structure to my entire Go workspace, which I have to keep seperate from the other sources.

Symlinks solves this for me.

> This could easily be avoided by letting me set enviornment variables that would relocate some of these folders (especially bin and pkg) to different places.

AFAIK, `GOBIN` will allow you to relocate `bin`. I'm not aware of any such env var for `pkg`.

> This is an example of how Go as a language is pretentious.

It's not pretension. It's following a philosophy that prefers convention over configuration.[1]

[1] - http://golang.org/doc/articles/go_command.html#tmp_1