
Ruby 1.9 lands NaCl support, can run in Chrome - igrigorik
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=35672&view=revision
======
bad_user
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.

~~~
cageface
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.

~~~
bad_user
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.

~~~
cageface
Obj-C is a very simple language. You can pick it up in a week or less if you
have any experience with other languages.

Cocoa Touch is a different story though. Even an experienced UI programmer
will probably need a few solid months of study to get up to speed.

In my limited experience it's easier to get going in Android but things get
more fiddly as they get more complex. For example, gesture handling is a lot
easier on iOS.

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

~~~
andrewflnr
_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?

~~~
derefr
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.

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

What's up with that?

~~~
djacobs
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
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).

------
icco
Here is the same commit in GitHub:
[https://github.com/ruby/ruby/commit/76bc2d1ed7f13fb329c33f48...](https://github.com/ruby/ruby/commit/76bc2d1ed7f13fb329c33f48756ea3c24c59a6ea)

------
icepick
Has anyone built this and have a demo?

~~~
Spakman
Here you go:

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

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

------
pjmlp
NaCl == Google's ActiveX, no thanks.

~~~
tomjen3
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).

~~~
gcp
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.

------
markus2012
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.

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

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

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

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

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

~~~
azakai
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>

------
ippa
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
Stupid nitpick: The 'l' should be uncapitalised as chlorine's chemical symbol
is 'Cl'.

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

~~~
megaman821
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.

~~~
gcp
_The whole point of NaCl is to stop bundling runtimes with the browser_

Ironically enough that's exactly what NaCl itself is.

~~~
obtu
I think that's stretching the definition; NaCl is part of the runtime
environment, but only as a sandbox which programs won't notice unless they go
off the rails. Unless you meant Pepper, which does provide enough platform
support for a port of the flash plugin. But Pepper is an API, and the
functionality it gives access to would be part of Chrome anyway.

------
eagsalazar
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>

~~~
tomjen3
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.

~~~
batista
"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.

~~~
VeejayRampay
I'ver never understood how the "this" thing actually brings possibilities. If
anything, it introduces unnecessary confusion about scoping/binding. Python
and Ruby don't have "this" and do just fine.

~~~
batista
Well, Python has "self", that you have to explicitly pass. Not the best
example.

~~~
lucian1900
But Python's methods already have self curried in. Class.foo(self, x) takes
two arguments, but instance.foo(x) already has self bound, and only takes on
argument.

This lets you do bar = instance.foo; bar(x) and it'll still work. Much more
consistent.

