Where to Go Next ~ Operators

What next for this not-so-young programming language

Go version 1.0 arrived in late 2009. It’s now a well established language and ecosystem, having carved out a significant niche in server integration and bespoke webserver code, amongst others.

Unashamedly a quirky language, Go’s developers pioneered an opinionated approach to minimalism that has evidently served it well.

This post is one of several looking to the future; it focusses on operators in Go.

This is the second post in this series. See range

Quirky

Quirky? Definitely. For example, if you program Go already, you will already know the three uses for the builtin make function (for slices, maps and channels) and that the new function is hardly ever needed.

You just have to know the special case rules. Go with it!

Many other languages have prioritised consistency and orthogonality in their concepts in order to make them easier to learn. Go doesn’t, and it doesn’t feel any need to apologise. Remarkably, this has worked well because the reasons are very well thought out.

We can see this in the complex64 and `complex128 types.

Complex simplicity

Complex numbers are needed for mathematics. The name complex is a bit misleading - they’re just like ordinary continuous numbers except they come in pairs. This happens to be a really useful way of describing oscillating things - how big an oscillation is and where it’s got to needs two numbers to describe, not just one. And it also happens rather conveniently that this pair of numbers, called a complex number, is also useful in loads of other parts of mathematics.

So the complex64 type contains two float32 values. Likewise the complex128 type contains two float64 values (see manipulating complex numbers).

Complex numbers are created using the built-in function complex. For example

tau := 2 * math.Pi // tau is float64
c128 := complex(5, -tau)

The value c128 is a pair of float64 values: the first value, called the real part, is 5; the second value, called the imaginary part, is -2π (or just τ as we like to say these days, where τ is 2π).

Alongside the complex built-in, there are two more: real and imag and they break apart the two parts of a complex number. So

tau := 2 * math.Pi // tau is float64
c128 := complex(5, -tau)
r := real(c128) // 5.0
i := imag(c128) // -tau

Outcome

So … big question … would extending range like this open up the unwanted risks of badly-behaving loops? Unpexpected performance gotchas?

Or could the extra flexibility allow Go programs to deal really smartly with user-defined collections?

 
comments powered by Disqus