Julia is a high-level, high-performance dynamic programming language for numerical computing. Sophisticated compiler, numerical accuracy, distributed parallel execution, and an extensive mathematical function library make Julia popular for data science. Its Base library is mostly written in Julia itself.
Pros:
Julia is free, so you don’t need a license.
Julia is compiled but not interpreted. Consequently, it wins in speed.
Julia can be used not only for numerical analysis. It can be used as a general-purpose programming.
Julia code can be combined with other language libraries written in Python, C, and Fortran. Moreover, we can interface with Python code by PyCall library and share data between Python and Julia.
Julia can provide metaprogramming. Its programs can produce other Julia programs and moreover modify their own code.
Cons:
Julia is not properly developed. Due to its recent entry, there is a need for improvements. Julia’s tools are not as fluid and reliable as they wished to be.
Julia has a limited number of packages because it is young and their community is pretty small. Unlike R and Python, Julia doesn’t have such a variety of packages.
Julia can’t identify issues. Julia is far behind from Python and R in terms of identifying issues and debugging tools. But soon more tools were expected to be developed for users.
Rant mode
So basically don’t rely on packages? Probably shouldn’t most of the time anyways.
Pythons libraries are great until you actually need to do something outside of a cookie cutter, then you end up patching the hell out of them, and submitting bug reports to 15 yr old legacy codebases that are thousands of lines of illegible crap contributed from 400 people who eagerly patched hot fixes to finish a job.
R on the other hand has a more robust and reliable ecosystem. If your team is just churning some basic models, and need’s easy high quality visualizations, R is great. But deployment options aren’t as extensive as python last I checked anyways. So if the product is software based well yikes.
Julia really fits a nice middle ground. I used it in industry to do data science, and so a few bugs came up, so what? At least everything was flexible enough that I could work around them. I never once had to use C/C++, every major project I’ve had in python and R I have had to do that… In python that usually means supporting Cython until the end of time(huge pain), in R, not as painful but still annoying/costly spending time rewriting code and debugging C++ from Rstudio ffs…
Basically, if you are working on cookie cutter problems use cookie cutter languages with cookie cutter packages, who cares what tool you use? If you actually have real problems, and you need to build something, don’t waste time starting in the wrong language, use Julia.
Yes, of course! I see it the same way and in this case I unfortunately have to say that the reach of the KDnuggets newsletter is quite large and therefore I fear that “opinions” might be consolidated. Therefore I have also left a comment…!
I don’t know about this — their website looks like something from the 1990s. But in any case, I think that the spread of “information” like this is self-perpetuating to a certain extent (like the way you are reposting it here).
The recipe is to write something simplistic about 10 different things, making your message spread in 10 different communities, each of which will be concerned that their particular thing was not addressed well, then they will discuss and repost it. It is quite ingenious as a strategy, and of course takes discipline to ignore.
Solid points. Yea their website looks like something I would design 15 yrs ago, except why yellow everything? And yea if you really look at the other language overviews they are pretty poor as well…
Totally inadequate assessment. Julia allows you write composable software by solving the expression problem, which OOP failed to achieve despite promising it for four decades. It’s also fast, and when it’s not, it provides substantial help to improve performance. Of course there are downsides, but Julia got the foundations right.
Maybe! My experience is a bit different: The customer is interested in the solution and less in the software tool. The customer simply assumes that the software used complies with a standard such as ISO 9126.
I looked into Python some 7-8 years ago – I’m sure it has improved since then. I found DiffEq solvers unintuitive. There were some good optimization code. There was also an optimization code written in Python… which completely failed on the Rosenbrock banana function unless I started within 10% from the optimal solution. At that time, Spyder was really bad. I used Wing 101, which had super good support from developers.
I much prefer the syntax of Julia. The transition from v. 0.6 to 1.0 was a little painful, but Julia itself has converged decently now. Some packages are a little bit in the flux, but as they mature, there will be converge in their interfaces, too. Julia has most of the packages I need.
For the average scientific computing user (I’m not talking about developers!), some maturing of IDEs with graphical debuggers will help. Also, more introduction books will help – at least for myself who prefers to browse books.
I agree! I see a lot of potential in Julia (I know, I repeat myself) and that was the reason to write an introduction to data analysis with Julia. I assume that there are some people interested in Julia who like to use books as a basis. I also started to do some advertising (of course for my book as well) on YouTube for Julia.
