The Environment Object Pattern in Go

One of the things I've been really enjoying about Go is how easy testing is. The pervasive use of interfaces and composition-instead-of-inheritance synergize nicely for testing. But as I've expressed this online on reddit and Hacker News a couple of times, I've found that this does not seem to be a universally-shared opinion. Some have even commented on how hard it is to test in Go.

Since we are all obviously using the same language, the difference must lie in coding behavior. I've internalized a lot of testing methodology over the years, and I find some of the things work even better in Go that most other imperative languages. Let me share one of my core tricks today, which I will call the Environment Object pattern, and why Go makes it incrementally easier to use than other similar (imperative) environments.

So you want to write a Monad tutorial in Not-Haskell...

There are a number of errors made in putative Monad tutorials in languages other than Haskell. Any implementation of monadic computations should be able to implement the equivalent of the following in Haskell: minimal :: Bool -> [(Int, String)] minimal b = do x <- if b then [1, 2] else [3, 4] if x `mod` 2 == 0 then do y <- ["a", "b"] return (x, y) else do y <- ["

Scientists (and, in my experience, especially bioinformaticians) tend to make horrible, awful messes no matter how maintainable you think a language is. (You can hand them Inform 7 and it'll still end up looking like Fortran ate the csh manual and vomited all over an APL keyboard.)-- chromatic on HN

I don't listen to the radio hardly at all anymore. Recently, I was with my wife while she was just idly flipping through, and I was astounded. Rappers? Autotuned. Rockers? Autotuned. Country? Autotuned. The electro/techno stuff was autotuned, but that's less of a surprise. Autotune, autotune, AUTOTUNE! Not even subtly, either, but cranked up as far as it will go before the high end simply explodes with noise. Is there anyone left in the music industry that can carry a tune?

I've pushed two repos to GitHub with Go code: gomempool (godoc): A []byte pool manager for Go. It's less generic than the Pool implementation that is working its way into Go tip, but also therefore understands more about []bytes, and is much simpler than the I-don't-even-know-what magic is in that implementation. It also tracks stats, which I've hooked up to my monitoring so I can see the usefulness of the pool in my real running code.

Computer Security Haiku

Gold in vault, target Steel door closed, locked, key thrown away; Thief laughs "There's no wall!" Data stream flows, filling Lake overflows; disaster! Arbitrary code Man trusts fellow Man, fellow Man undeserving. Script code injected. Novice celebrates, Output easy, just append strings! Master needs new novice. Dark secrets made, shared Tells foe the password is lost... Rubber hose finds it. "Love", Alice tells Bob In anger, Eve flips one bit

Parametricity in Go

One of my objections to Erlang is that despite paying the price of being a functional language, it often fails to reap the advantages. An example of this is in testability; nominally, a purely functional bit of code ought to be easier to test than the imperative equivalent, because it is just a matter of setting up your parameters and checking the results, with no IO or state in between.

Erlang doesn't make this impossible, but it's less convenient than the brochure promises. The core of your application is generally locked up in the various gen_* handlers. These handlers have very stereotyped ways of being called, which include the full state of the thing being tested. I find this very tedious to test, for two reasons: 1. Every test assertion must define some sort of "complete state" for the handler, which is probably full of real-world concerns in it. In particular if it has further messages it is going to send, those are often relatively hard-coded somehow... an inconvenient-to-mock Mnesia entry, an atom-registered process name, etc. (Erlang programs end up having a surprising amount of global state like that.) 2. If you want to test some sort of sequence of events, you are responsible for threading through the code, or manually invoking the proper gen_* start up functions, or something. It's possible to refactor your way out of this mess, but in practice it's a lot of work for the reward. So many of the tools you could use in other languages aren't available.

Go, in theory, ought to be harder to test than Erlang, being an imperative programming language. In practice, I'm finding it much easier, and I'm doing a lot more testing in it.

Mathematical Diversions: Producing Helium from Hydrogen

In response to this story about a possible impending Helium shortage, someone suggested on Hacker News that perhaps someday we can use nuclear fusion to produce helium.

As it happens I'd idly chatted with my wife about that a few weeks ago, but that wasn't enough motivation to run the numbers. This was. Could we produce enough helium to satisfy our commercial production of it through fusion, if we just assume we have fusion?

I had a dream this morning that my workplace had so suddenly shut down that there was nothing in the office when I got there, except a sign telling us that due to financial shenanigans the entire office had to be immediately liquidated, and a whole bunch of my coworkers milling around being angry about it. Since I work for a tech company, this is quite silly. The assets of a tech company aren't anything interesting at all compared to the people, and an emergency fire sale would hardly recover anything of value.

It is important to use a cartridge of the appropriate size for your target. Shooting a [UAV] drone with .22 rimfire for instance would be cruel. You need something that will kill the drone, not make it suffer. - jlgreco on HN