3 ms·
I don't know what scientific hole this peg fits into, but it might make more sense to run something in the browser than on the backend (scalability). Instead o
by sublinear 4y ago
I don't know what scientific hole this peg fits into, but it might make more sense to run something in the browser than on the backend (scalability).
Instead of using a wasm runtime for python for that it might also make more sense performance-wise to at least write that part in js if not an even faster language compiled to wasm. Either way if it ends up on a webpage some js will be needed to at least glue things together.
Also, from the perspective of just wanting to write some code and get what I want, I really don't see much of a difference between python and js.
For the rest of us, it's kinda the other way around. We can't figure out why scientists prefer python over all the other many options. I'm assuming it's just a lot of cobbled together legacy code nobody wants to breathe on.
> Furthermore, given that WebAssembly seems poised to (eventually) make strides in how browser-oriented applications are built
Also, this isn't really true. The proposals and implementations out there suggest the goal is to use wasm for libraries and specialized optimizations. Nobody wants to wait for a massive binary to download. You can try to port legacy junk apps, but making it usable on the web (not a canvas) might turn out to be more work than it's worth in many cases.
- no_circuit 4y agoScientific performance critical code isn't written in Python, it is written in C/C++ which is used by Python. Python in ML usually merely describes the calculation not unlike React describes the DOM that should be displayed in the browser. JavaScript was never really known for admin or file manipulation (Perl replacement), so that was what probably established the dominant ecosystem for Python. I also don't think the runtime overhead is applicable due to native C/C++ part, and download time doesn't have to be bad since modules can be split just like in JavaScript ecosystem today. For an AI app, the model inference weights might be larger than the compiled WASM code itself. However, I'd agree with you that porting legacy apps might not be possible without something close to a rewrite. There is a reasonable chance that once WASM GC is implemented, then direct DOM access will be provided [1], which I believe could pretty much halt interest in new JavaScript development for web frameworks overnight. WASM is the reincarnation of the Java Applet, but better. And a more typed language like Go or Dart could become the most widely used programming language. Either compile it to WASM as plugin for something like the browser, compile to JavaScript for "legacy browsers", or to native code for a standalone app. There are probably a handful of developers already assuming this and trying to write a version of React running in WASM already. [1] https://github.com/WebAssembly/design/blob/main/Web.md#gc https://github.com/WebAssembly/design/blob/main/Web.md#gc
- pjmlp 4y agoAnd Fortran, still.