Im not sure if Julia will ever take off. Right now there are huge investments in the AI space and Julia has no presence in those.
There is simply too many rough edges and usability problems as it is now, and at the current pace it will take maybe 10 or 15 years to address them.
On the other hand, the major use case for Julia is to have a fast, dynamic language. And it seems to me the time horizon for Python to become fast, or Rust or C++ to become dynamic is indefinite, so Julia is still the best bet in that space.
There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...
There are AOT compilers for JS.
Each thread has its own lua_State. However, we provide a serialization scheme which allows automatic sharing for several Torch objects (storages, tensors and tds types). Sharing of vanilla lua objects is not possible, but instances of classes that support serialization (eg. classic objects with using require 'classic.torch' or those created with torch.class) can be shared, but remember that only the memory in tensor storages and tds objects will be shared by the instances, other fields will be copies. Also if synchronization is required that must be implemented by the user (ie. with mutex).
Though as I said before, sometimes no amount of c++/c escape hatches can improve performance since you have to use python objects at some point or another and that will be the bottleneck. But by then, you won't needing some of the stuff Julia offers like the REPL and notebooks etc.
I haven't used Julia a lot but to me it's in a weird spot where it would be ideal to start projects with in theory since you won't need to outgrow the language you are starting with, since it's fast enough and has a pretty good/maintainable/sane design. But then you are sacrificing so much and will need much more time to get started that you might not ever get to that point anyways.
Just as an example, debugging obscure problems or deploying pytorch models that are more custom in prod is already pretty daunting at times, and it's the "best" and most popular ML framework in the world. I can't imagine how much more time consuming it would be when using a much smaller/less used library/framework.
So yeah all of that to say that being way faster isn't how Julia will win. Maybe a push from an influent player/big tech might give it the momentum it needs.
Numba is also really nice, and for just compiling against arrays I like it better than Cython. Neither help if you need data structures or abstractions, though.
For open source accounts, there's the SciML showcase page https://sciml.ai/showcase/. Thats very focused in just one domain though, and I tend to just update it with what I remember to put in there so it probably only has about 1/4 of the blogs and news articles that it should, and the "External Applications Libraries and Large Projects using SciML" part is woefully incomplete, but at least it gives a picture of what's going on. It's hard to keep those kinds of pages up to date because exponential growth means that page requires exponential work.
And don't get me started on how nice JuMP.jl is for mathematical optimization.
In what way is this true? Looks like Julia didn't exist until 2012. If I remember correctly, theano was the big AD thing in python at that point.
Are there subdomains that use it a lot? I am not sure what the diffeq landscape is exactly although it sounds related to dynamical simulations?
https://github.com/JuliaSpace/
Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
I personally end up doing a lot of work that uses the HEALPix sky tesselation, so I use healpy [2] as well.
Openorb is perhaps a good example of a pure-Fortran package that I use quite frequently for orbit propagation [3].
In C, there's Rebound [4] (for N-body simulations) and ASSIST [5] (which extends Rebound to use JPL's pre-calculated positions of major perturbers, and expands the force model to account for general relativity).
There are many more, these are just ones that come to mind from frequent usage in the last few months.
----
[1] https://healpix.jpl.nasa.gov/
[2] https://healpy.readthedocs.io/en/latest/
[3] https://github.com/oorb/oorb
[4] https://rebound.readthedocs.io/en/latest/
[5] https://github.com/matthewholman/assist
Will look into those. I recently wrote a little n-body simulator to become familiar with Julia's DifferentialEquations.jl and that motivated me to learn more about astrodynamics.
The DiffEq library seems to pull you towards the SciML ecosystem and that might not be agreeable to everyone.
For instance a known Julia project that simulates diff equations seems to have implemented their own solver
It's an interesting space because:
-(a) there aren't really good benchmarks on the full set of options, so a benchmarking paper would be interesting to the field (which then gives a motivation to the software development)
-(b) none of the implementations I have seen used the detailed tricks from standard stiff ODE solvers and so there's some major room for performance improvements
-(c) there's some alternative ways to generate the stable steppers that haven't been explored, and we have some ideas for symbolic-numeric methods that extend the ideas of what people have traditionally done by hand here. That should.
so we do plan to do things in the future. And having Oceananigans is then great because it serves as a speed-of-light baseline: if you auto-generate an ocean model, do you actually get as fast as a real hand-optimized ocean model? That's the goal, and we'll see if we can get there.
We have tons of solvers, but you always need more!
All my data are in a database, Julia need to become more db oriented , that is it
A large part of why I started using Julia is because calling into other languages through the C FFI is pretty easy and efficient. Most of the wrappers are a single line. If there is not existing driver support, I would pass the C headers through Clang.jl, which automatically wraps the C API in a C header.
https://github.com/JuliaInterop/Clang.jl
I most recently did this with libtiff. Here is the Clang.jl code to generate the bindings. It's less than 30 lines of sterotypical code.
https://github.com/mkitti/LibTIFF.jl/tree/main/gen
The generated bindings with a few tweaks is here:
https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.j...
Mojo also owes part of its design from the lessons it took from Julia (as per Chris Lattner [1]).
I really do wish it were open source already though. I know they have laid out a roadmap for opening the source.
It gives real “Jony Ive leaving Apple to go work somewhere where nobody can tell him ‘no’ “ vibes.