You'll be interested in this project, then: http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-p...

It's important to emphasize that PNaCl is a platform. We currently provide front-ends for C and C++, but nothing prevents you from writing your own, for your own language (or an existing one). As long as you emit PNaCl bitcode, Chrome will run it for you. The PNaCl bitcode has a definition here - https://developers.google.com/native-client/dev/reference/pn... - and we're working on making it more precise.

Working on a PNaCl spec or did I miss it and that was released too?

Can you clarify what you mean by "spec"? The bitcode ABI document I pointed to is the spec of the IR used by PNaCl. The official documentation covers the Pepper APIs which are PNaCl's interface with the browser and DOM.

A document with which someone could create an alternative implementation; like another browser for example. Do I take this to mean that there isn't one?

There is no real "spec" of the Pepper APIs, just API docs. While those might be of high quality, it still depends on many implementation details, so it seems like it would be challenging for another browser to duplicate.

Bueller...

> One day, I will be able to compile my golang apps to work on browsers without losing considerable performance, multiple threads and concurrency. That day, I'll be very happy.

One day, the browser will be used again just for documents. That day, I'll be very happy.

Native in-browser CLR, JVM and LLVM support would be the best world to live.

I don't know that sounds like a very large surface to secure.