Ruby 1.9 lands NaCl support, can run in Chrome | Hacker News Reader

Ruby 1.9 lands NaCl support, can run in Chrome

svn.ruby-lang.org

123 pointsigrigorik72 comments

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.

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.

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. :)

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.

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.

On my line of work, we change languages and tools all the time, depending on customer needs.

I really find strange how someone can have a hard time doing this type of context switch.

I often find that the bigger problem with getting into an unfamiliar dev environment isn't syntax, rather it's getting to know the libraries. And if you're writing iOS apps, you'll need to know the libraries anyway. And yes Xcode is horrible, but fortunately AppCode is now out and quite usable, so that's another hurdle out of the way. But to me, the biggest advantage of developing for iOS over Android is the potential revenue. I'd rather sell software and features than try to make revenue with ads, so I stick with iOS.

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.

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.

Some other dynamic languages that have a language specification:

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

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

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?

yes, you should.

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

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?

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.

Not if you know how NaCL works.

arbitrary code

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

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

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.

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

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

What's up with that?

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.

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.

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

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

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

Has anyone built this and have a demo?

Here you go:

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

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

NaCl == Google's ActiveX, no thanks.

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

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.

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

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

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.

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.

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

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

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

Porting a rails application to run serverless.

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

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"

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.

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

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

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.

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.

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

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

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

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.

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

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.

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

Ironically enough that's exactly what NaCl itself is.

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.

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

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

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.

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

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

You can't just port things to JavaScript the same way. JavaScript is a very different sort of language. "porting" something to JavaScript pretty much always means remaking the whole thing from ground up and hoping that your pixel pushing in canvas runs at an acceptable speed.

Actually Emscripten allows you to port an existing native application to JS, and the development effort is comparable to using NaCl.

Yup. They've ported all sorts of things with Emscripten, including, I believe, Ruby, Python and Perl.

Yes. But it's a POC thing that's also some orders of magnitude slower...

It's not orders of magnitude slower, most benchmarks have it 2x-6x slower. It's rarely slower than 10x (one order of magnitude). And that is before JS engines even start to optimize for it.

You might want to read http://mozakai.blogspot.com/2012/05/emscripten-opengl-webgl-... for some eye-opening about what one can do with porting to JS in a _modern_ browser.

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

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.

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

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.

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?

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

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.

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

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.

Reply on news.ycombinator.com