Just wondering, does Go finally has a package manager with proper versioning of modules?<p><i>Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?</i>
Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue?<p>Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co.<p>It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged.<p>The de-facto idiom of PHP before 2010 was messy code.<p>It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose, copy of the Java circa 2006 style (large class hierarchies, singletons, "Facades", DI, etc).<p>Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before.<p>In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.<p>Within a single project, sure, enforce some idiomatic way of doing things.<p>But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code.<p>It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.
> Phase 4 (the expert): You understand the design choices and motivations behind the language. You grok the philosophy of simplicity and composability.<p>In what way is Go code composable?
What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -- the `make` replacement.<p>If you want to fix the most broken parts of Go -- its ecosystem management tooling -- just replace your `go` command.<p>I have, and I love working on a project with a proper top-level src folder, with vendor-able packages discoverable in a top-level lib folder pinned to known-good commits.<p>There are literally dozens of go replacements, but the winning combination for me is using Goop [1], Makefiles, and symlinks to subvert `go get` and the naive way it parses import declarations [2].<p>[1] <a href="https://github.com/nitrous-io/goop" rel="nofollow">https://github.com/nitrous-io/goop</a><p>[2] <a href="https://golang.org/ref/spec#Import_declarations" rel="nofollow">https://golang.org/ref/spec#Import_declarations</a>
> <i>Don’t wait until you become an expert in the language to make your voice heard.</i><p>You can do anything!<p><a href="https://www.youtube.com/watch?v=gSjLiQxEZlM" rel="nofollow">https://www.youtube.com/watch?v=gSjLiQxEZlM</a>
"If you think the Go standard library is not powerful enough to do what you want to do, you might be wrong."<p>or not...<p>The standard libraries are not perfect. They do have very useful building blocks, but they are far from complete or perfect.<p>Take the http library, for example. There's no built-in context:<p>type HandlerFunc func(ResponseWriter, <i>Request)<p>type Handler interface {
ServeHTTP(ResponseWriter, </i>Request)
}<p>This resulted in a complete mess when it comes to http middleware because everybody is solving the context problem their own way (including google itself).