3 ms·
> it is kind of obvious that a compiled language is going to be faster than an interpreted one While it may be obvious, the interesting question is why exactly
by rakoo 13y ago
> it is kind of obvious that a compiled language is going to be faster than an interpreted one
While it may be obvious, the interesting question is why exactly. There's been a good presentation from Alex Gaynor [0] on this topic. TL;DR: Dynamic languages ar slow not because they can't be optimized, but because developers make a worse use of memory and have sucky algorithms, inducing way more mem allocation and copy than needed. If you can be smart about those, then your dynamic language can match static languages.
[0] https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
- leccine 13y agoThere are certain things that you can't really avoid using an interpreted language. How would you go around Ruby's GIL for example when you specifically need multiple threads (not talking about green threads). I agree that some of the stuff is on the developers developing libraries and performance is not kept in mind but there are hard limits you can't really do anything about.
- pjmlp 13y agoJRuby, RubyMotion
- dragonwriter 13y ago> How would you go around Ruby's GIL for example when you specifically need multiple threads (not talking about green threads). Using any of the Ruby implementations that don't have a GIL. Notably, JRuby, MacRuby/RubyMotion, and (I think) Rubinius.
- steveklabnik 13y agoRubinius does not have a GIL, you are correct.