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

171–180 of 237 posts

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

#171

Post by pjmlp »

int_19h wrote: post #155
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…

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.

To the point that if someone would take the hard work to try fork and implement the features some consider missing, they would be burned on the fire instead of praised for their work, which is why anyone with the skills of doing it just goes elsewhere instead.

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

#172

Post by pjmlp »

weberc2 wrote: post #29
jstewartmobile wrote: post #19

Earlier quoted context omitted.

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

Disagree hard on Go vs Python. Python is my day job, but documentation is rough . You're likely not going to get documentation for all the types, and if you do it's usually in one giant page and you can't tell which class's `__str__()` docstring you're looking at. Often you'll have a method with some terse description for parameters that don't completely describe the types accepted for a parameter. Most of this stuff…

I started using Python with version 1.6, and never used for anything more than scripting tasks, so my experience is mostly related to the official docs.

The manuals provided with Python are great when compared with quite a few alternatives, some of them require to go buy a book to properly learn them.

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

#173

Post by dnautics »

pcwalton wrote: post #48
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?

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 stopped using "i" when I had it in a context where it could be easily confused for "imaginary constant".

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

#174

Post by 12298765 »

bpicolo wrote: post #140
zbobet2012 wrote: post #122

Earlier quoted context omitted.

If you have to go "cross-reference" elsewhere you are modifying something "to far away" from you. That's a giant sign of spaghetti code. Also names vary with there contextual scope. Larger scopes mean longer names generally. Russ Cox gives a succinct description here: https://research.swtch.com/names A name's length should not exceed its information content. For a local variable, the name i conveys as much informatio…

> For a local variable, the name i conveys as much information as index or idx and is quicker to read This is only true because i is a specific, common abbreviation for index. When writing arbitrary glue code, a single letter variable would be a meaningless abbreviation without shared context. If you encounter "i" and it doesn't mean "index of a for loop", you're going to be taking additional time parsing meaning.

An example where I disagree, and use 1-letter names daily: arrow functions in both Java and JS.

`usersList.stream().forEach(u -> someSet.add(u))`

It's immediately obvious that u is a user in usersList. I realize that it's debatable if u is really more readable than spelling out user, but I prefer it, and I don't think anyone is going to be confused by it. If the chain does get really long, also, I will spell it out explicitly.

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

#175

Post by coder543 »

Groxx wrote: post #168

https://dave.cheney.net/practical-go/presentations/qcon-chin... > 8.3. Never start a goroutine without [knowing] when it will stop. 100% agreed with the concept, but even the final example is flawed. That'll unblock and continue immediately after `close(stop)`, without being able to do two important things: it can't tell you when it's done shutting down, and it can't tell you if it encountered an error. Fixing this m…

> 100% agreed with the concept, but even the final example is flawed. That'll unblock and continue immediately after `close(stop)`, without being able to do two important things: it can't tell you when it's done shutting down, and it can't tell you if it encountered an error. Fixing this makes it even more complex.

The final example actually does both of these things already, but maybe you're confusing the purposes of some of the channels?

The loop at the end of main will wait until it receives one (possibly nil) error value from every task that was launched. Upon receiving the first error, it will close the done channel, which will then cause any remaining tasks to run their Shutdown function, which will attempt to gracefully shutdown the server. The error of each shutdown function is then returned and printed if non-nil.

There is no immediate termination, and all errors are communicated. It doesn't let the process die until every task has sent its error value.

Obviously, there are two semantics not enforced at compile time: each task must send exactly one error value, and each task is responsible for its own shutdown. If a task sends more than one error, there will be early termination. If a task doesn't shut itself down properly, that is its own fault.

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

#176

Post by wishinghand »

bschwindHN wrote: post #145
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 w…

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

Power level 9000 is a reference to Dragon Ball Z. I haven't watched it but I gather it's up there on the power scale.

I think the analogy makes sense. Sometimes it is better to take a car than a Cessna or a jet, so it doesn't necessarily fail as you think it does.

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

#177

Post by freyir »

entity345 wrote: post #50
argd678 wrote: post #46

> 2.1. Choose identifiers for clarity, not brevity This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you’re not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn’t read the code.

Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

If you’ve seen any amount of Go and Java code (starting with, say, the standard libraries), you’d know these communities take very different approaches to variable names.

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

#178

Post by entity345 »

freyir wrote: post #177
entity345 wrote: post #50

Earlier quoted context omitted.

Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

If you’ve seen any amount of Go and Java code (starting with, say, the standard libraries), you’d know these communities take very different approaches to variable names.

The point is that you do not choose the way to name variables based on a sheepish "it's the way the community does it". You're responsible for your own code, and your organisation's code. It has nothing to do with the language.

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

#179

Post by entity345 »

croshan wrote: post #116
entity345 wrote: post #61

Earlier quoted context omitted.

I'm sure there are many actual professionals using Go. Not just script kiddies. I happen to be learning Go coming from a C background. I find "The Go Programming Language" by Donovan and Kernighan exemplary and the decades of experience that went into the language really show.

No need for insinuations, that's not a point of contention. If you look past the book, and directly at the STL, you'll find a common example: the "fmt" library, shortened to save three letters. Or compare the verbosity of these two examples from language docs, and the length and descriptiveness of variable names in them: https://docs.oracle.com/javase/tutorial/essential/io/cl.html to https://golang.org/pkg/bufio/#exa…

Naming conventions are part of your own practices and processes.

There is no issue with having short names to describe well-known entities part of the language, or trivial code.

Your example from pkg.bufio is trivial and but still the variables names are meaningful. There is a difference between clearly and meaningful, and verbose.

Your example from Java is not very different.

I feel that the point is not being understood here.

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

#180

Post by bschwindHN »

wishinghand wrote: post #176
bschwindHN wrote: post #145

Earlier quoted context omitted.

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 w…

> What the hell does "power level 9000" even mean for a programming language? Power level 9000 is a reference to Dragon Ball Z. I haven't watched it but I gather it's up there on the power scale. I think the analogy makes sense. Sometimes it is better to take a car than a Cessna or a jet, so it doesn't necessarily fail as you think it does.

The analogy might "make sense" but it's not useful. All it does is drive discussion towards arguments framed in the context of the analogy. Except we're not talking about public transportation! We're talking about programs! Points about "roads are everywhere" and "Are you driving across the Pacific?" are just snark.

As an example, let's take this quote:

> 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 carry a lot less people, but at least you aren't driving a car like the people using Python.

If Go was the name of a Cessna, C++ the name of a commercial airliner, and Python the name of a car, then that statement might make _some_ sense. But no, they're programming languages and you can't just throw this analogy out there and then try to have a serious discussion based on it.

Sometimes a Go program performs faster than a C++ or Rust program, and is written in less time. For certain domains, you might get something working (and performing faster) in less time in Python than writing it in Go. Python (and others) can call out to C libraries. Oh, I don't recall your car being able to summon a commercial airliner to pick it up in the middle of highway traffic. But that's how you'd have to explain FFI in this make-believe world of programming language cars.

Post reply on HN