Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dave.cheney.net

Post reply on HN
Print view View original

151–160 of 237 posts

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

#151

Post by tigershark »

Scramblejams wrote: post #66
networkimprov wrote: post #47

Earlier quoted context omitted.

I took issue with this because it's a conventional wisdom, and does a fair bit of damage. Single-caller functions attract other callers over time, gain backwards-incompatible features, and result in regressions.

This is one reason I like nested functions. They’re not available to the surrounding scope so they don’t succumb to these weaknesses, while also allowing you to organize your very long function internally by task. I use ‘em in Python all the time. It’s a bummer that more languages don’t support them, though you can get there with lambdas too, sometimes at the cost of more syntax.

C# has inner named functions.

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

#152

Post by xyzzy_plugh »

mrbrowning wrote: post #144
xyzzy_plugh wrote: post #69

Earlier quoted context omitted.

I couldn't disagree more. I think it comes down to personal preferences, mostly. I get so much more done in Go, have fewer maintenance issues, and more frequently collaborate with other folks/contribute to other projects. > I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered. I could -- and do -- say the same about the Java ecosy…

For what it's worth, I don't particularly have a cross to bear with respect to Java. I cited it just because its invocations as a Bad Language bogeyman are common in the Go-focused writings I've found, and those are far out of proportion to its inherent flaws (of which I believe there are many!). I completely agree that it's a matter of preference, which I think is supported by the fact that I found Go to be the best…

You make a fair point; I'm not adequately exposed to the Java ecosystem, I mostly end up reading Apache projects.

I guess my remarks could be rearranged as: In general, I find Java, and the JVM friend Scala, to worship Abstraction over simplicity. Complexity is constantly confused for convenience, and that makes me sad. The number of files I need to read to understand _any_ piece of Go, I could likely count on one hand, if even. For the JVM-based approach: dozens, if not more.

Abstractions _in theory_ are great: they reduce the cognitive burden, they simplify behavior, make it easier to rationalize and cast judgement; But in practice, that just isn't true. You _always_ need to peel away the abstraction.

In Go, countless times, I've found myself reading the standard library implementation. Is this good? No, of course not. Ideally, as a consumer, I never need to look under the curtain. Things should just work. But that tends to never be true, and looking under the curtain is an important aspect of computing (c. 1970-1999) that permeates everything we do.

Go makes it really easy to look under the hood, see what's happening, and more-or-less instantly achieve clarity. The only other languages I've ever used that came close were C and C++, and history has demonstrated how well that's worked out.

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

#153

Post by int_19h »

SaltyBackendGuy wrote: post #109
networkimprov wrote: post #70

Earlier quoted context omitted.

Go has closure functions; great feature. One of the (few) things I like about Javascript is the ability to define a closure anywhere in the containing function, so it appears in the order of operations: function f() { setTimeout(fDing, 2000); g(); function fDing() { ... } }

Now write a unit test for function fDing() { ... } Honestly with modern JS I am not sure this feature is that great. Looks more like a code smell these days imo. Edit: Formatting

You write unit tests for units of code. A function with nested functions inside of it is a single unit of code; that's essentially what those functions being nested, and hence not directly invokable from the outside, indicates.

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

#154

Post by int_19h »

Someone wrote: post #129
Roboprog wrote: post #117

Earlier quoted context omitted.

A bit of our “heritage” in programming destroyed by the C family of programming languages Pascal, like Algol, had nested subroutines for decomposing longer operations without leaking the details. Nested functions is one of the things I like about JavaScript as well.

C has static functions for decomposinglo ger operations without leaking the details. For better or for worse, taking advantage of that forces you to keep source files fairly short and cohesive in functionality.

You are still leaking the details of the function that is the sole caller of those other functions. It's not leaking across translation unit boundary, but it's not the only one that matters.

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

#155

Post by int_19h »

xyzzy_plugh wrote: post #69
mrbrowning wrote: post #54

Earlier quoted context omitted.

This attitude, which I'll paraphrase as "needing any feature that I personally consider unnecessary is a code smell," is endemic to the Go community and a big reason why I still find myself frustrated by it on a daily basis even after a month of using it for a greenfield project. I don't like the language itself, since I'm generally in favor of a language offering more affordances rather than fewer, but it's fine to…

I couldn't disagree more. I think it comes down to personal preferences, mostly. I get so much more done in Go, have fewer maintenance issues, and more frequently collaborate with other folks/contribute to other projects. > I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered. I could -- and do -- say the same about the Java ecosy…

GP isn't saying that Go is not productive, but that the community has an irrationally hostile attitude towards anything that is not possible, or easy, in the language.

And I agree - it has become the prime example of "you're holding it wrong" school of programming language design and apologetics.

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

#156

Post by int_19h »

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

This is interesting. Go proclaims itself as a modern spiritual successor to C, but I think what you've done is much closer to that goal.

BTW, if you're going for immutability by default, perhaps swap := and =? Reason being, if variables are immutable by default, assignments should be far less common, so the language should discourage them with more verbose syntax over initialization of immutables.

Besides, C originally used = instead of Algol's := for assignments for the exact opposite reason - because assignments were more common in C code than comparisons - this would be a nice opportunity to fix that mistake.

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

#157

Post by int_19h »

amedvednikov wrote: post #17
SaulOfTheJungle wrote: post #15

Earlier quoted context omitted.

> - No err != nil checks (replaced by option types) Where can I find code illustrating V Option types?

https://github.com/vlang-io/V/blob/master/examples/users.v They are very simple and combine Rust's Option and Result .

What's the difference between "break" and "continue" inside an or-block? Or do they apply to the outer enclosing loop if there is one?

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

#158

Post by happythought »

networkimprov wrote: post #101
jjuel wrote: post #100

Earlier quoted context omitted.

Longer functions are much more prone to causing errors, and errors that are harder to find. It is honestly much better to have functions that do one thing and one thing only. Might not always be possible, but it is always the best way to code.

It seems that belief is unfounded. See the link posted by @xtian.

I think “doing one thing” and “getting called one time” are getting confused.

GetData()

FormatData()

UploadData()

Those could do one thing but could be called at several points within a larger program, which i think you are fine with. Or they could only be called once in which case i think you are saying it might make sense to just inline them.

If I understand you correctly, then I agree.

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

#159

Post by apoorvgarg »

bnolsen wrote: post #149
apoorvgarg wrote: post #88

Earlier quoted context omitted.

Regarding single-letter variables, mathematical functions might be an exception. I think writing func gcd(a, b int) int {...} is better than other alternatives. There is simply no need to assign any more meaning to the arguments other than their type.

no, it's not. bigger deal is that single letter vars make it much harder to search for variable usage in files using arbitrary editors.

What would be the signature of your gcd function ?

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

#160

Post by base698 »

apoorvgarg wrote: post #159
bnolsen wrote: post #149

Earlier quoted context omitted.

no, it's not. bigger deal is that single letter vars make it much harder to search for variable usage in files using arbitrary editors.

What would be the signature of your gcd function ?

Numerator, denominator?
Post reply on HN