In particular, if you’re going to the Google I/O conference next week and want to say hello, I’ll be at the Go programming language office hours. We’re also giving a tech talk and an introductory workshop. The Go language blog has details.
Go is a new, experimental, concurrent, garbage collected systems language. I’ve been programming in it for the last 6-9 months, and recently spoke about it at a number of universities.
“Concurrent” is one thing that distinguishes Go from other mainstream languages like C++, Java, or JavaScript. Goroutines and channels are lightweight in-process built-ins that are conceptually similar to Unix processes and pipes, and trace their roots back to Hoare’s CSP (something that students don’t seem to learn about these days). A colleague described it as programming with goroutines and channels compares to programming with threads, threadpools, mutexes and async callbacks the same way structured programming with if statements, for loops and function calls compares to spaghetti programming with goto.
Go is still a little early for prime time. The package library is still relatively thin, and there’s optimization work still to be done. But if you’re curious to learn more, there’s plenty of documentation on the Go language homepage.
3 comments ↓
What are the main differences of go from other asynchronous languages and frameworks? I am particularly interested in hearing your thoughts about Go vs:
1-Erlang
2-Scala
3-Stackless Python
4-Twisted Python framework
To be honest, I don’t know if I have enough experience with any of those languages and libraries to have a well informed opinion, and I’m really not sure if the rest of what I say is 100% correct…
Erlang looks like a functional language, with single assignment, but Go certainly looks like a member of the C family. Erlang has certainly proven itself in serious production systems, but the syntax is different than other languages I’m used to. As for concurrency, I think in Erlang each process only has one “inbox” and you send messages to a PID, whereas in Go a goroutine can receive from multiple channels. Erlang has stuff for fault tolerance, Go is still exploring this space.
Scala is a fun looking language. I know that this isn’t about the concurrency model, but one thing with Scala is that it runs on top of the JVM, and has Java-flavored object orientation. This is great because you can re-use existing Java libraries, but it does mean you’re limited to what the JVM provides. For example, http://loadcode.blogspot.com/2009/12/go-vs-java.html says that a Java port of git performed badly because the JVM (1) doesn’t have unsigned ints and (2) can’t inline a byte[20] with the rest of an object. Go can do both.
In Go you can select to receive from multiple channels, which I don’t think you can do in Stackless (although I’d be happy to be proven wrong).
Twisted appears based around futures (they call them deferreds). In Go you can implement a future very simply with a goroutine and a channel, but that’s not the only thing you can do with goroutines and channels.
But I hear good things about all four things you mentioned.
thanks for the evaluation, i am looking forward to testing go after a framework is implemented on top of it(not brave enough to implement a framework myself:-))
Leave a Comment