EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).
Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games.
(In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.)
On the other hand, there are less high-quality libraries in Go than in C++ or in JS. That may be the most limiting factor.
Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.
One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twiddle without looking too glitchy, maybe you can figure out some way to shed work when you start to fall behind.
It'd be really cool to see someone attempt a game or such in Go--boundary pushing's always fun, more so when the boundaries are recently expanded.
No sane game developer would use anything other than Assembly.
The more things change, the more they stay the same.
"It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways.
Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly.
The compilers weren't that good generating code and they didn't want to loose the power of Assembly.
Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago.
We need to keep the spirit of taking things far alive, because in computing seeing is believing.
Apparently younger generations are unaware that C was seen as a managed language in the 80's and early 90's, with compilers not generating good enough code for game development.
In the 90's I have seen lots of Turbo Pascal and C code where the functions where plain wrappers for inline Assembly.
So unless you intend to write Crysis in Go, there are lots of games you can write with it.
It's a voxel game based on OpenGL. It implements much of vanilla minecraft. Annecdotally, I'd say it performs much better for me than minecraft itself does, at longer view distances, and with essentially no observable GC pauses (of which minecraft suffers quite visibly). Also, a stabler heap size, etc.
The capabilities are definitely there.
I'm spending some of my weekend moments playing around with more GL stuff based on what I've learned from reading this project, and it's quite fun. Build times are right up there where you'd expect, too -- seconds or less! (The first build takes a few moments for running gcc for the c bindings to GL, but after that, those cache nicely.) A 1-second turnaround for recompiling a whole game is an incredible breath of fresh air.
And of course, I shipped my demo game to a friend on a mac the same day I started writing. I'm on a linux. Not bad.
Whether you can write the whole game in it - I don't know, but it'll be pretty good for tools/editors/pipeline/etc.
So always take the JIT/GC complains in Unity3D context with that caveat in mind.
On one side they did a great job increasing the visibility of C# among game developers, which tend to only switch languages when the OS and console SDKs push them to do so.
On the other hand, they spread the feeling that C# is bad for game development among developers that don't understand "language != implementation" and take their Unity's experience as how C# implementations performs in general.
However I also should say that they are aware of it and planing to improve the situation after their IL2CPP compiler stabilizes.
Found a blog post by Joel Webber, who I have not heard of, but he was working on a minecraft clone and had some advice on avoiding GC and memory layout:
http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go
Also found an engine, Azul 3D, and they made this claim:
https://azul3d.org/doc/faq.html#what-about-the-garbage-colle...
Then there is termloop, which is a terminal based engine:
https://github.com/JoelOtter/termloop
Fun for indie game stuff.
So, yeah. There's that.
If KSP works in C#, you can write a game in Go no problem.
Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.
It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.
No and no.
> But the CLR does now, and always has, had a JIT.
And Python has had a JIT[0] for as long as the framework has existed.
[0] https://en.wikipedia.org/wiki/Psyco now replaced by the pypy project
- JIT and AOT compilation via NGEN up to .NET 4.5.2
- Starting with .NET 4.6, RyuJIT which uses the Visual C++ backend and exposes SIMD support to .NET languages
- When targeting Windows 8 and 8.1, AOT compilation to native code in a format called MDIL. Basically requires dynamic linking on device, everything else will be native code already
- When targeting Window 10 store applications onwards, AOT compilation to static executables
- .NET Compact Framework also always JITs
- .NET Micro Framework is the only one that does interpret MSIL
Also Microsoft .NET JIT compilers, with the exception of the .NET Micro Framework always jit the code, there is no threshold to trigger it like on most JVMs.
Python is interpreted in what was its most popular form, but may not be now, CPython.
This is using the definition of a JIT as an execution engine which takes in some form of bytecode and, at runtime, emits architecture-specific assembly code to a page, marks that page executable, and changes the IP to that page.
If CPython executes in that manner then I'm mistaken about CPython's execution engine and would also consider CPython to be a JIT.