I think you mean fully homomorphic encryption, that is, f(x.y)=f(x).f(y).
A homeomorphism is a isomorphism of topological spaces. If you do mean the latter then it would be something new (and I am curious to hear about it).
It really just boils down to the fact that julia's core value proposition is primarily enticing to domain experts trying to implement new algorithms without wanting to worry about switching languages for performance hotspots or having to reimplement existing functionality from other packages. Julia packages tend to be small, focused and astonishingly composable.
Hence, the proportion of the community that are actively developing and maintaining state of the art pacakges in julia is way higher than that in other languages like Python.
Furthermore, even if you're not some super researcher developer, Julia substantially lowers the bar for mere mortals such as myself to do package development. The composability I mentioned above means that I can stand on the shoulders of giants as I implement my own stuff, plus the fact that the majority of libraries are written in pure julia means that I can easily "peek under the hood" to figure out how they work and learn from them.
It's hard to make broad statements about how much ecosystem support one can expect from julia without first specifying the field. Some fields have fantastic julia support and others haven't received enough attention. It really just depends on if someone from your field has started making good packages yet.
How did you end up with libraries in global directories?
Also, while we are working on reducing the time to first plot latency (which has to do with compiling large amounts of code - the time to second plot is 0.2sec), it would be good to learn more about the compiler quality issues you mention. We always welcome constructive comments on the Julia discourse.
Note that even before this though, it's just the compilation phase for the first plot that's expensive. Plotting itself is quite fast in julia, and if you start up julia with the command line argument `--compile=min` you'll see very very fast first plots. Obviously, this will come with a runtime performance cost though.
Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem:
https://github.com/JuliaLang/julia/issues/28092
https://github.com/JuliaLang/julia/issues/17285
https://github.com/JuliaLang/julia/issues/4452
> It is hard to experiment with front end features like named dimensions, because it is painful to match them to back ends that expect calls to monolithic kernels with fixed layout. On the other hand, there is little incentive to build high quality back ends that support other features, because all the front ends currently work in terms of monolithic operators. An end-to-end tool chain for machine learning requires solutions from many specialist disciplines.
This is a fantastic example of getting around this problem using Flux.jl's interaction with the full Julia language. Here the author does some exceedingly cool stuff (doing machine learning on encrypted data!), and in order to get there he needed to write what many would think of as lower-level kernels that should be "provided by the library" (encrypted matrix multiplication, encrypted convolutions). To make the interface useful, he needed to use a mature interface that people are already using and make it something that can automatically switch over to encrypted implementations. And, because of the nature of fully homeomorphic encryption, the implementation has to be fast, otherwise it's dead in the water since FHE is expensive!
To me, this example showcases one way how Flux.jl's is helping machine learning get out of that "rut". The author adds dispatches to standard kernels which allow for his encrypted data types, which then allows standard Julia Flux.jl machine learning models to act on encrpyted data, and it uses type-inference + JIT compilation to make it fast enough to work. Not only that, but it's also not tied to some "sub-language" defined by a machine learning framework. That means the FHE framework not only works nicely with machine learning, it can be used by any other package in the Julia language (differential equation solvers, nonlinear optimization, macroeconomics models?). This allows composibility of tools and community: all tools from all fields can now use this same FHE implementation, so authors collaborate and mature this to a very good one. These knock-on effects give people doing research in Julia a lot of competitive advantages over other researchers, and it will be interesting to see how this effects not just the ML research community, but also everyone else!
https://dl.acm.org/citation.cfm?id=3321441
(Repost from the previous thread on this!)