Griping about Go

The whimsical nature of interfaces is definitely different coming from other languages. An `io.Flusher` might be nice, but it's not really necessary. You can just write:

    type Interface interface {
        io.Writer
        Flush() error
    }

    func someFunction(w Interface) error {
        w.Write(nil)
        w.Flush()
        panic("etc...")
    }

Or even drop the type name:

    func someFunction(w interface {
        io.Writer
        Flush() error
    }) error {
        w.Write(nil)
        w.Flush()
        panic("etc...")
    }

But maybe that looks too weird.

What's worse, defer's function-scoped nature means that the only way to compile it is to dynamically push closures onto a stack at runtime and then pop them off one-by-one before returning. The compiler may be able to optimize this in specific cases, but in the general case the semantics are extremely dynamic for no real benefit. Designing defer in this way is an especially strange decision for a language that in many ways is architected to make life easy for the compiler writer.

   goos: linux
   goarch: amd64
   BenchmarkPut-8             50000             27502 ns/op
   BenchmarkPutDefer-8        30000             46774 ns/op
   BenchmarkGet-8             50000             29812 ns/op
   BenchmarkGetDefer-8        20000             89701 ns/op
   PASS

   fmt.Println("foo")

    r1, err := fn1()
    r2, err = fn2()
    if err != nil {
      return err
    }

The article is on a suspect domain:

  https://https.www.google.com.tedunangst.com/flak/post/griping-about-go

Is there any legit reason to have https.www.google.com in there?

Automatic closeout remains a hard problem. "Defer" has the same problem as RAII - what if the closeout fails? Python's "with" clause, and how it interacts with exceptions, is one of the few constructs that can handle multiple closeout faults correctly.

Trying to get rid of exceptions seems to force workarounds that are worse than exceptions. C++ and Java exceptions were botched and gave the concept a bad name. Go's "panic" and "recover" are an exception system, but not a good one. Python comes closer to getting it right.

Key concepts for successful exceptions:

- A predefined exception hierarchy. Catch something in the tree, and you get everything below it. Python added this in the 2.x era, and it made exceptions usable. (Then they messed it up in the 3.x era, putting too much stuff under "OSerror".) This solves the problem of "Have I caught everything"?

- The case where a closeout event raises an exception has to work. This is hard. Attempts to get it right resulted in such horrors as "re-animation" in Microsoft Managed C++. It needs something like the Rust borrow checker model to make sure that object lifetimes are properly enforced on all error paths.

I think go has some serious other problems.

Like the billion dollar mistake. Why is this repeated in any new language? It is just plain awful and stupid. This is easily my biggest gripe with the language (apart from missing generics).

Go combines that greatly with the bonkers error handling:

  if err != nil {...}

Half of all go code ever written consists of the line above.

Now combine that with defer (or go routines) returning errors...

Here's one of my favorite gotchas in Go: why does this error?

https://play.golang.org/p/6LTbtuocu5-

I heard it's better now but when I was trying to do grpc I couldn't get this to build:

https://github.com/improbable-eng/grpc-web/tree/master/go/gr...

Basically there was dependency that changed, and it caused it to not build. The maintainer was just pointing fingers at google. I had no idea what to do, but it just scared the crap out of me.

Blog seems to have collapsed under HN weight (link is bad too).

Archive of archive of page: https://app.pagedash.com/p/d5c8c4bf-d88a-470b-a7f3-adb986ccb...

Is there a reason that go's defer is only function-scoped?

> as opposed to passing large byte slices or strings around. In theory, this should be more efficient

Why would passing a "large" slice be inefficient?? Maybe on x86 due to a lack of registers, but on 64-bit?

> Usually this can be resolved by creating a new function and calling that from the loop. But frequently not. [etc.]

For me this is the appeal of the language; I really prefer things confined and manually scoped rather than having things globally scoped which would cause a lot of debate just around that. You often have to think about what you want to expose and where, but that's a good thing in my opinion.

    for _, f := range fs {
      func() {
        defer f.Close()
      }()
    }

> I mostly like go, but after working with it a bit more I realize there are a few jibs of which the cut I do not like.

What is this supposed to parse to?

Defer also encourages the unsafe behavior of not checking error results. You can't propagate errors from it. About the best you can do is wrap whatever function you were deferring in another function, and then panic if there is an error.

    func Pants() (rerr error) {
        defer func() {
            if err := doStuff(); err != nil && rerr == nil {
                rerr = err
            }
        }()
        // ...
        return nil
    }

    func DeferClose(err *error, closer io.Closer) {
        cerr := closer.Close()
        if *err == nil && cerr != nil {
            *err = cerr
        }
    }

    func Pants() (rerr error) {
        f, _ := os.Open(...)
        defer errtools.DeferClose(&rerr, f)
        // ...
        return nil
    }

what kind of domain is this ?

https://https.www.google.com.tedunangst.com/flak/post/gripin...

#notasuspectURL

I avoid using defer