Dec
01
2009

Go is a Series of Tubes

Go, the brand-spanking new language from Google that arrived November 10, 2009, is a compiled, concurrent, threaded systems language — the first systems language of this decade!

The intent was to produce a language that had performance comparable to C, but developer satisfaction comparable to that of Python or Ruby. The language features some impressive ideas, including type inference, shorthand for declaration, initialization, and assignment, and interfaces, but I’d like to talk about my favorite features – Go routines and channels.

“Hey Joey, look at the f***in’ tubes!”

~George Carlin

Go Routines
Rather than using threads, Go supplies a mechanism called a Go routine. While these operate in a similar manner to threads, they have the benefit of being load-balanced internally across real threads by the Go language.

func threadedThing(){
  // Do some stuff
}

func main() {
  go threadedThing();
  // Continue without blocking!
}

Go routines can also be declared anonymously, like so:

func main() {
  go func() {
    // Do some stuff
  }(); // <- parentheses to call the function
  // Continue without blocking!
}

Channels (Tubes)
Go calls them channels, I call them tubes! Channels form the basis of how we can communicate between Go routines. Take the following example:

func printer(input chan int){
  var a int;
  for {
    a <- input;
    fmt.println("Receieved: ",a);
  }
}

func main() {
  tube := make(chan int);
  go printer(tube);
  for i:=0; i < 10; i++ {
    tube <- i;
  }
}

In the above example, the printer will block until it receives an item from the input channel (a <- input), and then print it out. Meanwhile, the main send values through the channel (tube <- i) - and it also blocks. However, if we change the declaration of the channel to include a buffer...

tube := make(chan int, 10)

...the main can continue to loop, simply dropping things into the channel buffer.

When is a tube not a tube?
Consider the following example:

func main() {
  killswitch := make(chan int);
  go server(killswitch);
  // Do some work
  <- killswitch;
}


Here we see an example of how you might "join" another "thread", but in Go terms. Rather than using the channel to communicate data, we simply await any communication from the channel, and then quit. Since reading from the channel is a blocking operation, the server Go routine can simply write any value to the killswitch channel, and the main will read it, discard it, and terminate.

Channels can be used for a variety of different purposes - to transmit data, to acts as a termination signal, and even as semaphores. The flexibility of a language like Go makes it a treat to work with, and I encourage you to head over to http://golang.org and take a look for yourself!

Nov
21
2009

RubyConf Part Three: This is Why

This entry is part 2 of 3 in the series RubyConf 2009

The final day of RubyConf 2009 was a poignant reminder of _Why: why we love Ruby, why we go to conferences, and why the Ruby community is unlike any collection of developers. This was perhaps embodied best by the Programming with the Stars event which ran during the lunch period of each day of the conference.

Developers passionately watched as pairs competed in a paired-programming event to demonstrate good coding practices and refactor things for the better. Every individual in the room was excited and involved in considering best practices for development in Ruby—in what other community are individuals so excited about not only getting work done, but doing it in the best way possible? A big thanks to Corey Haines (@coreyhaines) for organizing this event!

The day had several great talks as well.

  • Stuart Holloway urged Rubyists to consider what their next language was going to be—specifically, by discussing things he loved about Clojure. Stuart reminded us that we’re passionate developers, and our enthusiasm doesn’t need to be constrained to a specific language domain—get out there and have fun with something new.
  • Aaron Patterson (@tenderlove) and Ryan Davis brought the house down with their Worst. Ideas. Ever presentation. Some of the fantastic topics included optimizing web performance by writing in assembly, “Ruby doesn’t scale…but XML scales like a boss!”using PHP for Rails views, and making Ruby more “enterprise” by converting it to XML (because, as everyone knows, Rails doesn’t scale, but XML does). The mentioned that they actually did encounter a few bugs in Nokogiri and other libraries, just in writing the samples for this project—bugs that likely could have gone unchecked otherwise. The overall message: do stupid stuff; play with fire; having fun with a language is hardly something to be avoided—even if the overall product might not have any real value.

As the _why-esque art from the RubyConf whiteboard—along with all the presentations from the event—remind us, Ruby is fun, Ruby is never finished, and there are always people who look forward to working with you in the community.

Thanks to everyone involved for a truly phenomenal RubyConf 2009.

Nov
20
2009

RubyConf Part Two: Principles and Progress

This entry is part 2 of 3 in the series RubyConf 2009

Day two of RubyConf 2009 was just as exciting as the first. Unfortunately, I slept through a piece of it! I woke up around 9:30AM—just short of making it to Ben Scofield (@bscofield)’s presentation on non-relational databases. Ben gave a really fantastic presentation at Windy City Rails 2009, where he described particular problem domains that don’t lend themselves to standard relational modeling—specifically cross-bred animals like Ligers when trying to model classifications of species, or worse, the incredibly confusing situation regarding comic books. From talking to Ben, the presentation he gave today would have been a great followup to that talk – as he demonstrated some of the non-relational tools that developers are beginning to use for persistence. I’m very sorry I missed his talk, but thankfully, all the presentations are being recorded!

Great talks continued throughout the day; some of the highlights included:

  • Jim Weirich (@jimweirich)’s talk on SOLID Ruby covered the idea that as developers, we still have a really hard time discussing what good code design is. The SOLID principles were laid out as objective means of evaluating static languages—but that doesn’t mean there isn’t great use for them as guides for developing Ruby code. SOLID, while written for static languages, is a good guide for RubyMost notably, Jim talked about how Java developers consistently try to “program to the interface”, because the abstraction layer of interfaces allows for increased modularity. With Ruby, this isn’t necessary—objects are objects. However, in order to maintain the modularity, clients who use functions that expect a certain type of object need to know what the input specs are. Therefore, it’s incredibly important to discuss the virtual concept of “protocol” between methods, in documentation.
  • Chris Wanstrath (@defunkt) presented on Python—specifically looking at ideas that the Ruby community could learn from or take away. He gave a brief overview of the language, and a brief description of some of the cool libraries that Ruby doesn’t quite have, or could improve upon. Chris’ ultimate message was that adopting new languages is a practice that should be encouraged, because communities have a lot to learn from each other, and it’s never good to get too comfortable at any one thing for too long.
  • Noah Thorpe (@aquabu) gave a demonstration of various audio libraries in Ruby. He discussed how music could be generated from mathematical constants, using various technologies. However, Ruby does have the limitation of being an interpreted language, so real-time audio is a bit crippled. He did suggest, however, that JRuby might help to fix this problem. Several of the demos were very exciting, and I can’t wait to play around with the code myself.

Day two of the conference ended with a hasty rush to the Startup Crawl—a tour of open-house events hosted by Ruby startups in the San Francisco area. While I decided not to attend, many developers are currently traveling between such wonderful companies as Scribd, Engine Yard, Heroku, Justin.tv, Apture, Yammer, HeyZap, Pivotal Labs, SocialCast, Sauce Labs, ZenDesk, Shop It To Me, Chargify, BigTent, Airbnb, Plato’s Forms, and Dropbox.

Recent Twitter updates suggest some transportation hiccups, but it appears to be a great event!

Search