The power of ad-hoc interfaces

That’s not a technical term; it doesn’t mean anything by itself.  But since Go doesn’t have a term (or I’m not aware of it) for the particular flavor of type interfaces it supports, I’m calling Go’s interfaces “ad-hoc interfaces.” I keep being tickled by Go’s submarine features.  These are things which aren’t touted with any fanfare, but which I find more useful as I gain experience with the language.  In this case, the feature I’m growing increasingly fond of is the fact that types are not tightly coupled to interfaces; this is in contrast to Java objects, which are tightly coupled to interfaces.

Read More

Now *this* is interesting

I needed to compare some images for something at work and have been trying a few different approaches.  Since I wrote the application that’s using it in Go, and since this was going to be called tens of thousands of times, I was looking for a Go library rather than something I’d have to fork off a bunch.  I ended up implementing a couple of libraries, and one of these was a near-line-for-line clone of the pdiff application.

Read More

Programming satisfaction

The satisfaction quotient is very high with Go.  This post isn’t so much about Go, per se, except that I’ve been getting a high amount of satisfaction with my Go programs. I moved into management last year, and I don’t have much time for coding any more.  I work more managing than I did programming; most of my week is spent in meetings, which means that to get any of my tasks done, I have to put in more hours than the standard 40.

Read More

Go and Java

I recently had to write something in Java again, and was struck by the fact that – with Java – absence does not make the heart grow fonder. The little test application just read in an HTML file and broke it out into pieces – a prefix, containing everything up to and including the tag, the inner body HTML, and a suffix including the close body tag and everything after it.  It was just a sanity test for some regexp in Java.

Read More

Go revelations

Hoo boy.  There are some things which need to percolate in my subconscious for a while before I figure them out; when my brain accomplishes this feat, it’s a thoroughly enjoyable revelation.  When I was 20, it would happen in hours, or overnight; now it seems to take a bit longer (a couple of days), but I still enjoy it just as much. Go has a sort of multiple inheritance based on a rule called shallowest-first.

Read More

Mozilla's Rust Language

Mozilla released version 0.1 of it’s programming language offering called Rust.  There are a number of things about Rust which are nice; it uses LLVM, which means it gets tail-call-optimization, which Go doesn’t have; it has isolated, lightweight tasks, and channels much like Go; I’ve come across discussions about Erlang-style supervisors, which is encouraging; it has a Ruby-like syntax for closures; it has some limited type inferrence (very similar in scope to what Go can do); and it has pattern matching a-la OCaml, which Go doesn’t.

Read More

Universal truths

The fact that channel communications (whatever their implementation details) take much, much longer than function calls seems to be a constant truth no matter what the programming language.  I don’t have the benchmarks for Erlang offhand, but here are ones that I just recently ran for Go: main.BenchmarkChannel-2     500000              6106 ns/op main.BenchmarkFunction-2        100000000               10.2 ns/op main.BenchmarkAnonymous-2       100000000               11.5 ns/op Here’s the source code in case you want to pick holes in my benchmark: package mainimport “testing”func BenchmarkChannel(b *testing.B) {        c := make(chan int, 1000)        accum := 0        go func() { for { accum += <-c } }()        for i := 0; i < b.N; i++ {                c <- i        }}func BenchmarkFunction(b *testing.B) {        accum := 0        for i := 0; i < b.N; i++ {                handle(i, &accum)        }}func handle(v int, accum *int) {        *accum += v}func BenchmarkAnonymous(b testing.B) {        accum := 0        f := func(i int) { accum += i }        for i := 0; i < b.N; i++ {                f(i)        }} This was run with: gotest -run -cpu=2 -bench=‘.‘ Changing GOMAXPROCS didn’t make any difference.

Read More

Now we get to the annoying aspects of Go

I’ve spent another ten hours or so writing extensive functional tests for my code, and fixing bugs, so I have some further thoughts about Go. POLA gotest continues to be easy to use and is versatile, even if you do have to implement a bunch of basic functionality yourself (there are no convenient “assert” functions, there’s no setup or teardown functionality, and nothing like TestNG’s DataProvider mechanism).  Even functional testing of a server process is easier than in other languages, although I think most of that is again due to Go helping me separate my code into modules.

Read More

More Golang adventures

I recently wrote a little application called ConfigServer (although the project will probably be renamed). It is intended to be a tool to assist release managers and software deployments by providing a central server to hold configurations, but also allow configurations to be version controlled. ConfigServer provides some inheritance capability, the idea being that you can have a Cluster configuration, a Server configuration that inherits properties from the Cluster, and an Application configuration that inherits from the Server – ConfigServer doesn’t care about the schema, actually, but that’s an implementation detail.

Read More

JVM hate

I came across this paper, published by Google, comparing benchmarks in Scala, C++, Java, and Go.  Scala comes out on top (well, under C++) in performance, by a decent margin.  This surprised me a bit, but makes me happy – Scala is a functional language, and I do think functional languages are the (medium) future of software development.  My main beef with Scala is the JVM. There are (in my mind) several problems with the JVM.

Read More