[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Ruby Weekly News 21st - 27th March 2005
From:       gabriele renzi <surrender_it () remove-yahoo ! it>
Date:       2005-03-31 22:09:46
Message-ID: Us_2e.38932$zZ1.1154064 () twister1 ! libero ! it
[Download RAW message or body]

Brian Candler ha scritto:

please excuse me if my questions are dumb..

> But perhaps also:
> 
> - The Ruby source code will be bigger and slower to build

Sorry, I'm not sure I grok this: it could be probably slower to build, 
but why should it become bigger?

> - Scripts will be slower to start up

I think the process of compiling ruby in bytecode is quite fast. At 
least, I could not notice the slowdown when running scripts with yarv.

> - Ruby applications may be less reliable initially and/or harder to debug

why? Is Squeak harder to debug since it's written in 
Smalltalk-subset-compilable-in-c ?

> - Ruby may run on fewer platforms [especially if the VM writes machine-code
>   directly, or has dependencies on external C compilers, linkers etc]

well, the 'main' yarv can use direct threading when compiled with gcc 
wich is available almost everywhere, but it seem to run faster than 
currwent ruby even if compiled withouth it.
OTOH, I think AOT compiling can tuned as to work with any C compiler as 
a backend, I don't think there is a real problem with it, though IANAVG[1]
And, on even another hand, many compilers scream when compiling the 
current cvs with warnings enabled, but people feel happy anyway :)


> One of the big advantages of Ruby for me is that it's one-third of the size
> of Perl, whilst still being much more feature-complete (e.g. I get OpenSSL,
> MD5 and base64 encoding without having to install additional libraries)

Yup, but why would this become worst with a new vm, since it already 
supports the standard ruby dynamic libraries?




[1]I Am Not A Vm Guru

[prev in list] [next in list] [prev in thread] [next in thread]