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