
Spectro: Adventures in Go - WestCoastJustin
http://markcrossfield.co.uk/2015-08-22-spectro-adventures-in-go.html
======
millstone
> For example, I particularly liked that since map iteration order is not
> guaranteed, it is actively randomised at runtime to make that clear

What is there to like about this feature?

1\. It introduces unavoidable noise into performance testing

2\. It makes your functions impure

3\. Your simple script will have different output across successive runs, even
with the same input

4\. It removes a reasonable and useful feature that all other languages
support, namely, that you can iterate the same map twice in a row in the same
order

5\. Working around this usually involves sorting, which in turn requires a lot
of boilerplate: [https://gobyexample.com/sorting-by-
functions](https://gobyexample.com/sorting-by-functions)

It seems all this does is make life harder. I'd be interested to hear from
anyone who thinks this feature has helped them.

~~~
dilap
I like it.

If you're not going to have guaranteed order, then explicitly breaking it to
avoid accidental dependency that will break your programs later when the
language implementation changes is very much a good thing.

Compare this to python, which has deterministic dictionary order, but it
changes across implementations. That's just begging for problems.

I think the whole philosophy of Go is kind of "try to avoid shit breaking in
weird and unexpected a mysterious ways", an approach I become more sympathetic
to the longer I program.

~~~
pcwalton
Is there any advantage to randomizing on every iteration over just randomizing
a single seed at process startup?

Generating one seed at startup would solve the problem of accidental de facto
stabilization of dictionary iteration order while avoiding the issues
mentioned in the parent comment.

~~~
dilap
That does seem more reasonable, actually, unless there's some crazy reason you
might actually want to vary the order w/in a single process lifetime I'm
overlooking...

------
pbnjay
There's an odd, big complaint about numeric casts that culminates in this line
of code:

    
    
        fmt.Fprintf(os.Stderr, "%"+strconv.FormatInt(int64(paddingWidth), 10)+"s %s\r", "", legend)
    

Which could be improved greatly, and made a lot more readable with:

    
    
        fmt.Fprint(os.Stderr, strings.Repeat(" ", paddingWidth), legend+"\r")
    

In my experience with Go over the last few years, any time I have this "ugh"
moments it pays to take a step back. It's usually a code smell that there's a
better way.

~~~
cespare
You can do better -- fmt provides a way to give a dynamic width or precision
as an int argument.

    
    
      fmt.Fprintf(os.Stderr, "%*s %s\r", paddingWidth, "", legend)
    

I'd further wonder whether a separate padding calculation is needed at all
(too lazy to go read the source on Github at the moment).

~~~
pbnjay
I started with that, but there's no reason to use the formatting specifiers
when the padding string is already blank. With the dynamic width Fprintf still
needs to waste time parsing the format string.

