Practical Go: Real-world advice for writing maintainable Go programs

Post by TeddyDD » Thu, Feb 21, 2019, 7:00 PM UTC

amedvednikov wrote: post #3

Great 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

Post by amedvednikov » Thu, Feb 21, 2019, 7:05 PM UTC

wuschel wrote: post #20

amedvednikov wrote: post #3

Great 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

Exciting! How long was this language in development? In what language was the compiler originally written in?

Post by amedvednikov » Thu, Feb 21, 2019, 7:06 PM UTC

TeddyDD wrote: post #21

amedvednikov wrote: post #3

Great 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

I never heard about this language and it looks impressive on the paper. Keep up great job! I'm waiting for open source release to give it a try.

Post by michaelcampbell » Thu, Feb 21, 2019, 7:06 PM UTC

TheJazi13 wrote: post #7

letientai299 wrote: post #5

Came 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.

Post by weberc2 » Thu, Feb 21, 2019, 7:09 PM UTC

jstewartmobile wrote: post #19

letientai299 wrote: post #5

Came 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 guess it's hard to get around to the advanced features when so few people even bother to take advantage of the basic ones. Documentation for most Go libraries I've come across has been pathetic compared to similar things in Python or PHP. edit: Compare to something like Racket: https://docs.racket-lang.org/plot/intro.html?q=graph#%28part...