Stages of learning Go, with code examples

I can't say for sure, but I'm guessing it probably came from years of experience working on the sorts of projects that Go was designed to address. Go is really geared toward large distributed projects with a lot of contributors. In that context, it makes sense to value some sort of conformity. It may not always result in the most efficient code, but it makes the code much more maintainable and accessible to newcomers. Once you're familiar with idioms you don't need to spend so much time figuring out what a new piece of code is trying to accomplish.

You seem to argue that since old PHP and javascript code had terrible coding practices, therefore Go shouldn't try to enforce any particular type of practice. I don't see that your conclusion follows from that premise. Now if you're arguing that good coding practices arise from the community, that's well and good. Idioms can change and I expect that idiomatic Go code in 2020 will be different from idiomatic Go code today. That doesn't mean there isn't value to writing idiomatic Go code today.

I haven't actually seen any cargo cultists explicitly say that no one should be writing in other programming languages for any project. That would be a pretty stupid sentiment, although I shouldn't be too surprised if some people felt that way. Go's strength is really on server side code where storage is cheap and network and I/O latency is a bigger issue than CPU or memory utilization. If you're developing for that kind of environment, there's a lot to be said for using Go. And while you're at it, you'll save yourself and anyone else who's working with your code a lot of hassle if you follow best practices and write idiomatic code most of the time. If you're in a specific situation where you can get better performance or whatever by deviating from the standards, then go for it, but leave some comments explaining your choices to anyone else who has to maintain your code.

If I'm going to write a one-off script to process a million lines of text, I'm probably going to write it in Perl, not Go (and yeah I know it's 2015). My Perl code will follow TMTOWTDI whatever-the-heck-works practices. If I'm already writing Go for something, and others might want to peek at my code, then I will make an effort to make my code idiomatic.

That sounds like deb(dpgk)/rpm's job. In golang-land I just need to use vendoring+godeps for repeatable builds.

I direct your attention to sort: https://code.google.com/p/go/source/browse/src/sort/sort.go#... This defines sort on []int and []float64. If you want to sort a []int32, you have to manually define Int32Slice and copy paste lines 232-237. Copy paste the same lines again for any other slice of built-ins you wish to sort, e.g. uint32, uint64, int64, float32, etc.

They removed the entire set of vector containers now, but for the canonical way to implement IntVector, see https://code.google.com/p/go/source/browse/src/pkg/container... -- and compare that to stringvector.go in the same directory. It's almost entirely copy/paste with string substitution to replace int with string.

    Type structure is a syntactic discipline for
    enforcing levels of abstraction.

I don't have a bulletproof argument here, but essentially I'd like to say that greater modularity allows you to forget inessential details and subsequently increase the surface area with which you can compose your modules.

So finally, we come to generics as a powerful tool for using types to erase inessential details. Generics essentially operate via providing a new logical structure to types, the ability to introduce and operate sensibly over type variables. So I would argue that a type language without generics is much like a programming language without variables [1]. You are perhaps not completely crippled, but pretty close.

So, my argument is something like "without generics your type language is crippled so as to make control of modularity very weak which will prevent you (syntactically) from ensuring composability".

The "(syntactically)" bit is important since, as we all know, you can achieve modularity and composability "by hand" through code generation, copy and pasting, creating commenting policies... but then we've stumbled back into the "static types versus dynamic types" argument, so let's not rehash it.

[0] https://wiki.mpi-sws.org/star/paramore?action=AttachFile&do=...

[1] These kind of variables, not "mutable cell" style variables: https://existentialtype.wordpress.com/2012/02/01/words-matte...