Live data from Hacker News

Why I switched from Ruby back to C++

chrismdp.github.com

11–20 of 100 posts

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

#11
post #2

I'd be interested in HNers' views on whether I made the right call.

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 your standard scripting language perks, but it's also obnoxiously fast and has an incremental garbage collector. Furthermore, there's no GIL, and it's designed to be embeddable, making it a very powerful choice for game development.

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

#12

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.

Sounds like he's wanting to use a lot of native C++ libraries, so I imagine he'd still run into performance problems even if he found a way to use JNI with JRuby.

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

#14
post #8

Nice write up. I wrote my own 2d game engine in C++ a while back. Switching to Ruby was great, but I never made any games. I did make a couple of JavaScript HTML 5 games. But here again speed is a limitation, and so am looking into C (and eventually Objective C) to eventually do some iPhone game making. As great as it would be to make games soley with scripting/interpreted languages, I don't think we're there yet.

Easy porting to iPhone in the future is another big plus I should have mentioned in the original post.

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 surprised at how good a fit ObjC is for a game engine you prototyped in Ruby, as opposed to C++.

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

#15
post #11
post #2

I'd be interested in HNers' views on whether I made the right call.

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.

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

#16
post #2

I'd be interested in HNers' views on whether I made the right call.

Writing everything in C++ is not my idea of fun. It's definitely possible to write almost all of the game code in a scripting language. It would be reasonably easy to abstract all the native APIs you want, but you could also just let someone else do it: http://love2d.org/

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

#17
post #2

I'd be interested in HNers' views on whether I made the right call.

ruby excels where time to market and RAD are more important than performance, and where the standard and other libraries work well. Ruby saves lots of time doing things like CRUD operations where you're basically mapping on set of fields to another in a predictable way. When performance and memory are an issue and you can't trivially scale your code (eg. More processes or more machines) C++ is a big win.

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

#18
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.

Just because the Lua community will ream you out for the mistake (though it's the only thing they're mean about), it's "Lua" (Portuguese for "moon"), not an acronym. :)

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

#19
post #11
post #2

I'd be interested in HNers' views on whether I made the right call.

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).

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

#20
post #14
post #8

Earlier quoted context omitted.

Easy porting to iPhone in the future is another big plus I should have mentioned in the original post.

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
Post reply on HN