Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Topaz: A New Ruby

docs.topazruby.com

Post reply on HN
Print view View original

41–50 of 190 posts

Re: Announcing Topaz: A New Ruby

#41

Post by llimllib »

fusiongyro wrote: post #21
fijal wrote: post #18

Earlier quoted context omitted.

PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences: * RPython comes with a good garbage collector * the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit. * RPython comes with a set of data structures t…

Do you know what an analogy is?

There's no need to be a jerk.

Re: Announcing Topaz: A New Ruby

#42

Post by fijal »

fusiongyro wrote: post #21
fijal wrote: post #18

Earlier quoted context omitted.

PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences: * RPython comes with a good garbage collector * the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit. * RPython comes with a set of data structures t…

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"?

Re: Announcing Topaz: A New Ruby

#43

Post by drivebyacct2 »

fusiongyro wrote: post #21
fijal wrote: post #18

Earlier quoted context omitted.

PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences: * RPython comes with a good garbage collector * the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit. * RPython comes with a set of data structures t…

Do you know what an analogy is?

I do, but I also appreciate further distinction between pypy and llvm in this context.

Re: Announcing Topaz: A New Ruby

#44

Post by Argorak »

rmoriz wrote: post #16
Argorak wrote: post #5

Earlier quoted context omitted.

Its implemented on top of RPython, which is something completely different then Python, the runtime.

No it's not. Technically speaking yes, but without Python there would be no RPython. In other words you're betting on three language/vm communities: Ruby language, Python (RPython!), LLVM (iirc). I don't believe introducing a lot more dependencies and complexities will cure any problem. Sure, it's a nice project and the work shows the great skills of the developer. But it's not practical to use this besides some non-…

Yes, but betting on Python is the whole point of PyPy. The idea is to build a toolchain using a relatively high-level programming language like RPython to build new languages.

As far as I understood is that this allows for low-level concepts to be changed more easily, while low-level implementations always suffer from basic decisions (e.g. you will never get reference-counting out of CPython, while you might be free in to change that in an RPython-implemented language).

So, the entire point of PyPy is being able to implement other high-level languages in RPython, so an attempt to implement Ruby is definitely very interesting! Also, the resulting binary is not depending on Python whatsoever.

Re: Announcing Topaz: A New Ruby

#45

Post by fijal »

knowtheory wrote: post #17
nlh wrote: 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.

So that would be a very cool project to merge python ruby (or any other interpreter written in RPython). It requires quite a bit of work to pull it off the ground though. I would be happy to provide guidance on that, but I definitely won't do it myself (just yet).

Re: Announcing Topaz: A New Ruby

#46

Post by knowtheory »

llimllib wrote: post #41
fusiongyro wrote: post #21

Earlier quoted context omitted.

Do you know what an analogy is?

There's no need to be a jerk.

Yeah, although there may be other ways to phrase your admonishment which people will be more receptive to.

"C'mon dude, don't let flaming beget flaming."

Re: Announcing Topaz: A New Ruby

#47

Post by andrewaylett »

rmoriz wrote: post #16
Argorak wrote: post #5

Earlier quoted context omitted.

Its implemented on top of RPython, which is something completely different then Python, the runtime.

No it's not. Technically speaking yes, but without Python there would be no RPython. In other words you're betting on three language/vm communities: Ruby language, Python (RPython!), LLVM (iirc). I don't believe introducing a lot more dependencies and complexities will cure any problem. Sure, it's a nice project and the work shows the great skills of the developer. But it's not practical to use this besides some non-…

That's not really rebutting the GP's point, though, which is that despite using a Python-derived language, we're not running Topaz on top of a Python runtime.

Re: Announcing Topaz: A New Ruby

#48

Post by andrewaylett »

eranation wrote: post #24
Pewpewarrows wrote: post #10

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

Impressive, how does it compare to JRuby?

That's probably not a fair test to use on JRuby, as the JVM is notoriously slow to start.

Re: Announcing Topaz: A New Ruby

#49

Post by llimllib »

vidarh wrote: post #34

I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation. It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes…

1) Note that the post doesn't sell its speed; all it says is that they are interested in a high-performance Ruby

2) Python is a very similar language to Ruby, and Pypy already runs python very rapidly. This doesn't guarantee that the Ruby interpreter will be anywhere near as fast, of course, but it does give evidence that it's possible.

3) As kingkilr notes below, they've taken into account your argument and they believe they've implemented enough of the language to be confident that they can run it rapidly. No reason you need to believe him, but it's worth listening to.

Post reply on HN