Yesterday I went to Pycon Australia in Sydney. It was a great conference; well-organized, great speakers, and a fun crowd. I used to write a lot of Python code professionally, so it was both interesting and rewarding for me to get back in touch with the Python community.

I signed up for one of the lightning talk slots at the end of the day, with the contentious title “Love Python? Try Go!” When I asked a friend if it was inappropriate to give a talk about Go at a Python conference, he replied “Giving your talk without pants on is inappropriate. Talking about Go is just obscene!” Undeterred, I prepared and delivered my talk anyway (see the slides).

The talk was surprisingly well-received (I didn’t get booed off the stage). There was the requisite heckling from my friends and colleagues in the front row, but when they judged each of the talks by applause I got a reasonable showing (I expected stony silence).

My talk sparked a number of conversations at the pub afterwards. Were I to do the talk again there are some things I would have done differently:

• I wouldn’t make such a big deal about static typing.

It turns out that Python programmers like dynamic typing. A lot. Python’s run time typing errors just don’t seem to be a big deal to most Python programmers.

This surprised me, because my number one peeve with dynamic languages is how fragile the code feels. In Go, I can fearlessly refactor code with the confidence that most silly mistakes will be caught by the compiler. I have never had the same confidence when writing Python code.

One counter-argument is that good tests will catch those same kinds of errors. This is true to some extent, but I contend that static type checking saves time during develpoment, too. Unless you write your tests up front (I don’t) you won’t get that important benefit in a dynamic language.

But I digress. The “static vs dynamic typing” discussion is deep and subtle, which makes it a poor choice for a 5-minute lightning talk. I should have left it out.

• I would have somebody thoroughly proofread my slides.

On the slide about fast compilation I stated that “Typical programs build in <1 second,” except I used a greater-than sign by mistake. That got a laugh, at least, even if I didn’t know why at the time.

• I would make the point that programming languages are not a religion and that language choice is not a zero-sum game.

Learning a new programming language does not mean you forget the other ones; it just makes you a better programmer by giving you more options and experience.

The intent of my talk was not to coax programmers away from Python to Go. I wanted to tell people about Go and show that it offers some real benefits over other languages for some tasks. While I personally prefer to use Go over other languages for pretty much anything, I certainly don’t expect that everyone should feel the same. I’m not a Go zealot (or a troll), and I hope I didn’t come across that way. :–)

Software systems are mostly heterogeneous, particularly in the web world. For example, Python programs consist of a lot of C code, and most Python web apps are deployed behind a web server written in C. Were I giving the talk again, I would focus on the benefits of adding Go to your software development toolset, and give some real examples of systems that use both Python and Go.

So, in conclusion, if you’re a Pythonista with the need for speed and/or concurrency – or you’re just interested in learning something quite different and new – I (once more) encourage you to try Go. It may not replace Python in your day-to-day life but – like any new tool – it might just make your life easier.

Good starting points are my Real World Go talk and the Go documentation. And, if you’re in Sydney, come along to the Sydney GTUG on Tuesday the 30th of August where Rob Pike and I will be giving a couple of Go presentations.