<p>I am interested in game programming and I like Golang, so I wonder whether it suits for game development in backend? How Golang is different from Node.js in terms of garbage collection?</p>
<hr/>**评论：**<br/><br/>koffiezet: <pre><p>I highly doubt if a GC would have any noticeable impact if this game backend would be accessed over the network. Your network latency would be a magnitude worse than whatever a GC could do.</p>
<p>Also, in Go, it's not that hard to minimize the GC pressure, but I really would not worry about that, premature optimization is not a good thing.</p>
<p>As far as languages go - Go is in my opinion a much cleaner language than Javascript. Node applications tend to become a callback nightmare to handle all async behavior. in Go, you just code straightforward in a go-routine, use channels to communicate between them and let the Go runtime do the async i/o stuff/scheduling for you.</p></pre>Jamo008: <pre><p>Wrote servers in Node for 3 years. Been in Go now for 1 year. Go is much nicer to work. I bet about 9 times out of 10, your code will be cleaner and more correct in Go. Also agree with @koffiezet, packets traverse networks in milliseconds, where GC happens in microseconds. In most cases, you can forget about GC.</p></pre>singron: <pre><p>Gc pauses are also on the order of milliseconds. The time is dependent on how many objects you have in memory (garbage + non-garbage). There isn't generational collection, so it has to look at every object on ever collection. Hopefully you won't see 100ms pauses unless you have a ton of objects, but don't expect microsecond pauses all the time.</p>
<p>The gc is getting more and more sophisticated, so shorter and more predictable pauses are possible in the future.</p></pre>cybwraith: <pre><p>The key difference for a web-based game, is that it is quite nice to be able to share much of the routines/logic between client and server with the same code-base. Depending on the kind of game we're talking about, this can be a significant time savings. But in general I agree that Go is much clearner.</p></pre>koffiezet: <pre><p>Code sharing between UI and backend is a myth that many people fall upon. Another thing many people seem to think is that it's easier to learn/code only one language, but to code in Node you also need to learn all it's specific libraries and conventions, and the same thing for a webbrowser - it might be the same language, but the environment and what you have at your disposal is completely different - which is exactly what takes the longest to learn/master. Both Javascript and Go as a language are pretty simple and easy to learn, it's learning the standard libraries that takes up time.</p>
<p>Also - there is a <a href="https://github.com/gopherjs/gopherjs" rel="nofollow">Go to Javascript</a> compiler - though I would not recommend it, it generates quite a bit of code <sup>^</sup></p></pre>The_Jare: <pre><p>For real-time multiplayer games with server-side logic like, say, Destiny or Diablo3, performance will be important and I'd recommend Go (this is usually done with C++ or Java, AirMech for example uses Go). For games with less strict requirements, like most social, turn-based and/or asynchronous mobile games, either is fine (as would also Python, Ruby, etc).</p></pre>mcvoid1: <pre><p>Really the backend of a web-based game isn't all that performance critical- all the heavy lifting is being done by the client.</p></pre>tusharsingh: <pre><p>Can you offer more details? What sort of game? Puzzle/Turn based, RTS, large maps, small maps, items to track, etc.? Do you need to do server side simulation in order to track cheating?</p></pre>agmcleod: <pre><p>In general I just think Go would be nicer to use. I like javascript on the web, but could never get into it for server side stuff. Go has some clever stuff with its go routines, and has shown to be a nicer alternative to some things people were using node for: <a href="http://highscalability.com/blog/2015/2/2/marco-arment-uses-go-instead-of-php-and-saves-money-by-cutti.html" rel="nofollow">http://highscalability.com/blog/2015/2/2/marco-arment-uses-go-instead-of-php-and-saves-money-by-cutti.html</a></p>
<p>He was using php. Tried it with node, and while he saw improvements he didn't like the settimeout weirdness. Tried go, and ended up switching to that.</p></pre>ThisAsYou: <pre><p>I thought Node was awesome until I started learning Go. Now I really can't think of a reason to use Node/iojs over Go... </p></pre>Vladev: <pre><p>Consider using <a href="https://github.com/Reactive-Extensions/RxJS" rel="nofollow">RxJS</a> and <a href="http://www.typescriptlang.org/" rel="nofollow">TypeScript</a> if you opt for node.js (or even the frontend). It will make your life much easier.</p>
<p>I've worked with both node.js and Go and if it's going to be a game with Web frontend - I would opt for node.js with the tools mentioned. Without them - go for Go.</p></pre>myth007: <pre><p>I am starter in Go but working in game development. I would suggest as Go learning curve is not high and it can solve all your problems. Best part is its inherent threading support which helps you set tasks in parallel (depends on cores). It mainly depends on kind of game you are planing to build, for non-real time games your server won't be heavy so it would be ok. To make real time games, RPC will be used for which there are many libraries available, so Go will do all what you need. GC won't be much of a issue which can hamper your performance.
I would suggest to do most of heavy lifting on client side and keep sever as simple as possible which will help you on scaling. Security can be handled with both included.</p></pre>ApatheticGodzilla: <pre><p>Depends on requirements of course. In general though I avoid node.js if I can - there are so many pitfalls with callback/promise/generator hell, error handling etc. Go is a bit more verbose but much easier to refactor, deploy and test. Node.js has some uses e.g. server-side rendering with React.js, but if possible I'd use Go (or any number of other server-side languages).</p></pre>joeydj: <pre><p>I've also tried to do something in that way. Although I liked that everything around Websockets and HTTP came out of the box, it did lack of the generics you would want to have.
In games you mostly play against other Players (Which is fine to abstract in the code) and NPCs.</p>
<p>NPCs are hard in my opinion. NPCs should be able to do what a player can do, but still be distinguishable in the code. There could also be objects in the game players and NPCs can interact with. Again if the objects are somehow placed in the game they should have something in common with others, like their current location, which would have to be implemented for every structure in the game including Player and NPC.</p>
<p>NPCs can be quest givers, and objects too (Depends of your game design). You would have to implement their behaviour twice, which would be tedious.</p>
<p>So IMHO I think that Go is not the language for game development.</p></pre>dwevlo: <pre><p>Javascript doesn't have generics either.</p></pre>Raiyni: <pre><p>Generally you wouldn't have a true backend for a web browser game because you want the clients doing most of the work. </p></pre>simonw: <pre><p>Unless you care about people cheating, in which case you need to have most of the multiplayer game engine logic running on the server.</p></pre>Raiyni: <pre><p>Eh. Cheaters will always find a way to cheat. </p></pre>Femaref: <pre><p>Doesn't mean you have to make it easy for them. Or not even put up a barrier.</p></pre>
