Difference between revisions of "Go"
(Added cat-v link) |
(Mention of gc and gccgo) |
||
| Line 5: | Line 5: | ||
Go has several modern programming features, such as garbage collection and closures, which help when developing roguelikes. It has a reasonably simple duck-typing-based object system, which is clean, but doesn't necessarily match the complex problem of roguelike data modeling. The concurrent features aren't much needed in main roguelike logic, which is generally very sequential, but can help when programming an user interface that runs asynchronously with the game logic. | Go has several modern programming features, such as garbage collection and closures, which help when developing roguelikes. It has a reasonably simple duck-typing-based object system, which is clean, but doesn't necessarily match the complex problem of roguelike data modeling. The concurrent features aren't much needed in main roguelike logic, which is generally very sequential, but can help when programming an user interface that runs asynchronously with the game logic. | ||
Go supports Linux, BSD and OS X, but as of 2010-01, the Go build environment has not been completely ported to Windows. | Go supports Linux, BSD and OS X, but as of 2010-01, the Go build environment has not been completely ported to Windows. It has two compilers, '''gc''', and a gcc front-end '''gccgo'''. As of 2010-01, gccgo doensn't support garbage collection, and therefore isn't a viable compiler for a long-running Go program such as a computer game. | ||
There is FFI support for linking to external C libraries like [[SDL]] or [[Curses]]. Calling C code from Go is reasonably straightforward. As of 2010-01, distributing a Go binary linked to foreign shared libraries is problematic. See [http://groups.google.com/group/golang-nuts/browse_thread/thread/20ff377c05e49a5e this post] on the golang-nuts mailing list for a description of the problem and some proposed solutions. | There is FFI support for linking to external C libraries like [[SDL]] or [[Curses]]. Calling C code from Go is reasonably straightforward. As of 2010-01, distributing a Go binary linked to foreign shared libraries is problematic. See [http://groups.google.com/group/golang-nuts/browse_thread/thread/20ff377c05e49a5e this post] on the golang-nuts mailing list for a description of the problem and some proposed solutions. | ||
Revision as of 16:20, 27 January 2010
Go is a programming language announced by Google in November 2009. It is a native-code compiled, garbage-collected, concurrent language. The design idea seems to be to make a modernized version of C.
Roguelike Issues
Go has several modern programming features, such as garbage collection and closures, which help when developing roguelikes. It has a reasonably simple duck-typing-based object system, which is clean, but doesn't necessarily match the complex problem of roguelike data modeling. The concurrent features aren't much needed in main roguelike logic, which is generally very sequential, but can help when programming an user interface that runs asynchronously with the game logic.
Go supports Linux, BSD and OS X, but as of 2010-01, the Go build environment has not been completely ported to Windows. It has two compilers, gc, and a gcc front-end gccgo. As of 2010-01, gccgo doensn't support garbage collection, and therefore isn't a viable compiler for a long-running Go program such as a computer game.
There is FFI support for linking to external C libraries like SDL or Curses. Calling C code from Go is reasonably straightforward. As of 2010-01, distributing a Go binary linked to foreign shared libraries is problematic. See this post on the golang-nuts mailing list for a description of the problem and some proposed solutions.