There was a discussion on SOLID principles in the Go programming language and I threw in my two-cents. Once I was done writing, I was surprised with what I came up with.
Here is why you shouldn't think very much about SOLID in Go:
Consider each principle:
"A class should only have a single responsibility..."
Go doesn't have classes. Already the principle doesn't apply...
I write that tongue in cheek, because of course a struct is a bit like a class, and of course SRP is great for a Go struct type, but also, since Go struct types do not have inheritance, we don't get ~classes~types inheriting behaviors. Thus we don't have to worry about un-intended inherited responsibilities. It is easier to achieve SRP in Go.
"Software entities ... should be open for extension, but closed for modification."
No inheritance, thus no extension. Go gets this for free.
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Go doesn't have subtypes. YAY. So this only applies to interfaces implementations. Yes, it is an absolute must for interface implementations.
"Many client-specific interfaces are better than one general-purpose interface."
This is such idiomatic Go that it should go without saying.
One should "depend upon abstractions, not concretions"
This is another way of saying accept interfaces. Yes, we value this highly in Go.
We think about things slightly differently in Go, because Go isn't OOP, but once translated to Go's type system, SOLID absolutely matches with Go idioms.