Skip to main content

Posts

Showing posts with the label Golang

Some Go Irks and Quirks

Now that Jump Start MySQL is published, I’m taking advantage of the spare time I have on my hands while it lasts. I’ve helped organize the Syracuse PHP Users Group , reconnected with some old friends, and gave some love to Kiwi , my forever-project programming language. Moreover, I decided to rewrite Kiwi using Go as it’s one of those languages I found interesting but never had a reason to use in any serious fashion. And now that I’ve got some real experience with it, while I still find myself impressed by some of Go’s features, some things have become really annoying. I still really like Go’s data typing; it’s static, but it feels dynamic because the compiler is smart enough to deduce a value’s type. If you write your code well then you’ll rarely see a type name outside of a function signature or struct or interface definition. It’s nice to have type safety without the verbosity (yes I’m looking at you, PHP7). I wish := behaved slightly different, though. Instead of always an allo...

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...

A Week with Go, Day 2

After dabbling a little bit on day 1, I dedicated some time on day 2 to skim through Go's language spec and standard libraries . A lot of it didn't have much relevance to me yet because I hadn't begun to play with those parts of the language. What caught my eye though was that Go supports the \v escape (obviously no one at Google has read Stop the Vertical Tab Madness ). Welcome to 1963, folks. In addition to tweaking how loops are written, Go has augmented the traditional syntax of if and switch statements too. I don't see the enhancement providing as much benefit as I do with for . It's almost as if someone decided to let people move the placement of if up a statement earlier just to be different, and it certainly doesn't read well. x := recover() if x != nil { ... } vs if x := recover(); x != nil { ... } The list of available packages is rather impressive considering Go has been available for a year. Some packages are pretty standard, like math and...

A Week with Go, Day 1

Go is a general purpose systems programming language developed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. Go has been on my radar since it became publicly available a year ago as an open source project, and since then its documentation has been improving and a small community of users has been forming around the language. Last week I had some time off from work that coincided nicely with the Thanksgiving holiday and I thought it'd be fun to spend some of it looking at Go. Here's the first in a series of five posts that share my thoughts and experiences of spending a week with Go. My first Go programs were solutions to a couple Project Euler solutions. This was just to get a basic feel for its syntax. Problem 1 package main import fmt "fmt" func main() { sum := 0 for i := 0; i < 1000; i++ { if i%3 == 0 || i%5 == 0 { sum += i } } fmt.Printf("%d\n", sum) } There are a few oddities, but ove...