Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm trying to use asm.js to port Python to JS as a shared library, which would allow us to load and run arbitrary CPython modules (compiled for JS) in the browser. I generate code using emscripten, which is also able to generate WASM (which I'm not using at the moment though).

My experience so far:

Emscripten is quite mature and compiles even very complex C/C++ code without complaining. Statically linking code works fine, while dynamically loading shared libraries is still a bit problematic it seems.

Here's the Github project btw, help is very welcome:

https://github.com/adewes/cpython-emscripten



Slightly disconcerted that the first thing webdevs are rushing to do with wasm is to port massive language runtimes to it, continuing the web tradition of piling shit upon shit upon shit. Personally believe that this is totally the wrong idea; compilation or transpilation from intermediate forms is far more interesting and sensible in my view


Sure when targeting the web with software that doesn't exist yet I would definitely write that in JS. However, if there is a well-tested crypto library that has 300.000 lines of well-tested C code and that I can use without too much pain by transpiling it to JS I'd always prefer that to writing my own implementation in JS. In that sense transpiling is a great way to reduce redundancy by allowing to use code in different context. Concerning the intermediate form: I'm a big fan of model driven development but I think our tooling for it isn't good enough yet, so until someone invents a description language that is really powerful enough to describe let's say a crypto library and then generate code from that in various languages I think transpiling from one concrete language to another is still a better option.

BTW a lot of the power of Python, Ruby and JS comes from the interface these languages provide to existing C/C++ codebases, and I assure you that the binding code to make this work is often far from pretty. As end users we don't care about this though as long as it works.


It's not like people are planning on using these in production. It's just some fun hobby projects that are useful for, say, online Python tutorials and stuff.


Well actually, I would. But not for webapps.

There's a fairly large class of scientific computing oriented apps where having a widely deployed and fast VM with CPython compatibility would be fantastic. Python (for better or worse) has a large library of open source computational libraries, but shipping an embedded CPython VM is a pain. As an example, I helped advise an undergrad working on a program to calculate collagen fiber orientation for biomedical research labs. Figuring out cxfreeze or other Python packaging systems took longer than writing the actual app.

Unfortunately JavaScript doesn't have broad scientific library support and grad students in non-CS fields don't always have the time to become versed enough in C/C++ to create a usable app. So CPython & associated C libraries ported to wasm could be quite useful... This could apply to R programs as well.

Re: grandparent, just because a project offends your sense of purity doesn't mean it isn't surprisingly valuable for others.


> Emscripten is quite mature and compiles even very complex C/C++ code without complaining.

Because it's just Clang with WASM target.


I think it's a bit more than that given that the project has amassed more than 16.000 commits so far.

You must not forget that JS does not provide support for many of the things that are required to run a C program (e.g. printing), so emscripten needs to take care of providing alternative implementations for all these things.


Oh, alright. We are speaking about two different things. I was thinking about compilation and specifically supporting complex language features which are mostly handled by a compiler frontend which is this case is clang. And it seems that you are thinking about runtime libraries (or the whole tool chain).


Ah yes you're right, that part is luckily covered by LLVM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: