The release notes for Julia 1.0 are rather empty at the moment. However, one may refer to the release notes of Julia 0.7 (https://github.com/JuliaLang/julia/blob/release-0.7/NEWS.md) which was released earlier today. Julia 1.0 is basically the same as 0.7, except that all deprecated syntax/features have been removed.
~~Note that this is the first release candidate version[1]:~~
> As a prerelease, 1.0-rc1 should not be considered production-ready. It’s intended to give developers a chance to get ready for the release of 1.0 by trying it out and testing for issues. Most users should continue to use the latest release (0.6.4 at the time of writing) until 1.0 is fully released.
It's pretty weird, I'd assume it was a mistaken tagging except that the commit [1] is very clear in its intent. I still don't think they'd suddenly have decided to rush through it all and release 1.0 like this, so I'm still assuming there's a mistake or misunderstanding here.
The annual juliacon is happening right now. So yes the last few weeks of this release process have been very rushed. Only around 160 packages have made releases that pass their tests using Julia 1.0.0 at the moment, out of 1900ish total registered packages.
Python is not the de-facto standard to my knowledge. It really depends on the field and task. R is huge in my research area, MatLab is king in some other areas, and Fortran is still being used for large-scale number crunching. Will Julia replace all these? That's the ambition but I doubt it's going to happen. For instance, R has a unique and vast ecosystem of extension packages. It would take decades to build something comparable in Julia.
Where I am people are really pushing out of the MATLAB/Python world into Julia. It's tailor made for scientific computing in a way that none of the others are.
Clearly we're talking decades, but I am already realizing pay-offs from the switch to Julia (from Python) in my domain.
Rackauckas pointed out an amazing example recently [1]:
You have a library that implements calculating with numbers with uncertainties. You have the differential equations library. They don't know about each other but you can use the former in the latter to solve differential equations with uncertainties with a whole bunch of advanced solving algorithms.
This sort of power, having an ecosystem like Python that combines in a performant way, will be huge.
Pandas actually has many alternatives. Including JuliaDB, DataFrames, and Pandas.jl
Keras also many. TensorFlow.jl, Flux, Mocha, KNet, MxNet.
Sklearn is all there but bring it together will take a bit.
Some important parts are in JuliaML org. Also Clustering.jl, and MultiariateStats.jl (For DR) the classifiers are really scattered. I'ld love to fix that if I had time.
Having migrated my Python+Fortran code to Julia in October last year I would say yes. For reasons why I would read the documentation basics, check the benchmarks and play with a bit of code. I was sceptical when my advisor originally suggested it but now I dread the thought of scientific software in any other language.
IMO industry will start switching once a Scikit-learn or Caret equivalent for Julia shows up. PyCall.jl and RCall.jl should take care of everything else until the rest of the ecosystem catches up.
Last time I tried to move all my stuff to Julia I ran into issues with the data frame equivalent package. It seemed the devs and community were in debate as to whether Julia and the dataframe should be more pure numerical focused a la matlab or python/pandas and appropriate for data analysis. As such null values were handled weird or not supported, which made it practically useless for all of my use cases.
I’d love to know if that was still the case though, because I’d so much rather use Julia than Python for my analysis and stuff.
Python has so much inertia at this point that it seems unlikely to happen in the near future.
Probably not quite to the scale as C/C++ vs rust for systems programming, but a similar idea. Rust has all these great features but most people doing systems know C, all their code is already in C, and so the cost of switching is very high.
Not that a switch will never happen, it's just that no matter how good Julia is any transition is going to take a long time. (I do think Julia is a good language though)
The object system is IMO the best feature of Julia. All functions are multiple dispatch, so the expression problem is more or less solved. This makes it easy to do things like allowing users to define custom sparse matrix types and use them seamlessly with other matrices and vectors. It makes it easy to abstract away implementation details in a much greater way than Python or R.
My only fleeting experience with Julia is in a Numerical Analysis Course three years ago... but it has 1-indexed arrays so its good for scaring away all people who are programmers before analysts/scientists!
Really though, I think it has a better type system and a syntax that translates easier to mathematical expressions. Other than that, Python's breadth of packages will be hard to overcome.
I know it is not the default, but this package has no overhead over the default arrays according to recent benchmarks, and provides 0-indexed arrays:
https://github.com/JuliaArrays/OffsetArrays.jl
I confess, not being the default is a big thing. I've definitely had times where I thought "this would be easier with 0 indexed arrays", but it can then be harder to commit to adding a dependency and making that change vs just adding awkward looking "+1"s to all the indexes.
Coming from math/science, there's lots of times 1-indexing makes more sense / is more familiar. It's normal there to start counting from 1, so it can be easier to translate.
You get used to the 1-based indexing pretty quick. It's a non-issue. 1-based indexing is the standard in math, and also Matlab and Fortran. For the primary use-case of Julia, it makes sense. Julia REALLY tries to be easy for Matlab users, who still dwarf Python users in science.
Even among scientists there are people who don't like 1-indexed arrays (me, one data point)! However, Julia 0.7 and 1.0 have the keyword "begin" so that you can basically program arrays in an index-agnostic way.
Is Julia a decent substitute for non numerically focused tasks?
I’ve been thinking about learning a new lang recently, and while Julia does seem to be a real alternative to python for analysis, I can’t see how ergonomic it would be for simple (or convoluted, why not?) scripts.
The reverse keeps me from investing more time in Go (and Rust), though
ScottPJones uses it for string processing, and I have seen him comment on hackernews a few times. He's a big advocate for using it for things other than crunching numbers.
For scripts, the JIT overhead has gotten a lot better, and I think it will continue to improve. The strategy is saving more so that it doesn't have to get recompiled on launch.
That currently doesn't happen for packages. Which means while R and Python run much slower, they feel much snappier -- and will be much faster if you're just running a bunch of short scripts that wont amortize compilation.
So in the short term, I wouldn't use Julia for speed.
Multiple dispatch and powerful meta-programming are two other major highlights.
Multiple dispatch can make for much simpler, cleaner looking syntax, while often making it easier to remember too -- you only need one name per concept.
I briefly compared explicit SIMD vectorization in Julia and C here:
https://bayeswatch.org/2018/08/08/matrix-multiplication-kern...
were I to change the vector size, all that'd take in Julia is changing the number of elements, and it'll dispatch correctly. In C...
I don't have too much experience with object oriented programming which gives single dispatch, but I like the separation of functions from objects, and freedom of dispatching on any/all of the arguments.
If metaprogramming appeals to you, Julia makes that really easy compared to many other languages, with things like the `@eval` macro or `@generated` functions.
Any sort of repetitive pattern that isn't easily expressed in array operations can probably be handled pretty simply with metaprogramming. I gave an example of `@generated` in the blog post with matrix multiplication kernels, and a great example of `@eval` is: https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...
In that link, ForwardDiff defines a gazillion function overloads for dual numbers for automatic differentiation.
Being an interactive language, plus the helpful macro `@macroexpand`, can make it easy to explore and figure out what's going on if you like playing with that sort of stuff.
I've heard loads of great things about Rust, too. Hope this helps decide if its worth looking at.
My examples were all still analysis-focused, but that's my experience.
Julia was designed initially with a strong focus on numerical tasks, but over the years, especially because of the focus on flexibility, Julia has very much become an excellent general purpose programming language.
The one domain I’d say it’s not suited for is embedded systems where you have very tight memory restrictions but I expect that to improve soon as well.
In the past when I’ve poked around with Julia, I used Emacs Speaks Statistics. If you’re familiar with using R in this context, you’ll probably find developing and interacting with Julia to be quite easy.
If the Julia community could manage to get Julia support into RStudio, I think we’d see a more accelerated uptake. I’ve heard rumblings that RStudio has at least thought of supporting Python in RStudio (more than they do now with R Notebooks). I can’t help thinking that if RStudio were to add support for an additional language, that Julia might be a good choice.
All in all I’d prefer to do data things in Racket or another lisp, but Julia feels good. I could see both the Python and R communities being tempted. Here’s hoping!
> All in all I’d prefer to do data things in Racket or another lisp
Do you have any suggestions/resources specific to this? I almost exclusively work with python but am starting to learn Racket (mostly just for fun). But if I could do some analysis in Racket, that would be awesome as well.
Not really. I mean, there's a whole lot of libraries that exist for Python and R that you just won't find outside Python and R. Certainly you can do many data processing tasks in Racket, but you just won't find Hasselblat-Hertzgeminer method (I made that up) available off the shelf for Racket like you might for Python or R.
But, I do find Racket to be a nicer language than R or Python. I like to imagine that Racket's best-of-breed support for building DSLs could yield a more expressive data / stats environment.
People always talk about the unassailability of Python and R in data science. But I think that's sort of defeatist. Not very many years ago people would have laughed at you if you suggested doing statistics with Python rather than R. Even though Python is still a long ways behind R in statistical libraries, people have built enough that Python too is viable for many things.
So too could Racket (or Julia!) become more useful than they already are.
I prefer many things about RStudio over Jupyter! I have two main issues with Jupyter (Notebooks).
First, Jupyter Notebooks don't facilitate working with revision control very well. Each time a notebook is saved, a new mess of JSON is belched out. I think the path to collaboration via revision control should be as easy as possible for analysts. This model of notebook is pretty hostile to making the jump to collaboration.
By contrast, RStudio's "R Notebooks" (supports more than R) are human readable, and git revisionable, with no loss of functionality as compared to Jupyter Notebooks. This is the same model that Emacs's org-mode uses for a document with embedded, executable code snippets.
Second, while Jupyter Notebooks can be an easy path for someone with no computer experience to get started, it's very hard to scale the environment up to writing larger analytic projects. The notebook model that Jupyter provides doesn't allow you to escape the notebook without ditching the tools pretty much completely and learning something entirely new.
By contrast, RStudio makes moving between notebook computing and more traditional IDE support for R scripts very easy. A thing I have done that is easy in RStudio (or Emacs org-mode):
- start building a plain R script with just comments
- convert to an R Notebook where I essentially add rich documentation
- once things start to get unwieldy, I start to factor out code from my notebook into more reusable project modules. I then let a notebook report be the "tip of the iceberg" where I still have the write-up of my analysis and embedded supporting evidence like plots and tabular summaries.
At this last evolution, my notebook is really just a UI for the outputs of my reusable analysis code. If I want to take things further I can:
- Move away from a notebook / document presentation of my results toward an interactive application via Shiny.
I just don't see any way that Jupyter Notebooks are any easier than RStudio's tooling. I also see that RStudio's tooling facilitates moving up and down through different more or less technical interaction models. Jupyter Notebooks by contrast are a brittle environment that pretty much dictates you stay within their walls or learn something else entirely.
Not the person you're replying to, but: almost all of them. RStudio is useful for more than just notebooks, as opposed to having to switch between an IDE for code and something else for notebooks. It has more affordances than Jupyter -- a full console, for instance. RMarkdown notebooks play much more nicely with version control than Jupyter notebooks.
As far as I know, the 1.0 release only removes deprecated features from 0.7, the previous “transition” release. So that probably didn’t require much incubation
What an incredible journey the team has had this far. A very approachable group of people involved with the project have tirelessly given their work to the Julia language and finally, FINALLY the 1.0 is ready for consumption.
As if I wasn't psyched for this weekend enough already!
