Practical Go: Real-world advice for writing maintainable Go programs
1–10 of 237 posts
Re: Practical Go: Real-world advice for writing maintainable Go programs
#2[deleted]
Re: Practical Go: Real-world advice for writing maintainable Go programs
#3Great article, as always, by Dave Cheney.
I took a lot of his advice when designing V [1].
It's very similar to Go, but it has
- No global state
- Only one declaration style (a := 0)
- No null
- No undefined values
- No err != nil checks (replaced by option types)
- Immutability by default
- Much stricter vfmt
- No runtime
- Cheaper interfaces without dynamic dispatch
[1] http://vlang.io
Re: Practical Go: Real-world advice for writing maintainable Go programs
#4Would love to see better separation on the page between "Bad" and "Good" examples. While a good read, it's difficult to quickly distinguish between the two.
For example: https://github.com/airbnb/javascript
Re: Practical Go: Real-world advice for writing maintainable Go programs
#5Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements.
Take following functions, for example:
// Auth check if user credential is existed in bla, bla...
// ... (many more explanation)
Auth(user User, authProvider AuthProvider) bool
// AuthDefault check user against the default **AuthProvider**
AuthDefault(user User) bool {
return Auth(user, new(DefaultAuthProvider))
}
Re: Practical Go: Real-world advice for writing maintainable Go programs
#6Great article, as always, by Dave Cheney. I took a lot of his advice when designing V [1]. It's very similar to Go, but it has - No global state - Only one declaration style (a := 0) - No null - No undefined values - No err != nil checks (replaced by option types) - Immutability by default - Much stricter vfmt - No runtime - Cheaper interfaces without dynamic dispatch [1] http://vlang.io
Just wanted to say...as both a language nerd and opinionated snob, I'm really excited by what I see with V thus far. I'll be following your progress for sure and wish you the best.
Re: Practical Go: Real-world advice for writing maintainable Go programs
#7Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements. Take following functions, for example: // Auth check if user credential is existed in bla, bla... /…
I’d argue there’s a failure of the code to some extent to need such extsenibility with documentation. I’ve often found when I need more info outside of Godocs that simply clicking through and diving into the source provided me with all the answers I needed to know.
Re: Practical Go: Real-world advice for writing maintainable Go programs
#8Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements. Take following functions, for example: // Auth check if user credential is existed in bla, bla... /…
The authors have chosen to make it as limited as they have on purpose, as I understand it.
I disagree with them, but here we are.
I've been slightly tempted at times to make something with markdown but never gotten enthusiastic enough to put the time. Plus, markdown is technically a bit too powerful, so I'd want to cut it back down, and before you know it I'm inflicting the 3,124th custom markdown on the world. Really I just would like bold, italic, monospace, identifier linking as you say, and numbered and bulleted lists not in the unformatted text wrapper.
Re: Practical Go: Real-world advice for writing maintainable Go programs
#9Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements. Take following functions, for example: // Auth check if user credential is existed in bla, bla... /…
You should put the docs for AuthProvider on AuthProvider, not on Auth or AuthDefault.
Re: Practical Go: Real-world advice for writing maintainable Go programs
#10[deleted]