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

Opal: Ruby to JavaScript Compiler

opalrb.org

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Opal: Ruby to JavaScript Compiler

#61

Post by aikah »

dragonwriter wrote: post #41
aikah wrote: post #31

Earlier quoted context omitted.

my point was it doesnt transpile Ruby to Javascript.

It does, though; it just doesn't expose things that are exposed in the underlying JS environment to Ruby code without jumping through certain hoops. Which makes sense, because unlike CS, which is tied to the underlying JS environment, Ruby isn't, and exposing the underlying JS environment would make it harder to port general-purpose Ruby code as you'd be more likely to run into collisions with the JS environment that…

My use case was an online IDE where instead of using javascript to code webapps,users would use Ruby to do the same.But since opal doesnt expose window object,it's pretty useless for me. Maybe you have a solution for that,but I just didnt find one.

Re: Opal: Ruby to JavaScript Compiler

#62

Post by Yoric »

Argorak wrote: post #19
Yoric wrote: post #14

The name is a bit awkward, given the existence of Opalang, which is another $SomeLanguage to JavaScript compiler.

Given that Opal.rb was started in 2010 and Opalang (back then called opages) in 2010 as well, I would file that under "unfortunate". https://github.com/opal/opal/commits/master?page=107 https://github.com/MLstate/opalang/commits/master?page=126

I don't remember when Opalang was started, but I joined the project in 2008 :) Fwiw, back then the name was Opa. Opages was the name of the CMS written in Opa/Opalang.

Funnily, Opa and Ur/Web were two projects started around the same time and sharing very similar ideas, and they also collided linguistically – in German, Opa == grand-dad, while Ur == ancestor.

Anyway, have fun with Opal.rb :)

Re: Opal: Ruby to JavaScript Compiler

#63

Post by dragonwriter »

aikah wrote: post #61
dragonwriter wrote: post #41

Earlier quoted context omitted.

It does, though; it just doesn't expose things that are exposed in the underlying JS environment to Ruby code without jumping through certain hoops. Which makes sense, because unlike CS, which is tied to the underlying JS environment, Ruby isn't, and exposing the underlying JS environment would make it harder to port general-purpose Ruby code as you'd be more likely to run into collisions with the JS environment that…

My use case was an online IDE where instead of using javascript to code webapps,users would use Ruby to do the same.But since opal doesnt expose window object,it's pretty useless for me. Maybe you have a solution for that,but I just didnt find one.

Exposing the window object is a different issue than being a transpired and, in any case, you can access the underlying KS environment in Opal, including fairly simple access to things like the window object.http://opalrb.org/docs/interacting_with_javascript/

Re: Opal: Ruby to JavaScript Compiler

#64

Post by rapind »

azakai wrote: post #57
munificent wrote: post #54

Earlier quoted context omitted.

> You can compile a Ruby VM from C to JS, as people have done. That sounds to me like it would just kill your startup perf. Users would have to download an entire Ruby VM every time they hit your site, wouldn't they? Maybe I'm just a luddite, but spending network resources downloading a garbage collector written in JS only so that I can run it in JS... which natively supports GC just seems really gross to me. Don't g…

I see your point, but don't think it is quite as bad as that. For one thing, it would be cached etc., so it is about as bad as every site on the web using jQuery (that is, not great, but not horrible either). Yes, it seems ironic to download a GC written in JS, when JS can do GC. But JS can only do SOME types of GC. For example, it lacks destructor callbacks, which things like Lua require. Some other language might n…

While convoluted, I believe this results in some pretty fast js. mruby -> llvm -> emscripten -> asm.js

See: http://vimeo.com/70673036

Re: Opal: Ruby to JavaScript Compiler

#65

Post by Argorak »

Yoric wrote: post #62
Argorak wrote: post #19

Earlier quoted context omitted.

Given that Opal.rb was started in 2010 and Opalang (back then called opages) in 2010 as well, I would file that under "unfortunate". https://github.com/opal/opal/commits/master?page=107 https://github.com/MLstate/opalang/commits/master?page=126

I don't remember when Opalang was started, but I joined the project in 2008 :) Fwiw, back then the name was Opa. Opages was the name of the CMS written in Opa/Opalang. Funnily, Opa and Ur/Web were two projects started around the same time and sharing very similar ideas, and they also collided linguistically – in German, Opa == grand-dad, while Ur == ancestor. Anyway, have fun with Opal.rb :)

Thanks a lot for clearing that up (also, my post misses a "?" after opapages)!

Re: Opal: Ruby to JavaScript Compiler

#66

Post by mraleph »

azakai wrote: post #49
munificent wrote: post #44

I'm going to use this as a little example of why compiling to JS is hard. I work on the Dart team, and people often ask what the big deal about JS compilation is. Opal's compiler is a good example of why it can be hard. I want to stress, though, that I'm not singling Opal out here. I think Opal is a really cool project, and I hope it works well for lots of people. It's just a good example language since it's on HN ri…

Not necessarily. You can compile a Ruby VM from C to JS, as people have done. That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). Things get more complicated if your VM has a JIT, but there are interesting results even there, see pypy.js. This approach lets you have arbitrary semantics, even ones that differ hugely from JavaScript, with dece…

> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort).

You are comparing different ratios: munificent was comparing against JS and your "2 times" prediction is against native performance of the compiled VM.

> there are interesting results even there, see pypy.js.

Yes, the most interesting result is that you have to warm up pypy.js with a blow torch, otherwise performance is abysmal.

> I think that approach could work for Dart as well.

Have you seen people complaining about size of dart2js output? Can you imagine how big emscripten output would be?

I have been arguing that dart2js could have been using hand-written JIT compiler on the client side, but the startup performance compared to AOT would really be a big deal. I think a combination of AOT and JIT would be the best, but sadly it is also true that JavaScript lacks right level of abstraction. It is either too low-level (typed arrays, hand rolled allocations etc) or too high-level.

Re: Opal: Ruby to JavaScript Compiler

#67

Post by elia »

ankurpatel wrote: post #43
DouweM wrote: post #38

Earlier quoted context omitted.

Opal supports `method_missing`: http://opalrb.org/docs/method_missing/ `define_method` as well: https://github.com/opal/opal/blob/f958d6b2468e57acf7f324e10a...

This is not pure way of doing meta programming. It looks at the code to figure out what methods are being called in future. Opal.add_stubs(["first", "second", "to_sym"]); But lets say I am dynamically generating method using a string passed from user input or server then this would fail.

I had the same fear at first, but actually if you generate dynamically a method name you need to use `#__send__` (and friends) to call it.

Of course `#__send__` supports method_missing: https://github.com/opal/opal/blob/0-6-stable/opal/corelib/ba...

Re: Opal: Ruby to JavaScript Compiler

#68

Post by elia »

munificent wrote: post #56
angersock wrote: post #52

Earlier quoted context omitted.

The core of the issue here is that, in Ruby, it's all about messages and method invocation, right? I'd suggest that, while correct, your observation about types is a strawman--the generated Javascript (while quite slow!) follows the semantics of the Ruby language correctly; the addition operator is just a function, and with different context could've done something entirely differently. We could've, say, briefly over…

> follows the semantics of the Ruby language correctly; Exactly, the compiled code follows the Ruby language correctly. It's also unusably slow. It's possible to generated compiled code that also follows the Ruby language semantics by using knowledge of which portions of those semantics the actual program in question relies on. That program can be a lot faster. In other words, if you haven't overloaded arithmetic ope…

> If you've got a way to compile Ruby to JS that has tolerable arithmetic perf and doesn't do type analysis or generate a huge volume of code, I would definitely like to know more about it.

Yeah, that's kinda the point, you can do that and preserve Ruby semantics?

Let me note here that is a strawman indeed, Dart has frozen classes, Ruby is a bit different. In order to do something like that you should inline a ton of ternary operator to check if the method has been redefined on that particular object.

Something like:

    (a._isNumber && !a._plusRedefined) ? a + 1 : a['$+'](1)
plus listening on new method definitions to set `_plusRedefined`.

It's definitively a trade off, readability will suffer.

Opal had optimized operators in the past (that assumed native operations on numbers), they could even be back in the near future. But what I see here is a comparison of two different language semantics. I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything. What can be argued instead is that JS VMs could and should do that for us.

Re: Opal: Ruby to JavaScript Compiler

#69

Post by munificent »

elia wrote: post #68
munificent wrote: post #56

Earlier quoted context omitted.

> follows the semantics of the Ruby language correctly; Exactly, the compiled code follows the Ruby language correctly. It's also unusably slow. It's possible to generated compiled code that also follows the Ruby language semantics by using knowledge of which portions of those semantics the actual program in question relies on. That program can be a lot faster. In other words, if you haven't overloaded arithmetic ope…

> If you've got a way to compile Ruby to JS that has tolerable arithmetic perf and doesn't do type analysis or generate a huge volume of code, I would definitely like to know more about it. Yeah, that's kinda the point, you can do that and preserve Ruby semantics? Let me note here that is a strawman indeed, Dart has frozen classes , Ruby is a bit different. In order to do something like that you should inline a ton o…

It's not just readability that suffers. Even inlining the check like you do here, what you have will be dramatically slower then raw arithmetic.

(My hunch is that your inlined check would actually be slower than just calling the method, actually. If you just do a method call, the inline caching will optimize it away in many cases.)

> I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything.

All I was trying to demonstrate was just that. If you want a new language that runs in a browser, you can have:

    1. Different (presumably better) semantics from JS.
    2. A simple compiler that generates readable JS.
    3. Performance competitive with raw JS.
But you only get to pick two. CoffeeScript picks 2 and 3 (though it does subset out some of the bad JS behavior). Dart picks 1 and 3. Opal (from the very little that I know about it) seems to be picking 1 and 2.

By belief is that for a client-side language (i.e. a language that runs on the end user's hardware, which you don't control), that you don't have the luxury of sacrificing perf. You can in a server-side language since you can just throw more hardware at it. That's why languages like C++ still dominate client-side apps and games.

Given that, I don't think a language that targets the browser can really discard #3 and expect to get a decent number of users. Given that I love different languages, I'd be happy to be proven wrong here.

Post reply on HN