Julia holds a lot of promise: the next 5 years will determine whether it can deliver on its quest to solve the two language problem.
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.
An important thing that many people fail to realise is that Julia-1.0 came as a surprise to package authors as well, and thus the first month of the the release has been a scramble to get everything working on 1.0. Unfortunately the pre-1.0 package manager did not have good facilities for upper bounding versions - so essentially everybody's packages would install on 1.0 but be broken.
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.
> Doing a review of Julia based on the experience in the first month after 1.0 will be grossly misleading.
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.
Yes, the package situation seemed much better 6 months ago, on v0.6. Because so much changed in v0.7, it would (IMHO) have made sense to release 1.0 alongside v0.7.1 or something.
(But I guess there are various pressures, not to delay, too.)
The article argues that while the language is way cool in principle, the current implementation is bug-ridden and has poor error-handling. But as the HN title acknowledges, the article was written in 2014, when the Julia version was only 0.4. Since then it's been four years, and Julia only recently hit 1.0. It would be much more interesting to see an article discussing the current state of the language.
I've been using Julia seriously for the last year and I'm absolutely loving it. The language is beatiful, elegant and fast and the community has been nothing but friendly, helpful and welcoming to me.
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.
I used Julia for my thesis work in 2015 and also came away with "nice, but dealbreaking bugs, two in particular." They were both fixed by 2016. Julia is moving way too fast for a years-old opinion to mean much.
Most people using Julia today weren't using Julia in 2014 because we didn't think it was ready. That should tell you how relevant Julia v0.4 is to modern Julia.
It is the year 2048. A hacker news veteran presses enter to fulfill her duty and reposts the sad story about Dan Luu and the Julia community. A greyed Stefan Karpinski tries to object but his statement disappears behind thousands of Dijkstra postings. In the distance the voice of the zealots, chanting 1-based, 1-based...
The joke is that criticism of Julia is always the same: (1) Dan Luu's bad experiences in 2014, (2) some "giving up on Julia" blog post from 2016, or (3) bikeshedding about 1-based indexing. And when the discussion revolves around 1-based indexing, Dijkstra is almost always cited to prove objective superiority of 0-based indexing.
Controversies about this blog post and about Julia's 1-based arrays on HN often replace serious discussion about the programming language. Stefan Karpinski is one of the inventors of Julia, Dijkstra wrote a classic note in favour of 0-based indexing.
In math when we write a sum, we say "sum from i = 1 to n", not "sum from i = 0 to n-1".
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.
Sure I get that. MATLAB and FORTRAN also use 1 based indexing, so that's nothing new. People have been arguing about that since 1950 :P I just didn't understand the context of the post.
There's a lot of value here for anyone who does language design and development. It's important to see the challenges early language projects face, how users respond to them, and how the community responds in turn. If you examine this piece not from a perspective of the language wars or a language user, but from a perspective of "What can this tell us about what challenges early languages face" then this is a very good article. At its core, this article is about someone who was interested in a language, used it enough to find many bugs, found the motivation to write a blog post about it, and the community and devs responded in good and not so good ways.
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.
Beyond the state of the Julia Language (which I am excited to try out since 1.0), the core community comes off really badly in this post, and the previous follow-up discussion on HN [1], and julia-users group [2].
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.
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.
I didn’t make as much as effort as the writer of the post, but I had several negative interactions when trying pre v1 releases. This was far more discouraging than questionable code quality.
IMHO, one of the worst things Julia had done was to unnecessarily break so many backward compatibilities (e.g. renaming shift!() to popfirst!() – who cares? and how many user code this will break!). As a result, a great portion, if not the majority, of Julia tutorials online are not applicable to the latest version any more. This leads to a lot of headaches when you learn Julia. I know v1.0 is supposed to be stable, but their track of record makes me doubt. I will see what they do to v1.1 and then decide if it is worth learning.
Older languages like C/C++, Java, Javascript and Perl5, regardless of their versioning schemes, have been mostly stable for decades. There were minor breaking changes from time to time but the language cores are largely compatible backwardly. Newer languages like Go is on a similar path. This is what we need for a programming language.
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.
Which versioning scheme to use doesn't matter. What matters is how long you promise to keep a language "stable". Java and javascript have gone through many major versions, but the core of the language is largely stable. The same will be true to golang. Read their plan [1], the paragraph starting with "Go 2 must also bring along all the existing Go 1 source code". That is promised backward compatibility. There have been breaking changes in Perl5 (so it is not following semver), but most of the changes were minor and little user code was affected. Python 2=>3 is a disaster. If Julia goes through a dramatic change like that in 5 years, it will be worse.
When they write "bring along" they do not mean "Go 2 will be backwards compatible with Go 1". Pre-1.0, Go extensively used "go fix" to automatically upgrade older Go code to newer versions. (If they had never introduced incompatible changes as you seem to be claiming, this would not have been necessary.) They will most likely do the same thing for upgrading code from Go 1 to 2. Although that alone is likely to be insufficient as the failure of py2to3 demonstrates; they will probably need to also support using Go 2 packages from Go 1 or vice versa.
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].
I will ask this more explicitly: how soon will you deprecate features in 1.0? 2 years? 5 years? 10 years? Go 1 is 6 years old and Go 2 seems at least a few years away, and the paragraph I was referring to says "Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years.", which suggests they will keep the Go 1 compatibility for "multiple years" after Go 2 kicks in. That adds up to 10 years. If Julia can promise to keep the vast majority of 1.0 features around for 10 years, I will be good with that.
For Perl you are forgetting the HUGE amount of code that just works 10-15 years later. I love Perl for many reasons but here is where most other languages gets killed.
Older languages also had to exist in a much less networked world. The more 2.0 changes can be done by a robot making a PR, the less concerning they will be.
This is clear FUD. The developers directly stated with previous releases that backwards compatibility wasn't a top priority, and things weren't backwards compatible. Now with v1.0 the statement is that the language is far enough that it is a priority. Why would past telegraphed instability be indicative of future untelegraphed instability? There have already been multiple proposals shut down due to backwards incompatibility since the v1.0 release, so developers are clearly taking it seriously given the comments in the PRs.
Could you please point to some newer reviews that you trust? I'm trying to get a sense for myself whether I should invest my time learning Python or Julia.
...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).
I would really love to see what happened since the article, since I, personally, stopped using Julia around the same time (unrelated to the article) and only followed the announcements (e.g., of hitting the 1.0 milestone). I would love to know if the outside view ("it improved / matured a lot") is the true story.
Julia seems to be quite different. I will say "seems" since it can be hard to find someone who's been around since v0.4: most people joined the community long after. 2016 had a "third generation" of Julia developers join in, and there's a been a boom in the package ecosystem around that with high retention rates from GSoC.
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.