1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point.
2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package manager itself was rewritten to use libgit2, which has made it much faster, especially on Windows where shelling out is painfully slow.
3. Travis uptime. This is much better. There was a specific mystery issue going on when Dan wrote that post. That issue has been fixed. We also do Windows CI on AppVeyor these days.
4. Documentation of Julia internals. Given the quite comprehensive developer docs that now exist, it's hard to consider this unaddressed:
http://julia.readthedocs.org/en/latest/devdocs/julia/
So the legitimate issues raised in that blog post are fixed.
This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses.
Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...” or “the main technical complaints ...”
* * *
> [...] I certainly don't think that this is a major complaint at this point. [...] it's hard to consider this unaddressed [...] fixed
After reading the original post and your responses, I think the responses come across as pretty smug and dismissive.
Third-party readers would probably be more optimistic if you just left it at “we’ve made a lot of improvement since then and we’re still working on it” or similar.
I am part of a team that now has over 60,000 lines of Julia code in our computer algebra package(s), and the intersection between our experience as users and the points danluu made is almost nil.
If one looks at the ranking of the language on Tiobe, it's quite obviously being used a lot for a language that hasn't even reached 1.0 yet.
I think the issues one is likely to have with Julia as an evolving language have completely moved on from those made in danluu's article. In fact, it might be useful for someone to write a "constructive criticism" blog article about the state of affairs today.
My personal opinion is that I would wait until 1.0 (which will arrive in less than 2 years time) if I were a fortune 500 company, unless you really need to be ahead of the game and are prepared to contribute to the development of the actual language itself. But for just about anything else, if you need the features Julia provides, it's probably vastly superior to the alternatives today.
Our experience is you will occasionally have to adjust some of your code to handle changes to the language prior to 1.0, and we've had to do that a few times so far (at most a few hours work each 0.x point release, even with our large, complex code base). And this mainly applies if you are really pushing Julia hard and exploring interesting corners of the language. Other than this, its more than stable enough for serious work.
The language allows super-readable code while remaining quite fast. The sort of research I'm doing involves interacting a bit with data then doing a bunch of simulations, and Julia excels at this. The expressiveness in how Julia handles anonymous functions, optional arguments, tuple construction/deconstruction, etc. allows for really concise configurations of how my little simulations run.
My only pain points:
- DataFrames are not as fast as the rest of the language.
- I'd like an infix function composition operator. (Possibly this exists, but I can't find it in the documentation).
9.5/10, absolutely recommend.
Do you mean like the pipe symbol?
rand() |> println
Or are you referring to something else?Bugs are quite easy to come across and updating software feels more like a dice roll than a normal upgrade. Parallel computing in particular has been in a pre-alpha state for ages (which may be more of a documentation issue than an implementation one). Packages were previously very slow to load, though with pre-compilation this was partially fixed (~1 order of magnitude difference). I don't write robust software in julia, so I don't know how the error handling side has been evolving. The API inconsistencies have been getting fixed, but this typically results in broken packages until the compatibility package (Compat.jl) includes some workaround. The core code is difficult to get through and architectural-level documentation was absent last I checked.
Even with these development flaws it's still by and large an enjoyable experience to use. It solves some hard problems and it makes my own work (mainly DSP/ML) move a lot faster. I would recommend it, but as their versioning scheme indicates, there's no 1.0 release yet.
I'd rather try to fix a bug in some undocumented codebase than wait 6 months for a new black box.
Going through the post in order:
The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough idea, I now use julia daily and encounter a bug perhaps once every one or two weeks. In 0.4 I haven't encountered any bug which was a real show stopper and couldn't easily be worked around.
Testing has gotten a whole heap nicer with a decent test framework in Base (accessible in 0.4 via BaseTestNext.jl). Testing and package manager integrate in a simple but effective way which really makes the friction for writing a suite of tests for new packages very low, much lower than other languages I've used. I can't speak for actual coverage in Base, but I know it's now actually being measured and work has gone into the coverage tools.
I'm going to skip over the complaints about error handling, because others have already responded to this, for example StefanKarpinski's post to the julia-users list https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0Bzn...
Consistent benchmarking is currently being addressed, with great work going on at BenchmarkTrackers.jl, and a proper setup with dedicated benchmarking hardware for the language itself. I don't have the depth of knowledge to comment on Dan's other complaints regarding skewed benchmarking.
Regarding contributing, my experience is that contributions to Base and the runtime by unknowns (myself, say) are generally met with the fair skepticism and good taste that all good maintainers should display. Sometimes I feel the core devs could do more to encourage new contributors, and the environment can feel slightly hostile when suggesting new features. I'm not sure how to entirely avoid this, when a core job of a good maintainer is to say "no" to a lot of poorly considered requests! Much of the code in Base is still commented in a minimalistic fashion, if at all. In contrast my experience in contributing to packages has been almost entirely positive, with a lot of excitement and energy leading to some really great code and interactions.
With precompliation, slow package load times have really been improved to the extent that they're no longer a major hassle, but there's still room for improvement here.
The real sting in the tail of this blog post is the paragraph about nastiness in the community. There was a couple of unfortunately worded (though not unambiguously malicious) mails on the julia-users list following Dan's post, but the discussion was largely constructive and helpful. I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.
Overall I've found the julia experience almost entirely positive. It's a joy to work with for numerical and statistical problems, and we're moving forward at work to get our first major pieces of julia code into production.
I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with:
https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11
You can judge for yourself whether I was nasty or dishonest. Things were, unfortunately, not patched up. Dan posted a number of responses, deleted all of them before I could read them, then left the conversation permanently.
What I personally also find worrisome is the perception (at least for me) that Julia is confined to scientific computing whereas I find it should really be a general purpose language.
Now this turns up a terrible delima, do I try to use Julia or Rust for writing embedded controllers? Rust has macros and direct memory control, but the article mentions. :)
I also think the more of us that recommend Julia for general compute, the more likely it'll get used that way.
It is intentional. Julia could be the new Fortran like Rust could be the new C++.
With 1-based array indexing? Very unlikely.
I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.
http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here:
http://stackoverflow.com/questions/28078089/is-julia-dynamic...
Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have traditionally not cared about ensuring that return types are predictable based on argument types, and in static languages, a program is incorrect if that's not the case. As people care more and more about being able to statically predict the behavior of programs in dynamic languages, the concept of type-stability in dynamic languages becomes increasingly important.
"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.
really? There are quite a few things I don't like about julia, but using 1-indexing and "end" makes implementing algorithms much clearer IMHO.
The main pain points for me in julia are the module/pkg system and that the runtime is not just batteries but more like 10 generators included i.e. it could be way more minimal. But I get that the goal is to have a powerful scientific computing language and not to build a multipurpose language that emphasizes modular construction of code units and production ready package and build management utilities.
All in all, when judged by how well julia achieves its self-stated goals, I think it is excellent.
Guido explains his choice best:
https://plus.google.com/115212051037621986145/posts/YTUxbXYZ...
Congratulations to all involved in pushing the actual state of dynamic languages.
It's great! Looks like a very interesting contract.
Python uses it in the last couple of versions.