Hacker News Reader

Comment by whizzkid | Hacker News Reader

Golang's not being an opinionated software is the main reason I was not able to passionately start learning this software. Most of the engineers have a bit of a picture in their mind when it comes to implement a specific function. But when the question comes "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want". This prevents me learning the power of language from the beginning.

Being opinionated is about onboarding people with the best experience from the experts of the language, then let people overwrite or choose their own way of doing things when they know what they are doing.

View on HN

> Golang's not being an opinionated software [...] "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want".

I'm really not sure. Idiomatic Go is something well covered. Gofmt is ensuring consistent formatting. The official docs have an entry dedicated to this: https://golang.org/doc/effective_go.html.

And what would be an opinionated language if Golang is not?

Rust comes to mind. Almost all projects fetch dependencies and build the same way (cargo), with very similar looking project structures and entry point. The community has rallied around a set of libraries that's used by everyone.

I couldn't care less about formatting differences between repos. Ignoring superficial formatting difference, Ruby's community also has one package manager (bundler) and build tool (rake) with a widely followed naming convention and directory structure and community consensus set of libraries.

Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README.

Go feels like the wild wild west. Everyone has their own directory structure, with different ways of fetching dependencies (modules vs dep), building (seems to have consolidated around go build vs make), with everything hand rolled or whatever NIH selection criteria they used for their libraries.

> ways of fetching dependencies (modules vs dep)

Yes, an 'official' package manager have clearly not been a target for the core team for a (way too) long time, whereas Rust has envisioned that 'community' part from the beginning.

> I couldn't care less about formatting differences between repos.

Whereas, to me, an official, no-question-asked tool like 'gofmt' is godsend. It really depends on what you're building and in which context.

> , building (seems to have consolidated around go build vs make)

Not sure here, 'go build' is clearly the idiomatic building way from almost day one.

> Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README.

That was rather not (enough?) straightforward under %GOPATH% era, indeed. Today, with Go modules, its a one liner 'git pull; go build', granted you have Go 1.11 available in %PATH% and that the codebase already have a go.mod file (if not, a 'go mod init <pkgname>' should fix it).

Thanks for the reply. Maybe it has changed over the time but what i have meant was mostly about the way an application is built with golang.

Let me give you an example, it might be easier for me to explain it this way.

Writing a web application that responds to a post request. I am guessing I can use net/http library to achieve that. But does it implement CSRF prevention automatically, or should I be already informed about including it as a developer?

I would be grateful for letting me understand this part. I am not against the language, but just curious.

> Writing a web application that responds to a post request. I am guessing I can use net/http library to achieve that. But does it implement CSRF prevention automatically, or should I be already informed about including it as a developer?

I think I get where you may come from. Indeed, Golang (the language and its standard lib) is not a framework-language toolkit ala RoR. The standard lib is providing building blocks with really straightforwards and clear documentation (check https://golang.org/pkg/net/http/#pkg-overview).

> or should I be already informed about including it as a developer?

I guess you really should, whatever language/framework you're currently using.

> what i have meant was mostly about the way an application is built with golang.

Yes, clearly the confusion may be here, I took it as "the language is not opinionated", whereas you were in fact saying that the language and its standard library are not a universal web application toolkit/framework.

Having learned to code in a time and age where being opinionated wasn't a thing, opinionated languages feel like golden cages.

Reply on news.ycombinator.com