If you were trying to motivate someone embedded in Python / scipy / pandas / etc to move to Julia at this time , what would you say?
I also think writing out math is much more concise in Julia, no more np.whatever(np.sin(x.detach()) + cos(np.sqrt(y)).mean().
Yes, far exceeding python actually. - https://github.com/jump-dev/JuMP.jl - https://github.com/JuliaNLSolvers
Are just some.
> graphing
Excellent support.
- https://github.com/JuliaPlots - https://github.com/JuliaPlots/Makie.jl
>Munging xml/Json etc
- https://github.com/quinnj/JSON3.jl - https://github.com/JuliaData - https://github.com/Algocircle/Cascadia.jl - https://github.com/queryverse/Query.jl
>oauth2 etc
- https://github.com/JuliaCloud - https://github.com/JuliaWeb/HTTP.jl
for anything not available yet, you can call it from python using PyCall.jjl
Julia's equivalent to xarray: https://github.com/JuliaArrays/AxisArrays.jl
Original issue explaining the problem: https://github.com/pydata/xarray/issues/525
Latest issue detailing the work: https://github.com/pydata/xarray/issues/3594
The question I am currently researching is not what Julia is good at but what are the pitfalls and drawbacks of particular technical choices. I know them by heart now for Python, and my team relies on knowing what doesn’t work well. For Julia it’s an unknown unknown. Understandably all the blogs are about why Julia is great so it makes seems to go slowly and coexist instead of moving.
Mind elaborating?
Now, 8 years later, I'd say essentially everything there has been achieved. The most important difference between Julia now and Julia then is the gigantic, vibrant and interacting ecosystem that's sprung up (though share are other important technical differences too!)
_______________________________________________
Here's the pitch I'd give:
Julia's value proposition is mostly geared towards people trying to do things that are just too difficult, awkward or slow in other languages. It's not just about speed, dynamism and friendly syntax. It's also about solving the expression problem and providing unprecedented composability.
So while it may not necessarily have great appeal to 'end users' (who are people just calling numpy/scipy/pandas/whatever functions the way they were meant to be called by the library writers), it does appeal to people who make the sort of things end users want so the community is currently swelling with very talented people making state of the art research libraries. The language is designed for 'composability', so that it's very easy to combine packages together in ways the authors didn't necessarily intend or forsee.
This approach is really starting to bear fruit. Our package ecosystem has some real, state of the art stuff not easily available in other languages, and it's often built in less time and with less resources. For 'end users', whether or not Julia makes sense for them really just depends on if the things they need are already available.
Another huge advantage is that 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. This is really special and can't be replicated in python, because 'peeking under the hood' invariably means reading very specialized C code, rather than Python code.
I think Julia will someday eat Python for scientific computing, but it may be a while before that becomes obvious to Python users. In the meantime, we have an excellent package for calling and running Python code from withing Julia, called PyCall.jl [1], so that can make the burden of switching even easier.
Julia's syntax and language design is brilliant, but the biggest reason Julia has been my favorite language since I first learned to program is how astonishingly easy it is to use tools other people have made, and also to create tools for others to use.
The packaging system is just great for development, both as a user, and as a maintainer. I've been surprised by how easy it is to take stuff I've made and get it to work with a myriad of packages for the purposes I need. Multiple dispatch does wonders here too.
In the recent survey they said that 30% of respondents had contributed to a package. 30%! It's a super active ecosystem and the barrier of entry is low enough where I don't feel "imposter syndrome" as strongly as I have elsewhere--that I need to pass some threshold in order to properly contribute.
It's a hard problem to combat, because fundamentally, package code must be able to do arbitrary things. One advantage julia has though is that packages tend to be written in pure julia, which makes the duty of checking and detecting malicious code much easier.
> lowers the bar for mere mortals such as myself to do package development
That's a powerful combination. I've been close to contributing to Python packages a few times, but the overhead is pretty high. At this point, I also feel like it would be a waste of effort not to write stuff in Julia instead.
> Julia will someday eat Python for scientific computing
It's well on the way. Julia users have a reputation for being evangelists. Heck, I made a convert even before I actually started using Julia in earnest: my labmate had a problem he couldn't solve in his favorite language, and I encouraged him to try Julia -- it turned out great!
> I think Julia will someday eat Python for scientific computing, but it may be a while before that becomes obvious to Python users.
I can’t say I understand this rather pervasive attitude. If you have well tested code in a language which you can easily interface with, why bother rewriting it except for reasons of performance or compositionality? Or perhaps you mean that we’ll all be writing Julia even if some algorithms still sit in Python?
I mostly mean that I think Julia will someday have more mindshare in scientific computing than Python.
However, I'd say that the reason you see the "rewrite it in pure julia" attitude everywhere is that we enjoy a lot of benefits from having more and more things in pure julia, namely that our very powerful metaprogramming and code introspection tools can more easily 'get inside' Julia code, and that the compiler is able to perform interproceedural optimizations (IPO). IPO are not always important, but when you need them and don't have them, you really miss them, so at least for numerical kernels and such, it's really nice to have as much pure julia infrastructure as possible.
In the meantime though, as I daydream about a world where everything is written in Julia, there's nothing stopping me from being pragmatic and wrapping / bridging to and from other languages.
On the other hand Julia probably has a very strong long game, given that the Federal reserve bank uses it.
The containerization I used was singularity. I don't really love them much anymore, for various non-technical reasons, but it got the job done.
So here is an example and my worries ... My project uses GDAL, PIL, SentinelSat libraries to collect Sentinel 1 imagery and process it, pandas, numpy, scipy extensively. Would I find a bunch of those modules missing? I assume so ...
I guess then I might be better of to trying a new project in Julia. Something not too easy but not too hard.
Julia more than covers all the functionality of those packages.
>PIL
https://github.com/JuliaImages/Images.jl
> GDAL
https://github.com/yeesian/ArchGDAL.jl
>SentinelSat
I'd use PyCall.jl for that. It's very easy and does automatic conversion of types etc
Worst case scenario, you might need to do the GDAL, PIL and SentinelSat stuff with PyCall and then the Pandas, Numpy and Scipy stuff should all be quite well supported from the Julia side. I can ask around to see if there's anyone who can answer this better though.