Just use it. It’s not underdeveloped if you build and show the packages people want to use. Then show people what you’re doing. Ask what things they cannot do today and build that. I think that does a heck of a lot more than any high level presentation ever does.
It is earth science based. A lot of plotting, Machine Learning, Wave modeling. Finite elements, Signal processing. Mapping! A lot of physicists, mathematicians and computer scientist with applications to study the earth
What do you guys think about the potential of bringing people over to Julia? I mean I think i a great language to start (you can write live C or like Matlab), but I see a lot of seasoned coders here too!. Thoughts?
Hi Chris, you are an extremely generous man, but how could most of us possibly build things like Tullio, DiffEqs, LoopVectorization, Makie, and so many other high caliber packages that do make a difference? In the large base of the pyramid there are probably users with a little bit of DIY code thrown in. But I should add that a lot can be achieved by composing existing packages.
Building something to solve problems that someone cannot solve today can include using all of those tools. As a nice example of this, I like to point to Dan Padilha’s JuliaCon talk:
Using ModelingToolkit + DiffEq he got a domain-specific package that was 10x faster and has lots of cool new features for his domain. While MTK technically does this, until he came around “Julia could improve performance of designing spacecraft trajectories” was high level, theoretical, and speculative. Now there’s a package and video, go use it. There are tons of domains that need things pieced together correctly. If you package all of that up in a well-documented Julia package that clearly describes its advantages, then I have found that people will be happy to adopt it. So you don’t need to necessarily build the next LoopVectorization.jl, but if you can bring it to your domain, people will be ecstatic and that will be a major way to get the people around you using it.
On the earth science mapping front, geospatial tools are in heavy development currently. A lot of things will still seem harder than R/Python/Matlab and definitely less documented. But that is rapidly changing.
The interop is getting very good - increasingly geospatial packages work together seamlessly without converting objects manually (via GeoInterface.jl). We are working on integrating Makie.jl everywhere, which will be really amazing for interactive spatial visualizations.
In Rasters.jl I’m implementing super fast rasterization/coverage/masking/zonal stats (like 1-2 orders of magnitude faster than GDAL). It seems like we can do this for a lot of spatial operations in the medium term, algorithms are just so much easier to optimize and make parallel in Julia than in C++/R etc.
We partly have XArray-like features already with DiskArrays.jl, but they should get really good in the next year.
But: a lot of this is not easily demonstrable to a team at this point. A lot of it works, but with caveats.
So as @ChrisRackauckas says, it is better if you just use the language in your work for specific projects, and demonstrate the things that are 10/100 x faster and/or much cleaner to write, as you find them. Use julia to help with problems you cant solve in other languages. And help us meet your needs with issues, feature requests and PRs as you go.
You may be missing the central point a lot of us are trying to make - there is no easy generic comparison like this, and just “trying julia” is probably a waste of peoples time without a specific goal.
For some basic things Julia is far worse than other languages, because the tooling is missing or unfinished. For some things, especially high performance applications, Julia is often many times better than other languages. These areas are increasing, and the areas it is worse are shrinking. But thats a long process.
So the thing that matters most for your organization if there is currently an overlap between their specific needs and the things that Julia is much better at.
That is 99% of what will convince people at this stage of Julia uptake.
There you’ll see, in particular, that modern fortran syntax is quite simple and clean, by the way. So this is why there are other things in Julia that can interest fortran developers, such as how easy is to benchmark, package, document, distribute, and integrate the code with plotting and other tools, while retaining the performance (or perhaps improving it with the aid of the tooling by tuning the algorithms).
I really liked H2O.AI’s dataframes comparison, but they’ve stopped updating a year and a half ago (and lots of things have changed since then), and it’s quite expensive to run! Database-like ops benchmark
Well, if you want something simple (simple things always have a lot of power but also a potential bias of their own) to compare different languages, there is this exercise comparing 7 languages (Python, C++, Rust, Perl, R, Julia, FORTRAN) here.