E2E: Erik Meijer and Robert Griesemer - Going Go

Sign in to queue

The Discussion

  • User profile image
    felix9

    Very interesting ! Go Go Go

  • User profile image
    Zura

    Thanks for the interesting talk!

    I have a question. Instead of using defer:

    f, _ := os.Open("somefile")
    defer f.Close()

    Why not just have special method, like C++'s destructor, which is fired automatically at the end of scope? You can still handle the plain memory in the GC, but the destructor will handle other resources. What is the principal difference between calling Close() in the destructor vs defer-ing Close()?

    Thanks,
    Zura

  • User profile image
    mvrak

    Zura: In Go, the file handle could have been passed a long a channel to somewhere else. Keeping the call of the "destructor" in a defer statement also increases clarity.

    There are many compromises between clarity, garbage collection, and general feature sets. Go is heavily biased towards clarity.

  • User profile image
    mvrak

    Note that SetFinalizer exists, which is essentially a destructor triggered by the Garbage Collector. http://golang.org/pkg/runtime/#SetFinalizer

  • User profile image
    Brecht

    Note that SetFinalizer is not guaranteed to run.

  • User profile image
    Zura

    @mvrak:
    The finalizer is called by GC, i.e. it is nondeterministic, it might not be called until the end of program.
    The defer-ed function is called at the end of the function.

Add Your 2 Cents