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

211–220 of 237 posts

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

#211

Post by ilovecaching »

platz wrote: post #138
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…

But Go will never be a data science language like python, because Go is too limited to express that domain. Python may leave you in the lurch when it comes to maintainability, but for some domains python is infinitely better than Go.

I agree with you, but data science is a separate field, so I don't normally factor it into my discussions of tools for software engineering.

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

#212

Post by platz »

ilovecaching wrote: post #211
platz wrote: post #138

Earlier quoted context omitted.

But Go will never be a data science language like python, because Go is too limited to express that domain. Python may leave you in the lurch when it comes to maintainability, but for some domains python is infinitely better than Go.

I agree with you, but data science is a separate field, so I don't normally factor it into my discussions of tools for software engineering.

tell that to the NumPy folks!

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

#213

Post by kazagistar »

ragona wrote: post #42
networkimprov wrote: post #38

Earlier quoted context omitted.

And this is worse advice: > Functions should do one thing only. ... In addition to be easier to comprehend, smaller functions are easier to test in isolation, and now you’ve isolated the orthogonal code into its own function, its name may be all the documentation required. Using single-caller functions as a substitute for comments makes the workings of a specific operation much harder to follow, as you have to jump a…

> A long function is easier to understand than an exploded one. This is a pretty controversial position, and quite situational in my opinion. I absolutely agree that having to hop all over the source to understand something is frustrating, but that doesn't mean that very long functions are the right solution. Some combination of reasonably named helper methods and a function flow that makes the logic easy to parse sh…

An excellent balance is to try to make a function only do one level of abstraction at a time. It's a bit of a flexible guideline, but basically you shouldn't call `isUserActive`, do some complex arithemtic, read extract data from a complex data structure, and call a templating engine in one function, since those a results all different levels.

As long as what are doing is approximately the same type of thing, it is fine to do a lot of things without breaking readability.

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

#214

Post by kazagistar »

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

Make private functions that are only visible to the current module. Then write your unit tests directly in that same module, next to the functions, so they can access them even when the rest of the world cannot. Of course, this requires sensible language support.

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

#215

Post by atombender »

yiyus wrote: post #196
atombender wrote: post #133

Earlier quoted context omitted.

I often find myself wishing Go either allowed import cycles between packages, or allowed namespaces within a package. Because they can become unwieldy. For example, a common convention is to avoid redundancy. Let's say you have a package "builder". Your encouraged to have "builder.New()" as a constructor, not "builder.NewBuilder()". Fine. Now let's say you need two types of builders: One for building "schemas", one f…

Could you work around this somehow using a combination of internal packages and type aliases in public packages?

Not sure. But sounds messy -- type aliases aren't really intended for that.

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

#216

Post by geodel »

xyzzy_plugh wrote: post #152
mrbrowning wrote: post #144

Earlier quoted context omitted.

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

To add to your point last week I cleaned up a part of project in Java sprawling in 30 or so files with 5 KLOC to 2 Java files and under 1 KLOC of Java code. Now main clean up was using library properly which was already present as dependency for years and removing innumerable level of indirections.

This code was written in really roundabout way in Java tradition where e.g. setName() would call getName() -> initName() -> initClassName() -> getDefaultClassName() -> initDefaultClassName() just to set one damn string value. And believe me this getName() function would get called grand total of one time in whole project.

And it was possible for me to do so because learning and writing Go made me confident that straightforward code is not a sign of junior/inexperienced developer. Because in Java it will be exactly that if you do not bury the actual logic in ten levels of abstract crap.

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

#217

Post by int_19h »

amedvednikov wrote: post #204
int_19h wrote: post #157

Earlier quoted context omitted.

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?

Yes, just like in Swift.

Then I don't get it - how do you make the or-block exit normally and yield a value, instead of exiting the outer scope one way or another?

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

#218

Post by geodel »

pjmlp wrote: post #171
int_19h wrote: post #155

Earlier quoted context omitted.

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.

Do you think really Java or any other professional language would accept some language feature which was developed prior to explicit approval from committers?

If someone thinks since they have developed feature and put lot of hardwork in it so language maintainers have to merge it. I am sure they would have no option but to invent their own language.

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

#219

Post by leshow »

I've always found Go's 'guiding principles' to be highly subjective, the annoying thing about it is that they are masqueraded as objectivity. Simplicity and readability for whom?

If you've been writing C and Java for years, all simple/readable means is 'familiar'. There are other definitions of simplicity

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

#220

Post by pjmlp »

geodel wrote: post #218
pjmlp wrote: post #171

Earlier quoted context omitted.

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.

Do you think really Java or any other professional language would accept some language feature which was developed prior to explicit approval from committers? If someone thinks since they have developed feature and put lot of hardwork in it so language maintainers have to merge it. I am sure they would have no option but to invent their own language.

Yes, that is how a large majority of contributions work.

Language improvement proposals aren't taken in just with words on paper.

Post reply on HN