On using GORM: first experience

I rarely complain on others’ software, but this time I felt compelled to share my first impression on GORM, since it’s quite an example of how you pick software you need.

Since you usually don’t care much about the upsides but rather have blockers preventing you from using something at all, let’s get right to the negative side.

A first glimpse at the docs reveals you don’t (*DB).Close() after gorm.Open(). A more thorough examination results in finding out this is an expected change the author introduced in v1.20. Maybe the point to have the connection pool closed automatically on application exit even is valid, but expecting a Go dev to have to find that out and with a good chance still write something like:

defer func() {
    sqlDB, _ := db.DB()
    sqlDB.Close()
}()

still looks weird.

While this on itself doesn’t look like much of an issue, this is actually a sign of GORM not following semantic versioning, which is baked into the Go toolchain and is illustrated by its docs on version numbers. This means users of go get -u might have a difficult time having to patch their code after supposedly minor dependency updates.

I am still going to use this library, after all, it does what I wanted quite well; but hey, I have a right to complain! Right?..