I am using Go for a voxel based game, where the server is defined in Go and the client in C++. For me, I am able to produce three times as many algorithms a day with Go compared to C++. It is just so much simpler. When it compiles, it almost always works. Maybe I am too inexperienced with C++.
With C++11, C++ is moving closer to Go, but at the cost of getting more complicated.
The game server is designed for managing 10000 simultaneous players on one computer, and it looks like the target can be met. Simulation on my desktop computer shows 10% load (CPU, memory and communication bandwidth) for 1000 players. Of course, it can always be questioned whether a simulation is realistic, and it is difficult to predict player behavior. The size of the server and the client is currently at around 15000 lines each.
Meh. When generics are supported I will become interested in Go again. Generics are absolutely vital. Heck, Go's map is already a generic type, so obviously there is some necessity there. But we aren't allowed to create any. Right.
My client uses generics all of the place, and wouldn't be feasible without it. For the server, I didn't miss the availability of generics. At least not that I can remember.
What also annoys me to no end though is that they routinely trade run time for compile time. Great the compiler is fast, but the programs are slow (and fraggin huge). But in any real world application, the number of program executions should be far higher than the number of compiles. If execution speed is unimportant, I might just as well stick with Python.[/quote]
If that worries you, go for the gcc implementation of Go. The size of the executables are big because they are linked statically. That could be a problem if you want to make a long list of small programs. If you make a game server, or a web server, it doesn't matter. Anyway, the game server recompiles in 2.7s (core I7). The client recompiles in 9s on Linux, and twice that on Windows (using MinGW).
Not to say everything is bad about go. The concept of interfaces is very nice. Also love the defer statement. And a bunch of other stuff too. But no generics = no thanks.
[/quote]
What saves me most time of all, is the garbage collection. Yes, it degrades the performance (marginally), but when you no longer need to worry over allocation and deallocation you will become more efficient. Of course, it can't be ignored completely (for a long living application you need to have a basic understanding on what can prevent memory from being freed). GC is also a problem if you have requirements on hard real time, but so far it isn't noticeable in my load tests of the game server.
So why didn't I use Go for the client? There are still too many libraries that I need from the C world. Or at least it was that way when I started two years ago.
[attachment=10279:DynamicShadows_2012-07-28.jpeg]