Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Doesn't seem like there is any fundamental reason for Ruby to run slower.

I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.



> I think that all the metaprogramming magic that Ruby allows is at odds with speed.

I don't think so, Java and C# also have metaprogramming (reflection, class loading, bytecode manipulation) and they are still plenty fast.

Ruby's liability is that it's dynamically typed, and this puts a hard limit on how fast it can be (and also on how toolable it can be, but that's a separate discussion).


Reflection in Java is in fact slow. The difference is that in ruby that stuff is pervasive, in Java you rarely use reflection.


Reflection is also very slow in C#


Not it is not. A lot of basic metadata is cached and quickly accessible.


How much metaprogramming is normally going on behind the scenes in a typical Ruby/Rails app vs Java or C# though?

If you do a lot of reflection in Java then you'll end up with some pretty crummy performance, but the average Java program doesn't have much.


It's not just the actual metaprogramming, i.e. define_method is slow. It's also the runtime implications of metaprogramming being possible, i.e. needing to dispatch each and every method call dynamically just in case someone called define_method. Java can turn every method call into a function pointer at compile time.


Metaprogramming is code using define_method (optionally closing over local variables), instance_eval, and stuff of that nature. Even with bytecode manipulation they would be very difficult to emulate in Java/C++ and would be quite slow.

That said, JavaScript is not far off of Ruby's monkeying capabilities and yet pretty darned fast.


I mean metaprogramming support is kind of a spectrum and neither Java nor C# support it to the same degree as Ruby. For one thing and for another, C# and Java have large corporations supporting those languages which try very hard to make the runtimes fast so it's not a fair comparison.


Then compare it with compilers for dynamic languages like Lisp, Scheme, Dylan, Smalltalk...


I said tricky, not impossible but I will, even though I'm not sure I'm really qualified to talk about these languages for one thing and for another, I think that these sort of comparisons are pretty pointless to begin with. Also I'm not sure where you are exactly going with your comment.

Lisp + Scheme: I mean if nothing else, people have been trying to make them fast for the last more than half of century. Plus AFAIK most Lisp meta-programming code is generated during compile time through macros not during run-time.

Dylan: I don't really know anything about Dylan but it seems to have come out of Apple and CMU, so there's that. Plus it seems to be just a Lisp dialect.

Smalltalk: You consider Smalltalk fast? Lol.


>Smalltalk: You consider Smalltalk fast? Lol.

Well, any Smalltalk JIT beat the standard Ruby implementation hands down, what can I say?!


>I think that all the metaprogramming magic that Ruby allows is at odds with speed

Well, Javascript allows almost as much metaprogramming (and with ES6 proxies and such, exactly as much).


a.) Unless, you use eval profusely, it really does not. I'm not sure how much metaprogramming power proxies really give you.

b.) It also has Google pumping a LOT of resources into making it fast.


That doesn't seem right. Can you give an example? I use lots of js metaprogramming, but it mostly involves wrapping and passing functions, mixing in methods and dynamic getters etc. I don't think I've ever actually had to use eval, or anything eval-like.

OTOH, grep for instance_eval and class_eval in rails source.


Right, you should never ever use eval but I don't think that a lot of the things that are commonly done in Ruby could be achieved in JS without eval. And what you are talking about is not exactly meta-programming.

> OTOH, grep for instance_eval and class_eval in rails source.

I mean what's your point. Yes, I realize that both are used profusely, which is one of the things that this discussion is about.


> And what you are talking about is not exactly meta-programming.

I didn't describe metaprogramming, just how I usually see common metaprogramming "magic" implemented in javascript. The only reason you'd really need eval in js metaprogramming is if for some semantic reason it was nicer to accept a String of javascript somewhere. Afaik eval doesn't "get" you anything in javascript (it doesn't "unlock" private closures scope or anything, and context-injection is available using #call or #apply) and I almost never see it used, unless I am forgetting something (totally possible, I've been up all night)

> I mean what's your point. Yes, I realize that both are used profusely

My point is I don't see eval used profusely in javascript, which contradicts your assertion in a).

Edit: nvm, I stand corrected: (function(){var x = 1; eval('console.log(x)'); })() prints 1. Neat. But still, I do not see this often used, the callback + context passing approach is much more common.




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

Search: