I toyed around with it for a while, and really liked it. I wondered to myself "what makes this language specific to numerical computing? it seems generic enough to be used wherever I'd want to use Ruby or Haskell..."
But then I tried using it. And even though the language is generic enough, the standard library just plain assumes you're only doing numerical computing, and makes everything else needlessly hard by trivial omissions.
That was like 2013 though, so maybe things are different now?
Interesting, I've had the opposite reaction. I find it to be about the nicest programming language to work with. I even started writing a little toy database in Julia, and find it really easy to reason about.
Package management system is its only weak point IMO. It makes a lot of counter-intuitive decisions (having to build a package from the packages directory? that's just strange). Cargo / Bundler to me feel like the gold standard in package management... most alternatives I've seen would be better off just copying those workflows unless there's a really good reason to try something new.
I haven't used Julia for any big projects but I routinely use it for small projects or utilities. I have used it for:
1) Obfuscating source code
2) Reading and presenting iOS provisioning profile data
3) Simple social science related simulations ported from Ruby or Python.
4) Code completion plugin for TextMate
etc
So no huge projects, but I found Julia to be a very nice and versatile language to work in. I find I can write code which is clearer than its corresponding Python and Ruby version and which has less bugs because type info is a bit more explicit, but without getting too much in the way as is typical with statically typed languages.
I tried Haskell for some of the same projects, but I got to say Haskell takes way longer time to get proficient in. For the stuff I did I also found the way the Julia type system worked, made code reuse much easier than Haskell.
E.g. with the Julia Union type it was possible to define individual function across multiple specific types. E.g. I could make a particular implementation of f apply to type A, B and C, while another particular implementation of f applies to D and E. Function g could have a specific implementation of A and E. While another implementation of g is used for B and C.
While numerical computing is the first target, that's definitely not the sole goal of the language, so if there's something simple that you feel is missing, I would be very curious to know what that is.
I was really REALLY interested in the language due to the clustering ability and their JIT they build into it. But it does seem like the language was build without any systems-usage in mind. How sad. Nothing will ever quench my thirst for clustering.
I toyed around with it for a while, and really liked it. I wondered to myself "what makes this language specific to numerical computing? it seems generic enough to be used wherever I'd want to use Ruby or Haskell..."
But then I tried using it. And even though the language is generic enough, the standard library just plain assumes you're only doing numerical computing, and makes everything else needlessly hard by trivial omissions.
That was like 2013 though, so maybe things are different now?