7 ms·

I think it will all come down to web assembly. Why? Python has blaze, numba, dynd and dask going for it. These all ameliorate (and exceed Julia in some respe

I think it will all come down to web assembly. Why? Python has blaze, numba, dynd and dask going for it. These all ameliorate (and exceed Julia in some respects) many of the disadvantages of python (including fast user defined types). Then there are the libraries that while some can be used in Julia, you will never get full reliability, ease of use and compatibility. On the other hand, Julia has amazing metaprogramming and much cleaner scientific syntax. I think it will come down to whether Python can compile to fast LLVM regular standard lib programs. Once (if?) Julia can be run in the browser with web assembly (using ahead of time compilation to produce small binaries), python has no chance if it doesn't follow suit. Python has no advantage that can permanently match Julia's potential ability to run on mobile, front end web, back end etc all from one beautiful codebase. What does HN think?

riscy 10y ago
> Once Julia can be run in the browser with web assembly [...] That will never happen for Julia, because the language is designed to be fast for scientific computing... targeting web assembly is a pointless additional layer of abstraction that only negatively impacts performance.
- tanlermin 10y ago
  Yea... I don't think so: https://github.com/JuliaLang/julia/issues/9430 https://github.com/JuliaLang/julia/issues/9430 http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/02/09/static-julia.html
  - riscy 10y ago
    A "compiled binary emitted by a hypothetical slimmed down non-numerical Julia" seems to be the going theory about WebAssembly support in that issue thread, as the numerical C/Fortran libraries needed by Julia have inline assembly too. Doesn't sound like there is a direct way forward. I see value in Julia web notebooks, where the lifting is done by a server (or localhost), but what are the motivations for running Julia in a browser?
    - 3JPLW 10y ago
      There are definitely a lot of hypotheticals here, but many of those goals are desired in their own right and aren't specific to web assembly. Interestingly, there's a slow-but-steady effort underway to implement a generic BLAS and LAPACK in Julia itself, since this allows for computations with custom datatypes that aren't supported by the Fortran libraries. For example, you can now do QR factorizations and solves with any numeric type, including Rationals and Quaterions: http://stackoverflow.com/questions/20985783/rational-matrix-division-in-julia http://stackoverflow.com/questions/20985783/rational-matrix-... Julia's dispatch system allows for these kinds of layered algorithms very nicely, and they could just as well live in separate external packages.
tavert 10y ago
> including fast user defined types Can numba do this yet? Without having to write special "numba classes" code? Blaze has a giant serialization wall between it and the JVM which it needs to solve to ever be competitive in its target market. Ibis is the much more compelling effort here. Dynd is an overly complex C++ disaster that is trying way too hard to solve problems that aren't what anyone really struggles with. The number of real world problems for which homogeneous dense multidimensional arrays of floating point numbers is the solution isn't growing much. Real problems have interesting structure that your data structures need to be able to exploit on a problem specific basis. Doing the array layer all in templated C++ with Python bindings is not a recipe for making something easy to use and effective at problems it wasn't previously designed and compiled to solve. Displacing numpy is not going to happen in the Python space. Dask has good ideas, but the insistence on implementing everything in pure python means you're stuck with the GIL and lousy performance of your scheduler. This needs to be low overhead if they want anyone to actually use it.
- tanlermin 10y ago
  Granted special Numba class syntax, and nowhere near as elegant or integrated as Julia. Dask distributed interfaces directly with HDFS...no need for serialization. Dynd is specifically designed to deal with arrays of custom types...criticism sounds like it would be more aptly directly towards numpy. once it gains Numba binding it will lose the Python overhead. Re Dask...is 1ms per task too much? It has a threading scheduler that can work with numpy arrays to release the GIL....so not bound by that with numerical code. Regarding regular list and text processing... Julia's poor performance with heterogenous data actually makes it slower than python for cleaning the corresponding dirty and text datasets.
  - tavert 10y ago
    Interfaces to HDFS how? PyObject has to get translated somewhere. Arrays of custom element types is a good first start, but boy is dynd a seriously overengineered way to accomplish that. I'm referring to array structure, sparsity, symmetry, linear algebraic properties that should be reflected in the type system. Python's type system is lousy for this, and C++ isn't extensible. Julia can fix performance on heterogeneous data with gradual compiler improvements, and the string representation is due for a major rework. Python can't fix the fact that the language and libraries were not designed to be efficiently JITted, and extension interfaces are closely coupled to the CPython interpreter's API.
simonster 10y ago
WebAssembly is a neat idea, and could be useful for creating cool ways of interacting with scientific data. But a lot of code scientists write only needs to run once on one machine. And in that case, there's no reason to take the inevitable performance hit associated with WebAssembly.
ww520 10y ago
Web assembly would be great. Most browsers support WebGL now. Julia can utilize the GPU via the browser; the gain would be huge. Second, browsers are perfect for SETI-style distributed computation. Imagine a beowulf cluster of these browsers running downloaded Julia snippets...
username223 10y ago
> Julia's potential ability to run on mobile, front end web,... Julia is designed for interactive, exploratory scientific programming, like Matlab and R. I don't see any reason someone would want to do that on a phone or in a web browser when it already runs natively on a PC. Then there's the matter of Julia being designed to interface efficiently with optimized native C/Fortran libraries.
- KingMob 10y ago
  This. Scientific computing is not interested in running in web browsers. As a former neuroscientist, I occasionally had connectivity analyses that would take 3 weeks to run. No way would I risk slowing it down with anything unnecessary. A 25% slowdown for using VMs in the browser would mean milliseconds for users and days for me.
  - grayclhn 10y ago
    R's "shiny" is a counterpoint. Obviously something that takes a week to run isn't going on the web. But a complex model and visualization that can be incrementally updated quickly and in real time? That would be cool.
    - elcritch 10y ago
      +1 for this! For large programs -- server side Julia, but having browser native Julia via WebAssembly would make visualization and interactive analysis for data science fantastic. Performance of running large GUI applications and libraries would be much faster since WebAssembly could take advantage of the huge amount of work done for optimizing JS by tiered interpretation/JIT'ing.
    - KingMob 10y ago
      I agree there's value on the visualization side. Most scientists still do a poor job of sharing results to the public and other scientists (other than by printed images in your article...)
- ZenoArrow 10y ago

riscy 10y ago

> Once Julia can be run in the browser with web assembly [...] That will never happen for Julia, because the language is designed to be fast for scientific computing... targeting web assembly is a pointless additional layer of abstraction that only negatively impacts performance.

tanlermin 10y ago
Yea... I don't think so: https://github.com/JuliaLang/julia/issues/9430 https://github.com/JuliaLang/julia/issues/9430 http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/02/09/static-julia.html
- riscy 10y ago
  A "compiled binary emitted by a hypothetical slimmed down non-numerical Julia" seems to be the going theory about WebAssembly support in that issue thread, as the numerical C/Fortran libraries needed by Julia have inline assembly too. Doesn't sound like there is a direct way forward. I see value in Julia web notebooks, where the lifting is done by a server (or localhost), but what are the motivations for running Julia in a browser?
  - 3JPLW 10y ago
    There are definitely a lot of hypotheticals here, but many of those goals are desired in their own right and aren't specific to web assembly. Interestingly, there's a slow-but-steady effort underway to implement a generic BLAS and LAPACK in Julia itself, since this allows for computations with custom datatypes that aren't supported by the Fortran libraries. For example, you can now do QR factorizations and solves with any numeric type, including Rationals and Quaterions: http://stackoverflow.com/questions/20985783/rational-matrix-division-in-julia http://stackoverflow.com/questions/20985783/rational-matrix-... Julia's dispatch system allows for these kinds of layered algorithms very nicely, and they could just as well live in separate external packages.

tavert 10y ago

> including fast user defined types Can numba do this yet? Without having to write special "numba classes" code? Blaze has a giant serialization wall between it and the JVM which it needs to solve to ever be competitive in its target market. Ibis is the much more compelling effort here. Dynd is an overly complex C++ disaster that is trying way too hard to solve problems that aren't what anyone really struggles with. The number of real world problems for which homogeneous dense multidimensional arrays of floating point numbers is the solution isn't growing much. Real problems have interesting structure that your data structures need to be able to exploit on a problem specific basis. Doing the array layer all in templated C++ with Python bindings is not a recipe for making something easy to use and effective at problems it wasn't previously designed and compiled to solve. Displacing numpy is not going to happen in the Python space. Dask has good ideas, but the insistence on implementing everything in pure python means you're stuck with the GIL and lousy performance of your scheduler. This needs to be low overhead if they want anyone to actually use it.

tanlermin 10y ago
Granted special Numba class syntax, and nowhere near as elegant or integrated as Julia. Dask distributed interfaces directly with HDFS...no need for serialization. Dynd is specifically designed to deal with arrays of custom types...criticism sounds like it would be more aptly directly towards numpy. once it gains Numba binding it will lose the Python overhead. Re Dask...is 1ms per task too much? It has a threading scheduler that can work with numpy arrays to release the GIL....so not bound by that with numerical code. Regarding regular list and text processing... Julia's poor performance with heterogenous data actually makes it slower than python for cleaning the corresponding dirty and text datasets.
- tavert 10y ago
  Interfaces to HDFS how? PyObject has to get translated somewhere. Arrays of custom element types is a good first start, but boy is dynd a seriously overengineered way to accomplish that. I'm referring to array structure, sparsity, symmetry, linear algebraic properties that should be reflected in the type system. Python's type system is lousy for this, and C++ isn't extensible. Julia can fix performance on heterogeneous data with gradual compiler improvements, and the string representation is due for a major rework. Python can't fix the fact that the language and libraries were not designed to be efficiently JITted, and extension interfaces are closely coupled to the CPython interpreter's API.

simonster 10y ago

WebAssembly is a neat idea, and could be useful for creating cool ways of interacting with scientific data. But a lot of code scientists write only needs to run once on one machine. And in that case, there's no reason to take the inevitable performance hit associated with WebAssembly.

ww520 10y ago

Web assembly would be great. Most browsers support WebGL now. Julia can utilize the GPU via the browser; the gain would be huge. Second, browsers are perfect for SETI-style distributed computation. Imagine a beowulf cluster of these browsers running downloaded Julia snippets...

username223 10y ago

> Julia's potential ability to run on mobile, front end web,... Julia is designed for interactive, exploratory scientific programming, like Matlab and R. I don't see any reason someone would want to do that on a phone or in a web browser when it already runs natively on a PC. Then there's the matter of Julia being designed to interface efficiently with optimized native C/Fortran libraries.

KingMob 10y ago
This. Scientific computing is not interested in running in web browsers. As a former neuroscientist, I occasionally had connectivity analyses that would take 3 weeks to run. No way would I risk slowing it down with anything unnecessary. A 25% slowdown for using VMs in the browser would mean milliseconds for users and days for me.
- grayclhn 10y ago
  R's "shiny" is a counterpoint. Obviously something that takes a week to run isn't going on the web. But a complex model and visualization that can be incrementally updated quickly and in real time? That would be cool.
  - elcritch 10y ago
    +1 for this! For large programs -- server side Julia, but having browser native Julia via WebAssembly would make visualization and interactive analysis for data science fantastic. Performance of running large GUI applications and libraries would be much faster since WebAssembly could take advantage of the huge amount of work done for optimizing JS by tiered interpretation/JIT'ing.
  - KingMob 10y ago
    I agree there's value on the visualization side. Most scientists still do a poor job of sharing results to the public and other scientists (other than by printed images in your article...)
ZenoArrow 10y ago