Hacker News Reader

Comment by fidotron | Hacker News Reader

Intriguing. I'm not aware of much, if any, interest in Go in the games community, but there we are. C# seems to have finally taken off big time.

What would be cool/interesting is if you can write half decent audio processing code in Go for Android without the GC kicking in at the wrong moment.

They're 100% right about the broader API though.

View on HN

Go might be a good fit for game servers, but it seems like a completely uninteresting choice for game clients. I'd imagine game developers would either want to continue to work in C++ and leverage their existing skills and code bases or use a high level engine like Unity. The potential market for this seems quite small.

I'd really love to see Google throw some serious engineering muscle behind Rust, with the long-term goal of making it the default first-choice language for Android development. I'm not holding my breath for this though.

The design of Swift was somewhat hobbled by ObjC/Cocoa legacy requirements but it's still much better language for native client development than Java, IMO. Sooner or later Google is going to need a better story here.

Having written a bit of Rust, I'm not sure it's suited to being the default language for any platform, simply because it's really hard; it forces you to plan the lifetimes of your data pretty carefully. If you don't actually need all the guarantees and performance Rust gives, it's quite possibly a better idea to go with a managed language. Not that I wouldn't like to see it be a first-class option, just not the first one you point the masses at.

I'd be happy to be convinced otherwise by someone who knows more. :)

It is still way easier than using languages with manual memory management like C and Pascal derivatives.

Since you are not forced to think about lifetimes, then you get memory leaks, double frees and dangling pointers, usually leading to crashes in totally unrelated locations or worse, security exploits.

Um, right. I did suggest a managed language as an alternative.

Yeah right, but for me managed is a term coined by Microsoft as .NET was introduced.

Any language with automatic memory management, be it via dataflow analysis, RC or GC is managed.

I'm surprised C# is gaining this much traction in the games community despite the complete abandonment of both XNA and Managed DirectX by Microsoft.

C# lets you develop games that run on Windows, OsX, Linux, Android, iOS, Windows Phone, Xbox and PS, while sharing all non-UI and parts of the UI code.

I think this is 90% a result of Unity.

Let's hope Unity will support Rust, too, then...and I guess Go now as well, if Google says they want it for games.

They don't even support the latest version of C#.

Would they have to be ported to Mono to be used for Unity?

Likely not - C# seems here to stay on Unity3D, but speeding up execution through tools like IL2CPP seem most likely.

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

Unity only supports managed code unless you have Unity Pro, and its not clear to me how well you can use other languages; I think the support may be more for middleware libraries and such.

It's the best modern language overall (if you count everything: IDE, APIs, language design, cross-platform capability, capital backing, reach, approachability).

Also XNA is reborn as MonoGame. Microsoft wants to decouple from it's APIs and tools by offloading to OSS and third party (Unity3d).

Good desktop integration alongside P/Invoke, meant many game studios started moving their game building tools from C++/Qt/MFC to C#/Windows Forms/WPF.

So this way C# got a foot on the door, long before XNA and Managed Direct X came into the picture.

Go is interesting for game servers. Channels and selects are the shiznit! Not there yet, but has potential. Rust has even more potential.

We've moved pieces of our game backend architecture from Python to Go, especially the bits that really benefit from high concurrency and possible parallelism. Moving the entire API is a monolithic task, but I imagine we'll eventually get there. But carving out the bits that need high speed, high concurrency (like sending 500 GCM notifications a second, for instance) really thrive.

Our client dev is all Unity, however, and I don't quite see Go entering our client dev cycle at all. And I'm a huge Go fan.

As a game developer I would be intrested in this. I would love to have my client and server code in the same language so I would not have to write things twice.

Having said that, I'm not at all interested in writing an app that was Android only so I'll be sticking with javaScript for a while yet.

Reply on news.ycombinator.com