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

141–150 of 237 posts

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

#141

Post by bpicolo »

akerl_ wrote: post #36
briatx wrote: post #35

> Naming the Config parameter config is redundant. We know its a Config, it says so right there. > In this case consider conf or maybe c will do if the lifetime of the variable is short enough. This seems petty. Is it really that problematic to type out a few extra characters?

The issue w/ calling it "config" is that you end up with the confusing scenario where "config" is the object and "Config" is the type, differing only in casing.

This is a fairly go-specific issue due to its unexported vs exported convention. Many languages solve this through case conventions

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

#142

Post by amedvednikov »

axaxs wrote: post #105
amedvednikov wrote: post #30

Earlier quoted context omitted.

The main con is it's at a very early stage. It supports only traditional threads right now (but with automatic locking). Networking is supported. It uses curl/windows api. Cross compiling will be top notch, just like with Go.

Does this mean it doesn't support standard linux socket operations, or am I misreading it?

It does. I was describing the HTTP library. My bad.

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

#143

Post by ryl00 »

ybrs wrote: post #139
ilovecaching wrote: post #136

So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can c…

i'm riding that car for nearly a decade and never needed to pull to side. you can't ride a plane without airports, but you can travel to everywhere with a car - because roads are everywhere.

Driving across the Pacific anytime soon? :)

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

#144

Post by mrbrowning »

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…

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 choice of language in the context that I'm operating in whatever my reservations.

I'm confused about your assertion that the Java ecosystem has a similar problem, though, because my sense is both that it has a much less identifiable orthodoxy by virtue of being so widely used across so many domains, and that the new guard, such as it is, is very much in favor of creating libraries and utilities that favor simpler implementations and interfaces contra its "architecture astronaut" baggage.

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

#145

Post by bschwindHN »

ilovecaching wrote: post #136

So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can c…

I'm sorry but most analogies for programming languages just don't make any sense. This is why no one takes software "engineers" seriously.

What the hell does "power level 9000" even mean for a programming language?

Big, successful projects have all been written in Go, Rust, C++, Python, and many more languages. The key is that they've been chosen in cases when it makes sense to choose them. And it has nothing to do with childish "Rust is fast jet. Python is slow car." analogies.

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

#146

Post by arvinsim »

zbobet2012 wrote: post #106
pcwalton wrote: post #48

Earlier quoted context omitted.

Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete. Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.

I generally find if you need multi letter variable names it means your function or scope is to long, or manipulating to many things. It's a nice little red flag for me. Up to four or five single letter variables is pretty trivial to remember. Especially when three of those are i, j, and k. More than 6 or 7 rapidly becomes painful. But if you are manipulating 6 or 7 variables _in the same scope_ you are doing to much.…

I disagree. I am pretty sure that there's some code that is short and simple but you want to have descriptive names anyway like financial related computations.

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

#147

Post by mirceal »

ilovecaching wrote: post #136

So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can c…

if you want to fly anything other than a small plain you’re doing it wrong. think about it! we could get a new pilot and have them fly this in no time. it’s simple and can do this 2 tricks really well. everything is fluff and not for professional pilots. and google flies a couple of them so how could it be wrong?

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

#148

Post by shaan7 »

hackinthebochs wrote: post #97
dilap wrote: post #62

Earlier quoted context omitted.

I feel like I have the opposite problem. If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols. So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.

Totally agree. If you have to scroll up to be reminded what some variable means, a longer name is good. But if its usage is a few lines away from its declaration then there's no reason to add visual noise to your code.

Its easier said than done though. We started following this few years back but then while it was "few lines away" originally, code evolved and now there are parts where its 20+ lines away. This means that short var names need to be continuously "enlarged". Well, then why not start with a "medium" name and avoid all that headache? ctx is a good enough compromise between c and context. (c can be client, config, context, certificate ... you get the point).

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

#149

Post by bnolsen »

apoorvgarg wrote: post #88
pcwalton wrote: post #48

Earlier quoted context omitted.

Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete. Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.

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.

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

#150

Post by bdamm »

ori_b wrote: post #132
pcwalton wrote: post #48

Earlier quoted context omitted.

Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete. Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.

Readability is a problem -- long variable names are harder to skim, and rapidly begin to blur together for me.

Agreed. Step through the code in a debugger if you really want to understand what it's doing. Even unreproducible problems with production code can succumb to raw understanding gained from stepped test cases.
Post reply on HN