Let the Go hacks begin….

I’ve been tinkering around a bit more and more with Google’s Go language, and I’m finding that I like it more and more.

I think its a great good evolution of compiled languages. A few quick thoughts on what I like so far:

Novel way to handle concurrency

With C or C++, you have to write a pretty big chunk of code to spawn a new thread. With Go, you just have to write
go function(), and its as easy as that!

Furthermore, in C/C++ you’re constantly dealing with locks to ensure data is protected. As you know, this can get pretty hairy. In go, you can set up a system based on locks as well, but you can also use Go “channels”. Talking about Go channels really deserves its own series of articles, but pretty much, a channel is a way that you can instruct independent processes to wait for data to become available, or to signal that data is available. This lets you ensure concurrency without ever having to think in terms of locks and unlocks. Furthermore, you can send arbitrary data types on these channels, allowing you to process data in one thread, and then send the finished result to a waiting thread very easily. Its a novel shake-up to the way concurrency has been thought of in a lot of other languages that I’ve seen.

Garbage Collection

Garbage collection is a nice feature to have in a language. You can make a strong academic case for manual garbage collection, but at the end of the day, its easier to allocate and forget it. I’ve heard that Go’s garbage collector still needs some work (as all collectors do), but I’m sure as the language evolves it will have less and less overhead…

Compiled language

I mostly live in the OS level, and interpreted languages just don’t do in a lot of situations I come across. Having a language that is directly compiled to the architecture’s assembly, and directly executable without any runtimes is something that is great.

Moderately easy C bindings

Go’s authors provide a moderately simple interface to use C code. As with a lot of bindings, its a bit funny at times, but I’ve been using it to great effect to add C functionality to go code.

A Functional Language that’s learned from Object Orientation

You can go back and forth over whether its better to use a functional language or an object orientated language, but I think it just comes down to what you need to use it for. It is indeed nice to be able to tie a set of data to a set of useful functions on them, but at the same time, but at the same time, I find its easy to get bogged down in semantics and formalities of very strict object oriented languages.

Go is a functional language, but it works around with this with some very simple ideas:
1) There are no classes, but there are packages that group similar code together. You don’t have to deal with header files and book-keeping either.
2) In a struct, a data member is accessible globally if its a capitalized, its accessible only within its package if its lowercase. So for instance, foo.bar would be only visible within its package (aka, private), but foo.Bar would be accessible from any code that imports the package (aka, public). Its a simple idea, and I have to say it works great.
3) A struct type may be associated with a function. This lets you designate a function, say Sort, and then tie it to struct. Anyone using the struct can say Foo.Sort(), and the Sort function will get all the data in Foo as a parameter of the function. This too is simple, and works really well.

Real native interface types

Its a compiled functional language, but it gives you access to slices, a powerful way to manage arrays that has native support for a lot of the things C++’s vector library can do (without a lot of the strangeness of that library…)

Really, whether you love functional or object oriented, you should give Go a try!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.