Live data from Hacker News

Why I switched from Ruby back to C++

chrismdp.github.com

21–30 of 100 posts

Re: Why I switched from Ruby back to C++

#22
post #20
post #14

Earlier quoted context omitted.

The ObjC object model is very similar to Ruby's object model. ObjC's way of handling mundane data structures (strings, arrays, hashes) is (once you learn to stop worrying and love long sequences of calls to very long method names) very similar to how Ruby addresses the same problems. ObjC lets you drop into vanilla C code when you want to. ObjC doesn't impose GC. ObjC implements a form of duck typing. You might be su…

ObjC++ might be an even better fit

I always got a "stay on the golden path and away from ObjC++" vibe from ObjC++, kind of like trying to ask Rails to do database stuff without using ActiveRecord in 2008.

You can easily write C++ code without having to bridge ObjC's object system to C++'s object-and-generics system: provide a simple C API to your C++ libraries.

But the other thing is, one reason to do ObjC at all is to avoid all the heartache that comes bundled with C++.

PS: You got modded down. Baffling. Fixed.

Re: Why I switched from Ruby back to C++

#24
post #9

I wonder if switching to JRuby wouldn't have solved some of his problems? I'd imagine that distribution is much easier on JRuby. I suppose the issue is with libraries, but I'm not familiar with the libraries he mentioned.

Possibly, but I'm much more comfortable in C++ than Java. I also get a much easier route to iOS if I stick with C++.

With JRuby, you wouldn't have to be comfortable with Java. You get to use Ruby with the benefit of it running in the JVM.

Re: Why I switched from Ruby back to C++

#26
post #11

Earlier quoted context omitted.

Speaking as a huge fan of Ruby, I think it's absolutely the wrong language to write games in, because games are enormously sensitive to runtime fluctuations, and as you found out, Ruby has them. In particular, a stop-the-world GC is just never going to give you satisfactory performance, unless every GC pass happens in That said, you might consider Lua as a primary scripting engine for your game. It's got a lot of you…

Usually the way you solve GC issues is by either not allocating after some initial massive allocation, or by running the GC constantly and having it clean up bits and peices every frame. I don't know enough about ruby to know if this is possible but this is how you handle GC in Java and C#. As for Lua, Garry's mod runs almost entirely in Lua (outside of the source engine).

You can run GC manually in Ruby, but at the end of the day, it's a stop-the-world GC; your program doesn't get to do anything until it decides that it's finished. If that takes too long, you drop that frame. Additionally, Ruby doesn't have the concept of primitives (mostly), and all objects are stored on the heap! So, every time you use a float (which you do a lot of in games), you end up with a new struct on the heap that has to be garbage collected eventually. Ouch.

(By way of demonstration:)

    ree-1.8.7-2011.03 :002 > 123.456.object_id
     => 33681660
    ree-1.8.7-2011.03 :003 > 123.456.object_id
     => 33674740
Languages with incremental GCs will yield between phases of the GC pass, letting program execution continue even when a GC pass is in progress, making sure that you don't end up with dropped frames, which vastly improves the player experience.

Re: Why I switched from Ruby back to C++

#28
post #11

Earlier quoted context omitted.

Speaking as a huge fan of Ruby, I think it's absolutely the wrong language to write games in, because games are enormously sensitive to runtime fluctuations, and as you found out, Ruby has them. In particular, a stop-the-world GC is just never going to give you satisfactory performance, unless every GC pass happens in That said, you might consider Lua as a primary scripting engine for your game. It's got a lot of you…

I'll look into LUA. Never used it back in my games dev days as it was just coming into vogue.

The cause of its popularity in the games community comes from the fact that it is, by design, meant to be embedded in larger programs. So, for example, it will compile on any platform with a conforming ANSI C compiler.

And for x86/x64 and ARM, you can try LuaJIT to get even more zing (though you probably won't need to).

Re: Why I switched from Ruby back to C++

#29
This post should be titled, "Why I fucked up by choosing Ruby to write a game." - Or "What the fuck was I thinking"

I love Ruby, I spend a lot of time writing it. I also write kids games for iOS. I would never consider Ruby(in it's current state) a good language to write a game in. Anyone who would has clearly; never written a game before; or never used Ruby for anything serious before.

I agree with the other posters, you should investigate ObjectiveC though. You can get ObjectiveC packaged and running on Windows BTW, don't worry about that.

Re: Why I switched from Ruby back to C++

#30
post #23

This sounds very "link bait-ish"… Why were you trying to write a game in Ruby to start with? You didn't "switch back to C++", you simply realized you were trying to use a wrench to tight a philips screw… -.-

I suppose it does: but it's the honest truth. I have two months of ruby code that's rusting now, and it was quite a difficult post to write.
Post reply on HN