Ruby 1.9 lands NaCl support, can run in Chrome

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=35672&view=revision

by igrigorik • 14 years ago

123 72 14 years ago

svn.ruby-lang.org

charliesome• 14 years ago

I always thought Ruby used Git (https://github.com/ruby/ruby), but this links to an SVN repo.

What's up with that?

Argorak• 14 years ago

The official Ruby repository is still on svn, as all the tooling is implemented on top of it. ruby/ruby is the official mirror on github and does accept pull requests, etc.

djacobs• 14 years ago

I've talked with one of the core devs, who has said that the primary reason they haven't switched is of them use Windows.

petercooper• 14 years ago

Which is reasonably ironic considering Ruby's reputation for running on Windows (which has taken major third party efforts to get it to work in any sane way).

VeejayRampay3• 14 years ago

It's pretty ridiculous that Ruby still uses Subversion yeah.

jgmmo• 14 years ago

What is significance of this? When can I write Ruby as easily as JS/PHP?

zitterbewegung• 14 years ago

This means that you can run ruby in the NaCL component of google chrome. It doesn't mean that the language syntax will change or make it "easily as JS/PHP"

phamilton• 14 years ago

You already can write Ruby as easily as PHP (they are both server-side languages). What this means is that Ruby can be used as a client side language via NaCl, provided browsers support it.

kennystone• 14 years ago

Probably never as easily as JS in the client. You should look at CoffeeScript if you don't like JS syntax.

azakai3• 14 years ago

You can compile other languages than CoffeeScript to JS. C++, Java, C#, for example. Also, you can run Ruby in the browser right now by compiling its runtime (in a standards-compliant way without NaCl),

http://repl.it/#:languages

VeejayRampay3• 14 years ago

Of course it will be just as easy eventually. Surely you don't think we'll be forced to use JS forever now do you? Coerce people into using a UNIQUE and LIMITING solution and they will find ways to use something else. The sooner the better.

icco• 14 years ago

Here is the same commit in GitHub: https://github.com/ruby/ruby/commit/76bc2d1ed7f13fb329c33f48...

peppertree• 14 years ago

Does anyone know if future versions of chrome will come bundled with ruby runtime? Or is it going to be a plugin download.

koko775• 14 years ago

Probably never. NaCl lets you embed programs into a webpage, protected by a layer in between the OS and the actual code so that it can't break out and wreak havoc like ActiveX once did.

So this means that any website could embed Ruby code (more strictly speaking, it could embed a Ruby interpreter) to be executed client-side on a browser supporting NaCl.

drivebyacct2• 14 years ago

That's like asking if Chrome is going to come with Adblock Plus or some other random extension or app...

megaman821• 14 years ago

The whole point of NaCl is to stop bundling runtimes with the browser. You can develop in whatever language you like as long as it can compile to NaCl byte-code.

That said there could be a Chrome app that is a Ruby interpreter running on NaCl.

gcp2• 14 years ago

The whole point of NaCl is to stop bundling runtimes with the browser

Ironically enough that's exactly what NaCl itself is.

obtu5• 14 years ago

Ruby will likely be packaged as a PNaCl library, and silently pulled by any chrome application or extension that uses it.

icepick• 14 years ago

Has anyone built this and have a demo?

Spakman• 14 years ago

Here you go:

http://yugui.jp/nacl/example.html

Chrome/Chromium(?) 19+ required, I think.

EricR23• 14 years ago

Interesting. I wonder, though, what the advantages of executing sandboxed ruby in the browser are?

eklitzke• 14 years ago

This would let you write Chrome extensions in Ruby (rather than JS).

TazeTSchnitzel2• 14 years ago

You could already do that by compiling Ruby with Emscripten, there is nothing new here.

obtu5• 14 years ago

Porting a rails application to run serverless.

ippa• 14 years ago

While NaCL is exciting tech I wonder how user-friendly (load times, performance etc) and how easy to develop on top of it, it will be in reality.

jlgreco• 14 years ago

Stupid nitpick: The 'l' should be uncapitalised as chlorine's chemical symbol is 'Cl'.

tomjen34• 14 years ago

About as friendly as flash -- if the game or app is big, show a loading bar and use the browser cache aggressively.

eagsalazar2• 14 years ago

On the one hand I get why people are excited about this and why people like coffeescript, especially when source maps start working in inspector/firebug. You can write web apps in the language you love and know. Cool!

On the other hand, this really sucks. Javascript is just maturing to where it is really awesome! And there is a ton of collaboration among app developers because javascript was the only game in town for so long.

Of course people will continue to collaborate but not, I fear, at the same level. 3rd party libraries will continue to be available, but not as many will fit in so neatly with people coding in other languages.

This has already come up a few times with coffeescript and in a couple years when it is truly easy for people to work in other languages, we'll have a tower of babel effect.

JS is really good. It isn't that hard to learn if you already know other languages. It has warts but it is also very powerful so often it is worth it (check out the lines of code and speed vs other languages):

http://shootout.alioth.debian.org/u32/javascript.php

chii• 14 years ago

I think that NaCl is more geared towards being a target of a port for an existing application thats been written (like the supreme commander game that google managed to coerce a studio to port to NaCl).

I htink the pie is big enough for both NaCl and javascript apps.

azakai3• 14 years ago

> I think that NaCl is more geared towards being a target of a port for an existing application thats been written

It is, but you can also port existing applications to JS.

> I htink the pie is big enough for both NaCl and javascript apps.

It's a different pie. NaCl is chrome-only (and just enabled in the chrome store, in fact), while JS runs in all browsers.

bad_user3• 14 years ago

You're right about Javascript, but those benchmarks you link to are completely useless. Take a look sometimes at the actual code.

igouy• 14 years ago

Your complaint is "completely useless" - say specifically what you think is wrong and point to examples.

If you think you could write better programs then write better programs and contribute them.

lucian19002• 14 years ago

JS is not really good, sadly. Harmony is looking better all the time, but still nowhere near as sane as most other dynamic languages.

tomjen34• 14 years ago

How much JS have you actually written?

It is a crap language designed in an afternoon and nowhere near good enough to solve the problems we currently use it for.

Just a few things of my head: 'this', 'var', no integers, semicolons, no block scope.

larholm• 14 years ago

I have written a lot of JS since my humble beginnings in 1997 where I wrote an "ajax" chat system running down to Netscape 2 and IE3.

There's no point in dismissing JS due to simple lexical issues; those have in no way prevented us from maturing the language use through idioms, patterns, tools and collective knowledge.

JS is more than good enough as a basis for CoffeeScript and Emscripten - so why should we care whether scope context or a lack of block scope can be initially confusing?

batista3• 14 years ago

"var" and "no block scope" are horrible.

"No integers" is bad.

"this" can swing either ways. It provides some cool possibilities.

"semicolons" however (either the presence or the removal of) is a totally inconsequential and trivial syntactic thing.

Removing semicolons doesn't even buy you what a small amount of syntactic sugar buys you. You saved a few keystrokes. Big fucking deal.

derefr3• 14 years ago

On a complete tangent: of all the language runtimes I'd expect to be converted to run in NaCl, I don't think Ruby's would top my list for "immediate practical uses." On the other hand, porting the Erlang BEAM VM--and thus allowing a web client to become a node in an Erlang process network, and have arbitrary code pushed to and executed on it by the network--would have tons of relevant applications. Anyone working on this? Should I start working on this?

eagsalazar2• 14 years ago

yes, you should.

(ignore my previous tower of babel whining wrt this particular application which sounds completely awesome)

andrewflnr• 14 years ago

allowing a web client to become a node in an Erlang process network, and have arbitrary code pushed to and executed on it by the network

Does this sound scary to anyone else?

derefr3• 14 years ago

We already have arbitrary code pushed to us and executed in our browsers all the time--it's called Javascript (and with JSONP, we even have more Javascript being pushed to us in realtime in response to events and eval'ed live. Nothing new here.)

The difference in running Erlang here is simply that the browser would be joining a network of agents and spawning agents of its own, instead of joining a network of processes and spawning threads/web-workers of its own. This would allow a uniformity of process logic, such that an agent could be transparently running on a browser or on a server to complete a task, and messages could be being passed transparently across the network to facilitate this, without any of the code having to differentiate the cases.

NaCl ensures the browser sandbox environment remains in place--so, other than perhaps getting a bit hot, your computer won't be doing anything it wasn't already doing just running the Javascript the server served it.

tomjen34• 14 years ago

Not if you know how NaCL works.

obtu5• 14 years ago

arbitrary code

For certain values of arbitrary; actually the code is restricted to the NaCl sandbox and the Pepper API.

reddit_clone• 14 years ago

Do you really need to port the Erlang VM for this? Wouldn't it be enough to implement the ErlNode line protocol inside the browser? (Say using Javascript and Websockets ? Or a browser extension?)

derefr3• 14 years ago

Yes, you could run pre-defined code in the browser given messages sent by the network this way. But you couldn't send the browser a code:compile(Binary) and then upgrade one of its modules in-place, as you could with any other Erlang node--which is sort of the point of using Erlang in the browser, as opposed to another language.

CarlHoerberg• 14 years ago

Distributed processing is a (not well known) core concept in Ruby as well: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.htm...

bad_user3• 14 years ago

I see that some people wonder why this is useful. I wonder the same thing, and in general I don't like the concept of NaCl, which will be ActiveX all over again, even though it has a better security sandbox, as poor security wasn't the biggest problem of ActiveX ... seems to me like Google is trying really hard to be like Microsoft.

However, I can't help but notice that Ruby, as a programming language, is getting ported everywhere. It runs on all desktop operating systems, it runs on top of the JVM and on top of Android. For iOS there are 2 competing versions already. For .NET the interest was low, so IronRuby is kind of dying, but it's still decent for a .NET implementation. Ruby MRI evolved a lot from 1.8 to 1.9, being a decent VM for a scripting language. Rubinius is much like Smalltalk, having the standard library in Ruby itself, allowing you to access the internals of the VM. JRuby is awesome.

Then there are the specs. Amongst the scripting languages people use today, Ruby has some of the best specs. It started with RubySpec, which are test suites started by the people working on Rubinius and now used by everybody else. And now Ruby is becoming an ISO standard. This makes me happy because when it comes to equivalent dynamic languages, there is no spec other than the reference implementation, making third-party implementations an unfeasible task. Perl 5 is a really good example of this.

So does anybody else find this exciting? As a language, Ruby is really mature these days, while still being fun and productive. Much like Smalltalk was back in the day.

cageface2• 14 years ago

I would be thrilled if somebody waved a magic wand and completely replaced Javascript with Ruby.

But since that's not going to happen, I instead lean heavily towards the path of least resistance when it comes to languages. I write iOS apps in Obj-C, CRUD apps in Rails, DSP code in C++, and web front end in JS. The cost of context switching is less than the cost of swimming upstream all the time.

dsirijus• 14 years ago

I couldn't agree with this one more. I only swim upstream if I have absolutely no other choice, courtesy of the Deadline.

But here's the thing - there's always Deadline. :)

bad_user3• 14 years ago

I have the same approach, however that's the reason for why I haven't written a single line of code for iOS. Getting started with it is just too much work, and I'm not sure if it's worth it, compared to Android for which I am already familiar with the language and IDE and getting a Hello World on my own phone took only a couple of minutes.

I wouldn't recommend iOS apps written in Ruby either, but the learning curve is too great for Obj-C. Not only do you have to learn a complicated API, but you also have to learn a new language, that's C with features from Smalltalk, and then get familiar with a new IDE. For beginners wanting to get shit done, without much time on their hands, that can be death by a thousand cuts.

vibrunazo• 14 years ago

ActiveX biggest problem, by far, was that it was part of Microsoft's Embrace Extend Extinguish (EEE) strategy. Meaning it was a proprietary technology that would make IE the exclusive benefactor of it. Screwing everyone else. So developers noticed that and didn't adopt it.

NaCl is open-source, which makes it literally immune to EEE. Google couldn't pull that off even if they wanted to.

kibwen• 14 years ago

You're conflating "open source" with "specified". Without a detailed specification, all alternative implementations are still forced to reverse engineer everything from the code--including any and all bugs or other quirks that the code contains. Furthermore, I've heard from those who have more knowledge about this that NaCl is heavily laden with Webkit-specific details. So yes, NaCl is open source. But that doesn't mean that Firefox, Opera, or IE could implement it, even if they wanted to.

The take-away here is to note that open-source does not preclude an EEE strategy. Once Google creates a specification for NaCl and Pepper, then we're talking. Until then, it's quite worrying.

draegtun• 14 years ago

Some other dynamic languages that have a language specification:

* Perl6 - http://perl6.org/specification/

* Io - https://github.com/jeremytregunna/IoSpec

pjmlp4• 14 years ago

NaCl == Google's ActiveX, no thanks.

tomjen34• 14 years ago

No true. NaCl doesn't use proprietary APIs and is, in fact, a standard.

It is just that the other browsers haven't implemented it yet. Blame them, not Google (or blame users who don't use Chrome, without whom this would be a non-issue).

gcp2• 14 years ago

Sorry, but no way that NaCl is a standard. It's a huge, Chrome-specific open source library. The fact that you can get the source doesn't make it a standard, by far.

pjmlp4• 14 years ago

I fail to see how having the code available suddenly makes it a standard.

markus20122• 14 years ago

NaCL != ActiveX. ActiveX code had unrestricted access to OS services. NaCL does not.

pjmlp4• 14 years ago

It still follows ActiveX concept of a plug-in for native code, which is made available only on a single browser outside the W3C web standards.

Coming from the Chocolate Factory company does not make it suddenly good.

If you want native code just use native code on the desktop. The web is for documents and network protocols.

markus20122• 14 years ago

This is neat.

It would be fantastic if someone did the same thing with the jvm. Then I could use Java or Clojure or whatever JVM-based language I wanted - and make use of tons of pre-existing libraries.

NaCL is the sandbox I want, not the craplet sandbox. With NaCL I can use C libs and access useful OS services without having to sign the app and ask the user for permission to delete their hard drive.

Ruby 1.9 lands NaCl support, can run in Chrome

Related Stories