A review of the Julia language (2014)
danluu.com
danluu.com
Over the past few weeks I've been evaluating Julia as a potential R replacement. IMO, it's definitely not there yet. I've run into bugs, crashes, hangs, sluggish performance, packages that won't load in 1.0, a clunky REPL, and a lot of code that I can't trust has been as well peer reviewed as what's in Base R. It'll take me a couple months but I plan to write a blog post on my experience, and I'm no Dan Luu ;)
That said I like the design of Julia, and the mission or promise as I call it could eventually make Julia an R replacement (as well as a replacement for lots of other languages). I started using R in 2001-ish, and at the time I remember thinking no way would I switch to R from SAS. Today I laugh at that, but that's the difference that 15 years will make. Julia is still very young. It's advantage is the modern design. R is entrenched and robust, but let's face it, it's design is ancient, rooted in the Fortran-and-card-punch era, and there are things (eg. multithreaded) it will never do.
Julia is at a crossroads: the core developers are eager to listen to the community. Whether the devs can maintain grasp of their vision while still delivering what the community wants is yet to be seen. They're being pulled in a thousand different directions, based on everyone's desire for what they want out of Julia. This could end up a disaster if the devs don't stick to their vision. Even though it's not good enough to replace R for my daily work right now, I plan to keep using Julia and contributing, because in 5, 10, 15 years, perhaps I will feel about R the way I feel about SAS today.
I couldn't complete the installation, it gave a weird error "windows cannot find -v".
Nothing came up on forums or the internet, so I gave up on trying to learn Julia.
At exactly the same time, a lot of people thought "hey, 1.0 time to check out this new language", and would experience all those crashes.
Doing a review of Julia based on the experience in the first month after 1.0 will be grossly misleading. I've used the language progressively more for the last 3 years, and also teach a university R course, so I have some experience to base that claim on.
(But I guess there are various pressures, not to delay, too.)
This is definitely a fair point and a main reason I am not rushing to judgment after trying Julia for just a few weeks. I like the language already, and fully realize there is a lot of hard work going on among package maintainers to adjust to 1.0. My main advice to anyone trying Julia is to take the long view. It's still very young so look past the rough edges to its potential.
I think its a real shame this out of date grievance article is being dredged up again giving people a myopic view of what Julia 0.4 may have been like in 2014 when its now 2018 and we have v1.0.
Zero-based indexing of arrays makes sense in a language like C where arrays are just pointers and offsets are determined with arithmetic on pointer addresses in memory. This is why we are trained to write code like "for (i = 0; i < n; i++)". But in Julia where one of the stated purposes is to be able to write code that looks like formulae, it is far more natural to use one-based indexing.
For the right reader (early-stage language devs) this is a great resource. It's like an archaeologist uncovering a 10,000 year old pot. Sure it's not relevant to most users of pots today, but makers of pots could maybe learn something from it.
[1] https://news.ycombinator.com/item?id=8809422 [2] https://groups.google.com/forum/#!topic/julia-users/GyH8nhEx...
In terms of names, we do care a fair bit in trying to pick intuitive names that clearly communicate what a function will do.
FemtoCleaner also will auto update your code for these breaking changes, by making a pull request to your repo.
How long will Julia keep its backward compatibility? Based on the history, I suspect that in five years, Julia will release v2.0 and break a lot of user code again. Hope I am wrong here.
TLDR: if there aren’t breaking changes it won’t be called 2.0 it will be called 1.12 or something like that.
Go is currently planning their 2.0 release precisely so that they can make breaking changes. It was a big deal when they reached 1.0 for exactly the reason that they stopped making breaking changes. Ditto with Rust. We are following the exact same course. If it feels different, that’s because you weren’t using either language pre-1.0.
See also the Python 2 vs 3 transition and Ruby 1.x => 2. Comparing with Perl5 is ignoring the huge changes made in Perl2, Perl3, Perl4 and Perl5, not to mention Perl6.
That leaves Java and C++. Yes pre-1.0 Julia was more breaking than those two, ancient, industrial warhorses.
Julia has taken a similar albeit less automatic approach with deprecation warnings. When a breaking changes have been made, in one major release it continued to work but issued a warning telling you how to change your code. Only in the following major version did the code actually break. This allowed people to upgrade, run their tests (you have tests, right?), fix the warnings and be good to go.
More recently FemtoCleaner [1] has been introduced, which automatically makes PRs to projects and upgrades them just like "go fix" does. When we release Julia 2, we'll use a similar approach, so if your happy with how Go is doing things, you should be happy with how Julia does them.
It's fairly straightforward to avoid the Python 2/3 debacle, they key is to always allow packages to support two "adjacent" major versions at the same time, so as to not cause "upgrade deadlock" [2].
[1] https://github.com/JuliaComputing/FemtoCleaner.jl
[2] https://discourse.julialang.org/t/1-0-adoption-path/7922/39
Even now, there are some fanatics.
Hopefully people go to GitHub or discourse.julialang.org or julialang slack and try out for themselves.
Two of the people who look the worst are co-founders of Julia. Are they not involved with Julia anymore?
Dan's representation of things is wildly misleading. We worked with him extensively and even had him over to a 4th of July party the year that he was working on Julia stuff. Dan wrote a fuzzer and found a lot of obscure but not practically important bugs, almost all of which were nevertheless fixed quickly. He also found a few other less obscure bugs which were also fixed, usually within a few hours. He made a number of fixes himself as well, for which we were and still are greatly appreciative.
Dan had complaints about various things about Julia at the time. He was in the habit of emailing me directly about them. This is not great form in open source, but we were personally acquainted so it was fine. However, since I didn't have the knowledge or time to fix most of these issues, I generally encouraged him to post them on julia-dev or GitHub. As I recall, he usually did not.
As this continued, I encouraged him to write a constructive blog post about what he thought could be done better. Instead, he wrote a gotcha piece—the one posted here yet again—that implied that we don't care about bugs or software quality and had ignored or dismissed issues that he'd reported. He had been studying what kind of content does well on HN and how to get on the front page [1], and it's tempting to speculate that he knew that a dramatic criticism would get much better traction than a fairer critique.
[1] https://danluu.com/randomize-hn/
Shortly thereafter, in a semi-private forum which I was also on, he wrote a lot of significantly less kind things about about us. I responded to his semi-private "shit talking" in what I still think is a measured fashion. He did not appreciate the pushback and amended his formerly glowing review of the Julia community to what you now find in his blog post. I am the "core dev" that Dan is obliquely referring to. In retrospect, I guess I shouldn't have pushed back at all and just let it go. But having someone who you have gone out of your way to help and showed every hospitality and kindness to, then turn around and talk smack about you in a place where they know you'll read it, frankly really sucks.
The language has changed (for the better) soo much since 2014.
I'm sure there's more up-to-date reviews that could be more useful...
...replace that "or" with an "and". Python is unavoidable, and it makes no sense not to become proficient at it unless you already know another language usable also as a "systems scripting language" (eg. Ruby or Perl).