Hacker News new | comments | ask | show | jobs | submit login

It is really fun to see games coded in a language you know (and is not used for gamedev) -- completely new way of programming/thinking.

There is another great video similar to this of Tom Dalling coding a flappy bird clone using Gosu:


That is how C and Pascal got to displace Assembly, and C++ eventually displaced C in game development.

By having devs that instead of following "it cannot be done", persisted and eventually were able to release something in those languages that others wanted to play.

Having watched this cycle a few times, I always look forward to see higher level programming languages used in broader contexts.

However for game development, maybe Crystal instead of Ruby would still be a better option, in terms of raw performance and distribution.

considering rubymotion, i think ruby is still a feasible option though

RubyMotion support for Ruby/Gosu is on the way too (it does not work automatically): https://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=1194

RubyMotion just badly needs a .NET/IronRuby port, or anything else that'll work well on Windows... :(

Yes, assuming something similar ever becomes available outside the Apple world. AFAIK they only focus on those systems.

But yeah, I imagine compiling Ruby is not much dissimilar than compiling Dylan.

I don't know Dylan, but compiling Ruby is a nightmare. As such it's also a fun challenge (working on "as static as possible" Ruby compiler).

Actually, compiling Ruby is not that bad, horrible grammar (from the perspective of having to write a parser - as a user o the language I like it) notwithstanding.

Compiling Ruby into efficient code is a nightmare.

The problem is largely that there's a total lack of delineation of application read/load time and runtime, coupled with the ease of being able to mutate the object model.

E.g. in theory on return from any method statement the entire world might have been transformed. 2 + 2 = 4 one moment, only for 2 + 2 to have side effects and return 5 the next...

The "quick and dirty" way of compiling Ruby is to accept that you'll need expensive dynamic message call invocations all over the place.

Optimizing beyond that is a lot of work to ensure you can handle it when people start playing silly games. The jRuby Truffle backend is probably the best bet at the moment (Chris Seaton who did the initial work on that is on HN). If I ever get that far with mine, I'll be stealing lots of ideas fro there...

Dylan is a Lisp with Algol like syntax targeted for systems programming with a REPL, AOT compiler and IDE like environment.

So what you are telling about Ruby is also an issue in Dylan, given its Lisp heritage and flexibility.

looks awesome, thanks for the link!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact