Hacker News Reader

Comment by fred256 | Hacker News Reader

    var buttons = []string{"red", "blue", "green", "yellow", "purple"}

    > go run level_9.go

    Sending Code Sequence...
    1 : red
    2 : blue
    3 : green
    4 : yellow
    5 : purple

    Sorry, that's not correct

Not sure what the correct sequence is, if not that?

View on HN

The story is a little misleading -- the correct sequence is not in fact "sitting right there in the code."

I "cheated" on some questions by causing the correct output to be printed without actually doing what the instructions recommend, but in this case, the path of the least resistance is probably to follow the instructions, including leveraging what the lightbulb hint recommends.

Additional Hint 1: Tbebhgvarf nera'g arprffnevyl rkrphgrq va gur beqre gung gurl'er fgnegrq

Additional Hint 2: Qb nf gur vafgehpgvbaf naq uvag fhttrfg naq svk gur enpr pbaqvgvba ol hfvat n zhgrk gb rafher gung bayl bar tbebhgvar ng n gvzr fyrrcf naq gura nccraqf gb gur neenl

Additional Hint 3: Lbh pna eranzr gur frgOhggba zrgubq naq znxr lbhe bja ercynprzrag gung pnyyf gur byq bar

If you want to "cheat": hfr lbhe oebjfre pbafbyr gb frr gur .tb svyrf gung ner ybnqrq juvpu pbagnva gur fgbel, pbqr, naq pbeerpg bhgchg.

Decode hints with https://rot13.com/

Thanks for the help! Though I would have phrased the first hint as "Gur qrfverq beqre vf gur beqre va juvpu gur tbebhgvarf ner rkrphgrq"

Another hint, a reddit discussion of a golang phenomenon this puzzle depends on: https://bit.ly/2rqqWkh

It's a bit annoying that it's depending on such an incidental behavior.

My initial solution for this was to sleep 20*x milliseconds in setButton. Because the later random sleep is up to 10 milliseconds this ensures that the operations are always done in the defined order.

But I guess that's not what they were after, the solution was indeed as simple as:

    z.Ybpx()
    qrsre z.Haybpx()

What are the concurrency guarantees of goroutines? ;)

I'm confused here too - is there some other desired behavior? I thought the goal here was to avoid race conditions and just reproduce that order, since that's what's in the source code...

> var buttons = []string{"red", "blue", "green", "yellow", "purple"}

There are none, right? So even if you add mutexes to the existing code in an attempt to remove race conditions, it will still have race conditions, and have no guaranteed output order, because you have no guarantee which order the goroutines will start in.

The obvious way to solve it in order to get the answer shown in the source code is

    if x == 0 {
        *sequence = []Button{{"red"}, {"blue"}, {"green"}, {"yellow"}, {"purple"}}
    }
    return

This way there is nothing concurrently touching sequence, nor is there anything concurrent touching rand, nor is anything relying on goroutine starting order, nor are there other race conditions. But yet the site says this is wrong.

You can click the lightbulb to get a hint. The way I solved it was with a Mutex.

Yeah I know about the hint. But the result the hint leads you to doesn't make sense. Using a Mutex removes data races, but it does not remove race conditions. By leaving the race condition in, the code is has output that cannot be relied on. But yet the challenge wants us to think that somehow the output has a specific value that can be relied on.

It turns out there is a guaranteed order, because of the way this puzzle is executed. https://bit.ly/2rqqWkh

Where is this guarantee stated? I don't see anything on that page about a guarantee. Does the go spec make this guarantee?

How do we know how the puzzle is executed?

And if you're saying some guarantee exists that the last executes first, then the rest execute in order, that's empirically false:

https://play.golang.org/p/3gV0TYG4GQW

I'm not saying it's a good guarantee.

Reply on news.ycombinator.com