A Part of All Good Engineering
This is a story about what I learned from Rob Pike’s Go 2 Draft Specification presentation.
Engineering is about thinking about the problem space and prototyping to learn more.
If you try to to implement an idea you might learn what’s good or bad about it in order to inform subsequent design decisions.
We don’t know if it will work until we play with it.
We can’t play with it without trying it.
We can’t try it without implementing it.
And we’re back at the beginning again.
But now we know more about what does and does not work.
And we continue iterating until we arrive at the optimal solution design.
Improved Error Handling
Here’s the example of what we might see in Go 2:
The Biggest Question
Can we simplify the ideas in the Go 2 Proposals down to something that fits well inside Go as we love it without making the language feel like a totally different language or is any particular idea, in fact, too complicated to implement?
When we implement language constructs like handle or contract, we’re trying to cover a space of problems we know about.
Go doesn’t try to solve all of the worlds problems, but what it tries to do is to solve an important subset well. — Rob Pike
For example, if we want to do everything we can possibly do with parametric polymorphism or everything we can do with error handling, we’ll over complicate Go.
Nobody wants Go to get complicated, but that doesn’t mean that Go can’t have more stuff; but rather, that stuff needs to feel like it belongs.
Do you ever read an article with a particular thought or question you’d like answered in mind?
When watching Rob’s presentation, the thing I was looking for was coverage of my most wanted language feature: Support for Tail Call Optimization.
Tail Call Optimization
A tail call is where the last statement of a function is a function call.
Support for TCO provides the performance gain required for using various functional programming techniques.
I wrote about it in my book, “Learning Functional Programming in Go.”
Purchase book here. My publisher just shared the following with me about a week after it was released: The book ... has…lexsheehan.blogspot.com
I wrote about it in another article, “Tail Call Optimization”.
A tail call is where the last statement of a function is a function call. Here’s a tail call example in Go:medium.com
I offered input that, amongst others’ input, resulted in a Go 2 proposal “add become statement to support tail calls”.
The current Go language does not support tail calls, because they affect runtime.Callers and stack backtraces and the…github.com
I learned that there is a lot of thought involved in adding one statement to a language.
I responded to questions from others that would like to see TCO support in Go:
Hello l3x, I'm currently reading your book. How do I know whether I have the draft or the latest version? The first…github.com
Here’s the Catch
Let’s say TCO were implemented and available in Go 1.12, that would mean that the Go Dev Team is committing to this trial that nobody has played with long enough to make a long term decision about its implications.
A Possible Solution
Perhaps, a trial implementation of the Go compiler could be made available that supports TCO?
Maybe that way, people can play with various functional programming techniques using Go. We could do things that are currently infeasible given existing recursive call performance issues in order to explore what could be possible with TCO in Go.
Fundamental Engineering Question
Language designers must know where to draw the line. They must answer the following question:
How much complexity will be introduced by adding a new feature compared to how to how much problem space coverage will be gained?
Stuff Needs to Feel Like It Belongs
Another aspect of adding a new language feature, e.g., TCO, is whether it belongs in Go.
Some may argue that since the creators of Go come from a Unix background and since Go bears a close resemblance to C and the imperative programming paradigm, that functional programming and support for TCO is out of place in Go.
Some may argue that the functional programming paradigm is too complicated and therefore does not belong in Go. (People tend to think Monads are complicated and difficult to understand.)
Complicated or Simply Beautiful?
Given an Apache web server access log with entries like this:
Let’s consider what the commands we run in the Unix shell…
… have in common with the workings of functional programming:
That sequence of shell commands is a Monad using Map and Reduce (for details, get a copy of my book ;-)
Were the designers of Unix aware of functional programming?
Just because we don’t see a thing does not mean it’s not there.
Unix was designed on the principle of doing one thing well, e.g., individual commands like (cat, echo, awk, sort) and composition (piping the output of one command to the input of another). How is that different from functional programming?
Adding TCO to Go is not a simple as I had once imagined, but I also think that adding TCO would open up the door of productivity for Go programmers that Unix administrators (and programmers like me) enjoy daily.
Go is an amazing language. Thanks to the Go Dev Team for all their hard work..
… and thank you for considering TCO in Go 2.
Other Things of Possible Interest
My Blockchain Boot Camp Offering:
Intro course to the theory and mechanics behind cryptocurrencies for professional software engineers. We'll study the…cryptocurrencies.developersclass.com
Some of My Other Medium Articles:
Sounds like a scam, right? (Read on and judge for yourself.)medium.com
This is a story about my adventures with the Lightning Network, Banks, the Financial crisis of 2007–2008, Bitcoin and…blog.goodaudience.com