While Star Trek was ahead of its time in many ways, you could tell they never lived with the technology they hypothesized. For instance, there's no episode in which Wesley Crusher walks around with his PADD unlocked while cradling it on his chest, causing a Major Interstellar Diplomatic Incident when he accidentally ends up emailing pictures of his armpit to the Klingon High Council along with a text message consisting of "klxitijtjqtktkjjt", which is of course an ancient and dishonorable way of challenging the entire Council to a mandatory duel to the death.

And the cat's in the cradle and the silver spoon,
Little boy blue and the man in the moon.
"When you coming home, dad?" "I'm home right now,
having some fun and how,
You know we're having fun and how!"

Go comes in part from Rob Pike and Ken Thompson, both influential in early UNIX. Both Rob Pike and Ken Thompson also were influential in working on Plan 9, a followup to UNIX.

UNIX's ideal is that "everything is a file". In Go terminology, this is a declaration that everything should be accessible via a uniform interface, which the OS specially privileges. One of Plan 9's core reasons for existing is that UNIX didn't take this anywhere near as far as it could be taken, and it goes much further in making everything accessible as a file in a directory structure.

I'm skeptical of both of these approaches. Everything isn't a "file".

There's numerous "files" that require ioctls to correctly manipulate, which are arbitrary extensions outside of the file interface. On the flip side, there are all kinds of "files" that can't be seeked, such as sockets, or files that can't be closed, like UDP streams. Pretty much every element of the file interface is one that doesn't apply to some "file", somewhere.

The Procrustean approach to software engineering tends to have the same results as Procrustes himself did, gravely or even fatally wounding the code in question.

Supervisor trees are one of the core ingredients in Erlang's reliability and let it crash philosophy. A well-structured Erlang program is broken into multiple independent pieces that communicate via messages, and when a piece crashes, the supervisor of that piece automatically restarts it.

This may not sound very impressive if you've never used it. But I have witnessed systems that I have written experience dozens of crashes per minute, but function correctly for 99% of the users. Even as I have been writing suture, I have on occasion been astonished to flip my screen over to the console of Go program I've written with suture, and been surprised to discover that it's actually been merrily crashing away during my manual testing, but soldiering on so well I didn't even know.

(This is, of course, immediately followed by improving my logging so I do know when it happens in the future. Being crash-resistant is good, but one should not "spend" this valuable resource frivolously!)

I've been porting a system out of Erlang into Go for various other reasons, and I've missed having supervisor trees around. I decided to create them in Go. But this is one of those cases where we do not need a transliteration of the Erlang code into Go. For one thing, that's simply impossible as the two are mutually incompatible in some fundamental ways. We want an idiomatic translation of the functionality, which retains as much as possible of the original while perhaps introducing whatever new local capabilities into it make sense.

To correctly do that, step one is to deeply examine not only the what of Erlang supervision trees, but the why, and then figure out how to translate.

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.

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 <- ["y", "z"]
            return (x, y)

This should yield the local equivalent of:

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.
• abtime (godoc): An abstract time library that removes your dependency on the OS time from the time module. I've now run into this problem at work in three forms; unfortunately one of them is in a module I plan on releasing someday and don't want a dependency on this module, but the other two can benefit from a standardized way of dealing with this. I had a semi-complete version of this in my local code base already, but I was inspired to bring it up to public spec by Moonpig.

Both libraries have 100% test coverage, and are golint and go vet clean.

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
Now love's checksum fails