Marc Gravell

Select is a bit less common (at least in use) from what I've seen, yea... until you start looking at Promises and Rx. Then it's absolutely everywhere, e.g. `Promise.race(futures...)` (which trivially handles a flexible length of futures, unlike select) or any merging operator in Rx. More often though I see code waiting on all rather than any, and Go doesn't seem to change that.

Channels though are everywhere, and sample code tends to look almost exactly like introductory Go stuff[1] - Java has multiple BlockingQueues which serve the same purpose as a buffered channel, and SynchronousQueue is a non-buffered one. Though they don't generally include the concept of "close"...

But streams do have the "close" concept in nearly all cases, and streams are all over the place in many many forms, and have been for a long time. They generally replace both select and channels, but are usually much easier to use IMO (e.g. `stream.map(i -> i.string())` vs two channels + for/range/don't forget to safely close it or you leak a goroutine). Some of that is due to generics though.

[1]: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQueue.html

---

some alternate stream concepts are super interesting too, e.g. .NET's new pipelines: https://blog.marcgravell.com/2018/07/pipe-dreams-part-1.html

We put an explanation here (hope it's OK to post the link):

https://octopus.com/blog/build-your-binaries-once

A real world example of this is that when .NET 4.5 shipped, the compilers in .NET 4.5 for 4.0 code produced different output than the .NET 4.0 compilers would have. So installing a system-level update on Windows on a build server would mean Test and Production got different results:

http://blog.marcgravell.com/2012/09/iterator-blocks-missing-methods-and-net.html

Also, releases move through environments at different times:

Monday: 1.0 goes to Test

Tuesday: 1.1 goes to Test

Wednesday: 1.0 goes to Prod

Between 1.0 and 1.1, perhaps you updated Node, or went to Python3 - so your build server had to be updated. Reproducing Monday's build is going to be more difficult the more time that goes by.

As you said, truly reproducible builds are hard. Why not just zip the artifacts and use the same files, instead of rebuilding?

At the time the algorithm was running on one of the servers in the data centre and until recently we didn't have anything in the DC kitted out with GPUs (see http://blog.marcgravell.com/2016/05/how-i-found-cuda-or-rewriting-tag.html for the reason behind that).

I'm not sure if we're planning to use GPUs for future iterations of algorithm testing; the GPUs are installed in hardware serving production traffic so it's unlikely to be used for experimental stuff like this. That said, a bunch of us just got Dell XPS-15s with the NVIDIA GTX 1050 so we can probably have a go on our local machines to get a feel for performance characteristics... watch this space, I guess!

Code is here: https://github.com/mgravell/SimpleCUDAExample

Previous articles:

Part 1: http://blog.marcgravell.com/2016/05/how-i-found-cuda-or-rewriting-tag.html

Part 2: http://blog.marcgravell.com/2016/05/how-i-found-cuda-or-rewriting-tag_9.html