Go: Is it safe to use gob package to save data to file for later use?

Question

I'm currently saving a struct to file so it can be loaded and later used by implementing gob, as follows:

func (t *Object) Load(filename string) error {

    fi, err := os.Open(filename)
    if err !=nil {
        return err
    }
    defer fi.Close()

    fz, err := gzip.NewReader(fi)
    if err !=nil {
        return err
    }
    defer fz.Close()

    decoder := gob.NewDecoder(fz)
    err = decoder.Decode(&t)
    if err !=nil {
        return err
    }

    return nil
}

func (t *Object) Save(filename string) error {

    fi, err := os.Create(filename)
    if err !=nil {
        return err
    }
    defer fi.Close()

    fz := gzip.NewWriter(fi)
    defer fz.Close()

    encoder := gob.NewEncoder(fz)
    err = encoder.Encode(t)
    if err !=nil {
        return err
    }

    return nil
}

My concern is that Go might be updated in a way that changes the way that gobs of data are encoding and decoded. If this happens then the version of my app compiled with the new version of Go would not be able to load files saved from the previous version. This would be a major issue but I'm not sure if its a realistic concern or not.

So does anyone know if I can consider it safe to save and load gob encoding data like this and expect it to still work when Go is updated?

If not, what would be the best alternative? Would my function still work if I changed gob.NewDecoder and gob.NewEncoder to xml.NewDecoder and xml.NewEncoder? (Does the XML encoder encode and decode structs in the same way as gob, i.e. without me having to tell it what they look like?)

Answer 1

The documentation for the type GobEncoder does mention:

Note: Since gobs can be stored permanently, It is good design to guarantee the encoding used by a GobEncoder is stable as the software evolves.
For instance, it might make sense for GobEncode to include a version number in the encoding.

But that applies to custom encoder.

For the one provided with go, the compatibility is guarantee at source level: Backwards-incompatible changes will not be made to any Go 1 point release.

That should mean gob should continue to work as it does now.

A different and robust solution exists with projects like "ugorji/go/codec":

High Performance and Feature-Rich Idiomatic Go Library providing encode/decode support for different serialization formats.

Supported Serialization formats are:

• msgpack: https://github.com/msgpack/msgpack
• binc: http://github.com/ugorji/binc

But unless you need those specific formats, gob should be enough.