I had the privilege of attending GopherCon 2023 last week with many of my coworkers at Smarty (thanks!). I came away with a few thoughts I'd like to share.
Idiomatic?
Kaylyn Gibilterra gave a talk entitled "Idiomatic Go Tells a Story". I really appreciated her take on how method definitions/signatures can and should read almost like prose:
func (this Thing) OperatesOn(the OtherThing) (andReturns YetAnotherThing) { ... }
I really didn't appreciate (but wasn't surprised by) her reinforcing the Code Review Comments document with its insistence on using the first letter of a type's name as the receiver name for its methods. I've already written about why I don't do this (here and here) so I won't belabor my point except to reiterate that naming conventions can and should be determined by software teams (and I would follow guidance from those who lead software projects I work on), not programming language designers or a community at large.
GOOOP?
Dylan Bourque gave a talk entitled "Clean Up Your GOOOP: How to Break OOP Muscle Memory" (materials). I knew I wanted to attend this talk but I was pretty sure I wasn't going to like it. I was sort of wrong. I agreed with some of what he said, disagreed with a few things, but then found myself wondering which side he was taking for the rest of the time. Perhaps this is due to the title of his talk attributing a negative connotation to the application of object-oriented thinking in Go ('GOOOP' == 'Go + OOP'), but then he proceeded to undermine the premise of his talk by:
- Explaining Uncle Bob's "Clean Architecture", which I supposed could be implemented without object-oriented programming, but it would be very difficult;
- Teaching Uncle Bob's SOLID principles, which had their genesis in object-oriented thinking. Here's how I apply these principles in Go code.
The application of both of the above are highly desirable in a software system, so I find it odd that the premise of his talk was to deride object-oriented thinking, which they both require.
While we're on a role sharing principles espoused by Uncle Bob, we might as well summarize his "Three Paradigms" blog post:
In the last 40 years computer hardware technology has increased the computing power of our machines by well over twenty orders of magnitude...
But in that same 40 years software concepts haven't changed that much.
But three things have changed about the code...We could call these things "paradigms". And they were all "discovered" in a single decade more than 40 years ago.
1968 – Structured Programming...replacing [gotostatements] with structures such as if/then/else and while loops.
1966 - Object Oriented Programming...with the advent of polymorphism, the need for pointers to functions was eliminated; and indeed deprecated.
1957 - Functional Programming...all functional programs are dominated by one huge constraint: They don't use assignment.
With that introduction, here's a fundamental milestone:
Three paradigms. Three constraints. Structured Programming imposes discipline on direct transfer of control. Object Oriented Programming imposes discipline on indirect transfer of control. Functional programming imposes discipline upon assignment. Each of these paradigms took something away. None of them added any new capability. Each increased discipline and decreased capability.
Here's the grand conclusion: The judicious application of appropriate programming paradigms is desirable no matter what language we use to write code. We are very likely to find usage of all three paradigms in large software systems and this is a good thing. No one should feel ashamed of applying object-oriented principles in a software project--we have bigger fish to fry, like just getting the code under unit test (which is usually much easier with object-oriented design..).
import "encoding/json/v2" // ?
Joe Tsai delivered an absolute masterclass of a talk entitled "The Future of JSON in Go". He and his team really paid the price to understand the needs, challenges, and objectives of the community and have delivered a VERY solid foundation on which to propose a new standard-library JSON package without alienating the Go community at large. I like the new API (which leverages functional options) and allows for maintaining legacy behavior as well as allowing developers to fine-tune the behavior over time as they migrate toward the proposed v2 behavior. It's brilliant work!