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 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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
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),
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.
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"
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.
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.
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.
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):
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.
> 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.
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.
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?
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.
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.
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.