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.

Iterative Design

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:

Instead of:


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.

Reading/Listening Bias

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.”

I wrote about it in another article, “Tail Call Optimization”.

I offered input that, amongst others’ input, resulted in a Go 2 proposal “add become statement to support tail calls”.

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:

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?

Parting Words

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:

Some of My Other Medium Articles: