I've had this experience one to many times. And in self defence my code doesn't look ugly even when I've just written it; I don't have to come back and "clean it up".

I wrote my solutions to tour.golang.org at gist.github.com

How quickly I've picked up Go

I started writing Go with the cononical hello_world.go program on Jan 11, 2016.

I wrote a working B+Tree implementation in Go on Feb 11, 2016.

So I would say it took me 4 weeks to become "productive" in Go. I still need to use the Playground to work out small issues with Go syntax every now and again.

Testing Gist & Go Playground

The Gist:

The iframe embed of Go Playground heigh=500

Thunks and co with ES6 generators

A thunk is the output of a transformed node.js-style asynchronous function. The transformed function (aka the thunkified function) is meant to work with a generator wrapper. Here is the generator wrapper I am talking about:

co(function*(){
  ...alot of synchronous looking code...
})()

That generator wrapper takes the output of a thunkified async function call in a yield context and passes the ultimate results of the async call back to the original yield location; so code like this works (within the generator wrapper):

output = yield thunkfiedAsyncFn(args...)

Where node.js asynchronous functions are called with a few arguments plus one callback function to receive the output of the async operation, a thunkified node.js function call takes the original arguments MINUS the callbcak function and outputs a thunk function. In the above example what you are yielding to the generator wrapper is the thunk function. Here is a full example of reading a list of files in series: As you can see this is very different from how you would need to do it with the async module. For example, you can directly use the array subscript i of the fns array (normally you have to worry about the closure over i in a callback always being equal to 4.

To do the same async work in parallel you collect an array of thunk functions and yield that array. Example:

Just published v1.1.0 of my framing protocol module for node.js. https://github.com/lleo/node-frap I rewrote the input parsing routine completely for v1.1.0. It wasn't broken before, but the current version is much cleaner/better looking code. I remove gobs of what I've come to call vomit code. All the verbosity for debugging and assert-bombing to die close to a bug (old C-coder debugging style of mine). Lots of lines-of-code reduction. Makes it easier to read casually. I implemented a lot of BDD tests, based on the mocha framework. I wrote better benchmark scrips. Better but not very good. Overall, I'd say it is more stable and healthier code than v1.0.0.

IEEE 754 may not be such a kluge I thought it was

I just found out something elegant about double floating point numbers... or maybe this is just a Javascript thing.

function log2(v) { return Math.log(v)/Math.LN2 }
log2(Number.MAX_VALUE) //=> 1024

The Log base 2 of the Maximum double floating point number is 1024. There is something elegant about that. My respect for IEEE 754 just went up.