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

Post by fastbmk » Fri, Feb 22, 2019, 11:40 AM UTC

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.

Post by undreren » Fri, Feb 22, 2019, 12:02 PM UTC

dana321 wrote: post #94

My advice would be this: If you have a specific reusable component.. Make a package to contain it. Use init() to compile any regular expressions and store them as variables within that package, so that you don't Split out related code in a folder, remembering that the included code is done in alphabetical order - so shared functions within the same package you should alphabetically make it the first to be included. Y…

    err := unsafe1()
    if err == nil {
        err = unsafe2()
        if err == nil {
            err = unsafe3()
            if err == nil {
                err = unsafe4()
                    if err == nil {
                    err = unsafe5()
                    if err == nil {
                        // ...
                    }
                }
            }
        }
    }

Post by amedvednikov » Fri, Feb 22, 2019, 12:16 PM UTC

int_19h wrote: post #156

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

Post by ivanhoe » Fri, Feb 22, 2019, 1:51 PM UTC

mntmoss wrote: post #119

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.

Dense code that benefits from dense variables(which describes a lot of "pure algorithms" work) I often approach by aliasing the variables to shorter ones. It's all in the same body so the context is not especially hard to lose.

Post by bpicolo » Fri, Feb 22, 2019, 2:49 PM UTC

12298765 wrote: post #174

bpicolo wrote: post #140

Earlier quoted context omitted.

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