Skip to main content

Posts

Showing posts from December, 2010

Ubuntu Packages Please Get Your Act Together

I didn't intend to write another blog entry so close to the conclusion of my Week with Go series, but my experiences earlier today definitely warranted a rant. Installing the SpiderMonkey JavaScript engine for use as a stand-alone interpreter on Ubuntu 10.04 LTS doesn't sound like outlandish goal. After all, CouchDB ships by default as of 9.10 and it requires a JavaScript run-time. Technologies like node.js and v8 are pretty hot right now so there might even be a few alternatives to choose from, right? WRONG! sudo apt-get install spidermonkey-bin E: Couldn't find package spidermonkey-bin There used to be such a package but apparently SpiderMonkey is "unsupported" now and was removed from the Universe repository. Sorry Ubuntu. I'm not feeling the love for Rhino. It doesn't do JIT and runs slower than a one-legged sloth. Besides, I don't feel like installing ca-certificates-java , default-jre-headless , icedtea-6-jre-cacao , java-common , libavahi-

A Week with Go, Day 5

Concurrent programming in Go makes use of coroutines, which are quaintly called "goroutines", and channels. Coroutines are functions executed asynchronously from the rest of your program, and channels are synchronous pipes through which the routines communicate. I had written a multi-threaded Kember Identity program in C a while back, and decided to rewrite it in Go to gain some exposure working with these features. The Effective Go primer gives a hint of what goes on under the hood with coroutines in Go. A goroutine has a simple model: it is a function executing in parallel with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required. Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the compl

A Week with Go, Day 4

Day 4 was spent learning about Go's take on object oriented programming, which I found to be a refreshing change from the likes of Java and C#. It's not type-focused; instead of relying on an object's type to know whether or not it offer certain functionality, the object will generally implement an interface. This mindset is not dissimilar to good JavaScript programming where feature detection is preferred over browser sniffing. The code doesn't care what something is (browser/object), just what it can do (functionality/interface). The word "object" is probably a bit misleading since Go doesn't really have them in the traditional sense. There's no need to write a class definition as in Java, nor to instantiate an object literal like JavaScript. The programmer specifies a set of functions and Go's compiler deduces the relationships. type Rectangle struct { width float height float } func (r *Rectangle) Area() float { return r.widt

A Week with Go, Day 3

The first two days of tinkering and scouring helped me form an opinion of Go based on its syntax. To form a more-informed opinion I would have to write some more code and see how much resistance I experienced along the way. What features were missing? How was typing applied? I wrote a rudimentary version of Deal or No Deal , and slowly some of those meaningless sections in the language spec started taking on more meaning. I decided to store the case amounts as an integer array (nobody likes the 0.01 anyway!) and came across my first bit of frustration and misunderstanding when it came time to shuffle the amounts. cases = []int{100, 200, 300, 400, 500, 750, 1000, 5000, 10000, 50000} shuffle(cases) func shuffle(arr []int) { rand.Seed(time.Nanoseconds()) for i := len(arr) - 1; i > 0; i-- { j := rand.Intn(i) arr[i], arr[j] = arr[j], arr[i] } } The language spec says arrays are value types and slices are reference types. shu