4 ms·

I would like to read an actual in-depth comparison. While undeniably the quality of the Ruby implementation has a long way to go, Ruby has very "loose" semantic

by stiff 13y ago

I would like to read an actual in-depth comparison. While undeniably the quality of the Ruby implementation has a long way to go, Ruby has very "loose" semantics and I think some of the optimizations that are possible for Java, JavaScript or even for Smalltalk are simply not possible for Ruby because you have less assumptions to rely upon, everything has to be looked up at runtime basically. Besides just nitty-gritty optimizations there are some high level design issues which are interesting. JVM performance is great for languages like Java, but for some reason probably related to the JVM all Java web servers seem to be multi-threaded monsters, which turns debugging into a mess and seems to make DoS attacks way easier. We use a self-hosted Jira on top of Tomcat at work, there are maybe 30 simultaneous users and every time one of them does something computationally expensive or uses some buggy functionality the whole process goes nuts, memory leaks until exhaustion, load goes to maximum etc., the whole web sever has to be restarted. With a web server with multiple worker processes you just restart the single worker and call it a day. Does anyone happen to know why the worker-based hosting model with separate worker processes seems to be completely absent from the Java world in favour of multi-threaded servers?

pjmlp 13y ago
I fail to see how Ruby is more dynamic than Smalltalk as I am not aware of any Ruby dynamic feature not present in Smalltalk as well. Are you aware that Hotspot was born as a Smalltalk (StrongTalk actually) JIT compiler?
- stiff 13y ago
  I don't know Smalltalk well enough to say for sure, it's just my rather vague impression that Smalltalk is more compiler-friendly, likely based mostly on what I've read over the years about this, for example looking at: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606 Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes. In Ruby, it is practical and somewhat useful to add methods dynamically; in Smalltalk, the practice is generally to treat the methods and classes as static. Have also a look at: http://www.hokstad.com/the-problem-with-compiling-ruby http://www.hokstad.com/the-problem-with-compiling-ruby I don't think all those 5 problems apply equally well to Smalltalk, do they?
  - nikbackm 13y ago
    Seems to me they would apply to Javascript though, and that got quite fast with V8.
    - dragonwriter 13y ago
      Being the one widely supported client-side language for the web means that lots more money has been poured into making JavaScript implementations effective than has gone into Ruby (I wouldn't be surprised if Google put more resources into V8 than have gone into all Ruby implementations combined.)
      - danneu 13y ago
        For example, Lars Bak (virtual machine master) is the head programmer of V8. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
      - nikbackm 13y ago
        True, but since V8 is open-source, shouldn't it now be possible for the Ruby developers to borrow the techniques from it that made Javascript so much faster?
        dragonwriter 13y ago
        Ruby isn't JavaScript. Studying V8's solutions to particular problems with making JavaScript efficient may help people seeking to make an efficient Ruby implementation, but how much is easily transferrable I don't know.
        vidarh 13y ago
        None of the techniques that's gone into V8 are all that novel. Most of them - at least the ones that are relevant to Ruby - stems from research around Smalltalk and Self that's been well known for a very long time. The hard/time consuming part is implementing them.
    - 13y ago
- riffraff 13y ago
  I seem to remember a discussions about this a decade ago, with smalltalkers saying that the only big difference is that programmatic generation of code is not so common in ST as it is in ruby (i.e. "attr_*" is possible in ST but doesn't actually exist). Other than that I _think_ maybe ST has a fixed number of slots per class compared to dynamically added instance/class variables in ruby? My memory is fuzzy. By the way, there _is_ a ruby built by smalltalk developers[0] exactly because the object model is 99% the same. [0] http://maglev.github.io http://maglev.github.io

by stiff 13y ago

pjmlp 13y ago

I fail to see how Ruby is more dynamic than Smalltalk as I am not aware of any Ruby dynamic feature not present in Smalltalk as well. Are you aware that Hotspot was born as a Smalltalk (StrongTalk actually) JIT compiler?

stiff 13y ago
I don't know Smalltalk well enough to say for sure, it's just my rather vague impression that Smalltalk is more compiler-friendly, likely based mostly on what I've read over the years about this, for example looking at: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606 Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes. In Ruby, it is practical and somewhat useful to add methods dynamically; in Smalltalk, the practice is generally to treat the methods and classes as static. Have also a look at: http://www.hokstad.com/the-problem-with-compiling-ruby http://www.hokstad.com/the-problem-with-compiling-ruby I don't think all those 5 problems apply equally well to Smalltalk, do they?
- nikbackm 13y ago
  Seems to me they would apply to Javascript though, and that got quite fast with V8.
  - dragonwriter 13y ago
    Being the one widely supported client-side language for the web means that lots more money has been poured into making JavaScript implementations effective than has gone into Ruby (I wouldn't be surprised if Google put more resources into V8 than have gone into all Ruby implementations combined.)
    - danneu 13y ago
      For example, Lars Bak (virtual machine master) is the head programmer of V8. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
    - nikbackm 13y ago
      True, but since V8 is open-source, shouldn't it now be possible for the Ruby developers to borrow the techniques from it that made Javascript so much faster?
      - dragonwriter 13y ago
        Ruby isn't JavaScript. Studying V8's solutions to particular problems with making JavaScript efficient may help people seeking to make an efficient Ruby implementation, but how much is easily transferrable I don't know.
      - vidarh 13y ago
        None of the techniques that's gone into V8 are all that novel. Most of them - at least the ones that are relevant to Ruby - stems from research around Smalltalk and Self that's been well known for a very long time. The hard/time consuming part is implementing them.
  - 13y ago
riffraff 13y ago
I seem to remember a discussions about this a decade ago, with smalltalkers saying that the only big difference is that programmatic generation of code is not so common in ST as it is in ruby (i.e. "attr_*" is possible in ST but doesn't actually exist). Other than that I _think_ maybe ST has a fixed number of slots per class compared to dynamically added instance/class variables in ruby? My memory is fuzzy. By the way, there _is_ a ruby built by smalltalk developers[0] exactly because the object model is 99% the same. [0] http://maglev.github.io http://maglev.github.io