It's better to do it _right_ than to do it _right now_

cbrake · October 15, 2021, 4:29pm

This discussion, started by Rob Pike, is an interesting read:

github.com/golang/go

go: don't change the libraries in 1.18

opened 07:51AM - 12 Oct 21 UTC

closed 10:12PM - 27 Oct 21 UTC

robpike

NeedsDecision FrozenDueToAge generics

The 1.18 release of the Go language is likely to include by far the biggest chan…ge to the language since its creation: parametric polymorphism, colloquially called generics. There has been much discussion about how the core libraries will adapt, and how to make that adaptation. See #45955 and #48594 for example, and there are others already and sure to be more soon. How to use these ideas in the standard library requires great thought and planning. Putting them in the library now also adds a significant burden to rolling out the release. I propose that we do **not** update the libraries in 1.18. The reason is simple and compelling: It's too much to do all at once, and we might get it wrong. The language changes have been worked on in some form for over a decade, but the library changes are very new, and we have no experience with the use of the new types in Go on which to base a strong case for their design. Yes, we can reason about them at length and much has been done. Experience with other languages helps, but one thing Go has taught us is that it grows its own ways of doing things. For generics, we don't know what those new ways are yet. Also, the compatibility promise makes the cost of getting any detail wrong quite high. We should wait, watch, and learn. Instead, I propose we still design, build, test, and use new libraries for slices, maps, channels, and so on, but start by putting them in the golang/x/exp repository. That way, these new libraries - which are truly experimental at this stage - can be tested in production, but can be changed, adapted, and grown for a cycle or two, letting the whole community try them out, if they are interested and willing to accept a little instability, without requiring every detail of every component to be ready from day one. Once they have soaked a bit, and updated through experience, we move them into the main repo as we have done with other externally-grown packages, but with the confidence that they work well in practice and are deserving of our compatibility promise. I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now. Use, learn, study, and move cautiously.

I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now. Use, learn, study, and move cautiously.

Dijkstra reminds us (in an essay aptly called The Humble Programmer):

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility.

In other words, however smart and capable one or two individual Go programmers might be, they can’t necessarily anticipate what kind of programs a million Gophers will want to write, or how they’ll write them. Even the beautiful, pragmatic designs of the standard library are occasionally found to be wanting in some minor respect. I think Dijkstra would have approved of Go, because a kind of humility is built into it. We all need reminding of the value of humility once in a while (he said, humbly referencing his own blog post).

This approach reminds of some thoughts from Evan Czaplicki, the author of Elm.

https://twitter.com/evancz/status/928359033844539393

Be kind.

Learn from everyone.

Collaboration requires communication.

Not every problem should be solved with code.

Communication is contribution.

Understand the problem.

Explore all possible solutions.

Pick one.

Simplicity is not just for beginners.

It’s better to do it right than to do it right now.

It’s not done until the docs are great.

Take responsibility for user experiences.

Make impossible states impossible.

There are worse things than being explicit…

These values are why I use Go and Elm in the Simple IoT project – at least for now

bminer · October 20, 2021, 6:41pm

I completely agree with Rob here. Go’s compatibility promise is a strong one, so it doesn’t make sense to rush things in the standard library. Good stuff. I’m really excited for 1.18!

cbrake · October 20, 2021, 7:12pm

Yes, Go’s stdlib has been a joy to use!

I’ve thought about this a bit more – perhaps this is not a universal rule – on the other side of the coin, you have the MVP philosophy that focuses on getting stuff out, learning, and iterating. So perhaps its important to use the right approach at the right time (kind of like the right tool for the job …) – changes that are in core libraries, data structures, or APIs that are far reaching need to be designed and changed carefully. Features in an unreleased product is where the MVP approach is more appropriate and should be perhaps be implemented early and released often. In released projects, a more conservative approach may be needed as whatever you release, you might have to live with forever. Open source languages, like Go and Elm, are at the far end of the spectrum where changes are far reaching and features need to be considered very carefully.

This “right” theme is what defines successful architects/technologists:

right technology at the right time
right approach and methodology for the team/project phase
right tools for the job

One size does not fit all!