3 ms·

> 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

by bpizzi 8y ago

> 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 https://golang.org/doc/effective_go.html. And what would be an opinionated language if Golang is not?

kenhwang 8y ago
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.
- bpizzi 8y ago
  > 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).
whizzkid 8y ago
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.
- bpizzi 8y ago
  > 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 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.

by bpizzi 8y ago

kenhwang 8y ago

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.

bpizzi 8y ago
> 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).

whizzkid 8y ago

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.

bpizzi 8y ago
> 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 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.