Developing games in Go?

Google's new Go language is still in its infancy, and it has yet to find widespread real-world use or support. Even so, it seems like a promising experiment, and I wonder if it could have a future in game development. I haven't been able to find much game-specific discussion of Go elsewhere, and figured a CW discussion may be appropriate.

Some thoughts:

• According to golang.org, Go programs "run nearly as quickly as comparable C or C++ code"--quick enough?
• Is Go's garbage collection well suited for games?
• How much mental re-tooling is necessary to create games in the land of concurrent goroutines?
• Go is frequently called a "systems"-level language, with server software given as an example. It's hard not to think of multiplayer game servers when hearing this.

Your thoughts?

From game development TSomKes

• My take on your questions:

  • The language is plenty quick enough. The slower Java language is used for game development. Even Python (pygame) is used for game development, and it's significantly slower than Java. It all depends on the type of game and how processor-intensive it is.
  • Garbage collection in general is not very good for games. However, Go has a particularly bad garbage collection system (mark-and-sweep) which stops the world while it cleans up stuff. It'll be difficult to cope with and will cause something of a stop-and-go framerate.
  • A decent amount of mental retooling is necessary to create games with coroutines. Graphics and logic can't be concurrent in the traditional sense; but at a smaller level, parts of the logic are great candidates for concurrent goroutines (e.g. parallel processing of AI decisions, particle systems, etc.)
  • A multiplayer game server may indeed be a great candidate for the Go language.

  In my opinion, if you have a strong enough urge to try writing games with a language, go for it. Obviously if you're considering it then you have a passion to do so, and why not follow that passion instead of forcing yourself to conform to the norm? I could say a lot more but I've already said a lot in my answer the question, "Is Ruby a suitable language for game development?"

  Joe Wreschnig : "a particularly bad garbage collection system (mark-and-sweep)" mark-and-sweep does not inherently stop the world - Java has a concurrent mark-and-sweep collector for example, and Lua used a naive one for a long time - and a lot of the length of the pause can be controlled via a careful generational system. That being said, Go's _is_ stop-the-world mark-and-sweep. But the former, not the latter, is the issue for games. (The Ruby thread had some weird claims about this too.)

  TSomKes : The current Go GC system seems to be something of a placeholder: "The current implementation is a plain mark-and-sweep collector but a replacement is in the works" (http://golang.org/doc/go_lang_faq.html#garbage_collection). Replacement options have been discussed; I'm not aware of any firm decisions on the matter.

  Ricket : Joe, thanks for clarifying! I wasn't aware of that. And yeah TSomKes, I did see that, so we can keep our hopes up that Go will implement a better garbage collector at some point.
  From Ricket

• Something else to think about is that since Go is still relatively new, there may not be bindings for a lot of the common libraries used in game development yet.

  TSomKes : Definitely the case. For example, I've come across two Go/SDL projects, one of which seems to have been abandoned. I've found a bare handful of (relatively small) games that use either of them.
  From Bob Somers

• Do not use Go to develop a game, it will just be an albatross around your neck. The toolchain for game development extends so much deeper than just the language that you write things in that you're going to find obstacles at every turn that just won't be there if you just go with something established.

  Don't get me wrong, I love playing with new languages, but if you are trying to make games pick a language that has a community and support and you will be much better off.

  Joe Wreschnig : On the other hand, if you're just going to hardcode stuff on a small indie project to play with a new language, worrying about the "toolchain" is overrated.
  From Aaron Brady