3 ms·

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

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.

eliben 13y ago
You'll be interested in this project, then: http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-pnacl.html 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/pnacl-bitcode-abi https://developers.google.com/native-client/dev/reference/pn... - and we're working on making it more precise.
- Touche 13y ago
  Working on a PNaCl spec or did I miss it and that was released too?
  - eliben 13y ago
    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.
    - Touche 13y ago
      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?
      - Touche 13y ago
        Bueller...
      - jryans 13y ago
        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.
_random_ 13y ago
Native in-browser CLR, JVM and LLVM support would be the best world to live.
- stonemetal 13y ago
  I don't know that sounds like a very large surface to secure.
pjmlp 13y ago
> 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.

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.

eliben 13y ago

You'll be interested in this project, then: http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-pnacl.html 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/pnacl-bitcode-abi https://developers.google.com/native-client/dev/reference/pn... - and we're working on making it more precise.

Touche 13y ago
Working on a PNaCl spec or did I miss it and that was released too?
- eliben 13y ago
  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.
  - Touche 13y ago
    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?
    - Touche 13y ago
      Bueller...
    - jryans 13y ago
      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.

_random_ 13y ago

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

stonemetal 13y ago
I don't know that sounds like a very large surface to secure.

pjmlp 13y ago

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