If you considered them it's even worse - by keeping the language simple you've made it more unintuitive and less readable for the programmer. IMHO the primary beneficiaries of Go are the compiler writers, not the programmers having to read and write source code.

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.

If that's what you were trying to demonstrate then you were pretty far off the mark. The two programs are far from equivalent, and your Go code is just bizarre.

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?

The Go code is bizarre? That's the introductory Go tutorial showing off Types in Go (http://golang.org/doc/go_tutorial.html) Not a single line of the Go code is mine (I just copy and pasted the entire tutorial in a single file). If you want to blame someone for making Go look bad - blame the author of the tutorial - or better yet the inventors of the Go Language.

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

Just to play devil's advocate, here's what that example would look like with exceptions and something like `using()` in C# (here, any curly block can implicitly be treated like a try block, like in Ruby):

    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)
        }
    }