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? 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 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.
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)
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π).
complex built-in, there are two more:
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
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