To be fair, in some cases[1] the code in Go has error handling and the code in Nim doesn't. In other cases the Go code does more things[2].

Nim is no doubt more expressive and concise than Go, but this comparison is seriously unfair in some situations. In addition, although Go is concise on the absolute scale I don't think it ever set out to be the most concise - it solves the problems that it set out to solve.

[1]: http://rosetta.alhur.es/compare/nimrod/go/#Read_entire_file [2]: http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_...

Not only that, on LOC is the goal; the Go code isn't written in most terse form, there are numerous unnecessary newlines and they do things like:

Examples:

    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

vs

    cmd.Stdout, cmd.Stderr = os.Stdout, os.Stderr

and:

    if open == 0 {
        fmt.Println("ok")
    } else {
        fmt.Println("not ok")
    }

vs.

    if open == 0 {
        fmt.Println("ok")
        return
    }
    fmt.Println("not ok")

Your first example is a great counter-point to the talk above about "if more stuff can fit on the screen it's easier to understand". I personally really prefer the 2-line construction.

As any language designed in the last decade.

Go is only eight years old.

Fair enough, but syntax-wise it looks like it was designed in the 80's or 90's. Some people see that as a good thing.

Many programmers don't like indentation blocks.

Can't tell why. I think it's awesome. Languages like Ruby suddenly seem like they got a bunch of strange ends dangling all over the place.