Live data from Hacker News

Announcing Topaz: A New Ruby

docs.topazruby.com

51–60 of 190 posts

Re: Announcing Topaz: A New Ruby

#51
post #42

Earlier quoted context omitted.

Do you know what an analogy is?

I'm actually not a native speaker, so indeed, I might not know. I checked in the dictionary though. This is an analogy, but not a very good analogy, because of the reasons that I pointed out. Are you disagreeing with any particular reasoning there? Or should I just say "they're similary, but"?

Well, so you're right and you're wrong.

You're right that the analogy doesn't quite capture everything here. On the other hand the analogy gets across most of the point.

I would have said "That's mostly right, but the interesting thing about sharing code on a VM is access to VM features and code shared on the platform, not just that it's possible to decouple a front end from a VM."

or something to that effect.

Re: Announcing Topaz: A New Ruby

#52

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s

[deleted]

Re: Announcing Topaz: A New Ruby

#53
post #4

Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.

So, lets talk about JRuby. JRuby is a Ruby implementation on the JVM, and its really awesome power is actually that you can wrap and interface with Java libraries, and still write all of your app code in Ruby. If Topaz was able to give me the ability to access NLTK, but still write in Ruby? I'd be overjoyed.

> If Topaz was able to give me the ability to access NLTK

I doubt that's going to happen. Topaz is not a Ruby running on the CPython interpreter, the Topaz VM is developed in RPython. As far as I know, RPython doesn't provide that capability either (between VMs coded in RPython), which fijal seems to confirm.

Re: Announcing Topaz: A New Ruby

#55
post #2

Why not implemented on Erlang OTP? Ruby and Python share the same scaling issues, so I don't see a benefit it combining them or migrate from one to the other. I also dislike the "high performance" claims without showing a single performance comparison. Not to mention the state of implementation completeness of the language.

Build an Erlang backend for PyPy. Should be doable, but what benefits would it bring?

Re: Announcing Topaz: A New Ruby

#56

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s

Try comparing with Rubinius

Re: Announcing Topaz: A New Ruby

#57
post #52

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s

[deleted]

the idea was to implement enough of "hard stuff". So it should not change. but hello world is not a good idea (this one also might actually change due to library loading, but please don't benchmark it like that)

Re: Announcing Topaz: A New Ruby

#58
post #20

So Ruby on top of RPython on top of PyPy? Why not, but how does it compare to JRuby and Rubinius?

> So Ruby on top of RPython on top of PyPy?

No. It's Ruby in RPython, where PyPy is Python in RPython. The pypy project is currently in the process of splitting "RPython" (the VM-development framework) from PyPy (the Python VM) to make that clearer.

RPython is a general purpose, language-agnostic (ish?) core for implementing JIT-ed garbage-collected languages, it's kind-of similar to LLVM being a framework for implementing compilers.

(now because rpython is a proper subset of python you can run your rpython VM on a python interpreter without translation, but that doesn't give you any specific python bridge, in the same way coding your VM in C doesn't give you a c FFI for free)

Re: Announcing Topaz: A New Ruby

#59

RPython is the new C?

In addition to fijal's comment: I also heard somewhere that RPython is a) not strictly specified and b) may change when needed without notice. So I would stay clear of it. :)

we removed that from the docs, it's kinda stable by now (but it's still an atrocious language to use, just beats C/C++ for that particular task by a lot)

Re: Announcing Topaz: A New Ruby

#60
post #57
post #52

Earlier quoted context omitted.

[deleted]

the idea was to implement enough of "hard stuff". So it should not change. but hello world is not a good idea (this one also might actually change due to library loading, but please don't benchmark it like that)

Makes sense. I wasn't claiming any "absolute" benchmark, of course, just pointing out that real benchmarks should wait until the implementation is more complete.
Post reply on HN