"Error codes are a poor substitutions for Exceptions" This is debatable.

"Have to code around lack of generics" Some people complain about this, but in practice their absence hasn't been a big problem. It's still an open issue, though.

"Defer less desirable and intuitive than C# using" Again, debatable.

"array bracket notation prefixing the variable" http://blog.golang.org/2010/07/gos-declaration-syntax.html

"No proper classes?" This is a bizarre complaint. Go doesn't have classes. It has types and methods. Why would you need classes? What is a "proper" class?

The tone of your complaints implies that we didn't consider any of these things, or that these decisions were made through sheer incompetence. This couldn't be further from the truth. Language design is just as much about what you exclude as what you include. One of Go's major strengths is its simplicity. It's a very small language; so small, you can read the spec in one sitting! http://golang.org/doc/go_spec.html

As has been pointed out already, your comparison between Go and CoffeeScript is not illustrative of much. Go is typed, CoffeeScript is not. The "cat" comparison is very strange. Your (very unidiomatic, and in some places plain wrong) Go program re-implements everything from a syscall level, while the CoffeeScript example uses library calls. Why?

Here's how one might write a similar "cat" in Go:

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) os.Error {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        defer f.Close()
        if _, err = io.Copy(os.Stdout, f); err != nil {
            return err
        }
        return nil
    }

    func main() {
        for _, arg := range os.Args[1:] {
            if err := cat(arg); err != nil {
                log.Print(err)
            }   
        }
    }

Your example is not the same, this is just a C-style single method. The whole point of my example was using Go's own sample source code to showcase the hacks needed around structs to get around the deficiencies in not having classes. The resulting struct method signatures are ugly, verbose and unintuitive - it's not nearly as readable and wrist friendly as grouping them in a single class definition.

In following this pattern the defer keyword is a magic method that doesn't visually demonstrate its behaviour - compare that with C#'s using statement which does.

I think this statement of yours is quite revealing: "Your example is not the same, this is just a C-style single method." It's not a "single method," it's a function. Not everything is or should be about object orientism. It's not always the right choice, and people who obsess over making everything an object (those who think functions are a special type of method) are doomed to overcomplicate their design. (For example, there is no reason you should need to construct new objects to write cat.)

I'm confused as to why someone who clearly doesn't know Go would try so hard to discredit it. What's your motivation?

If you think OOP is not important for building and encapsulating large software code bases, then we operate in different worlds and Go wasn't designed for my purposes in mind. Feel free to keep using Go as a better C and I'll stick to mainstream languages without these deficiencies (aka trade offs).

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) {
        using (f := os.Open(name)) {
            io.Copy(os.Stdout, f)
        }
    }

    func main() {
        for _, arg := range os.Args[1:] {
            cat(arg);
        } catch (err os.Error) {
            log.Print(err)
        }
    }

It's very hard to compare statically-typed system languages with dynamically-typed HLLs. And it's utterly misleading to judge one by the standards of the other.

That said, what Go achieves with its syntax is remarkable, imho.

Consider this: How do you add another function (e.g. "close()") to your file class in CoffeeScript? By extending the existing class into a "MyFile" class? But then you have to make sure all your "File" instances are actually instances of "MyFile", so you can call your newly defined function on them.

In Go you just define the new function.

    File::close = ->

So, to revise my point: with "proper" classes (i.e. Java or C++) this wouldn't be possible, or at least more complicated and not the way to do things. Classes are not the ultimate solution and it's a good thing that Go tries a different approach to OOP.

    #!/bin/sh
    cat file.txt

    perl -e 'while (<>) { print; }' file.txt

  perl -p file.txt