I've been using R for years. A month ago I tried to port a program we use that takes 20MB CSV files and finds trends. In R, it would take around 5 second to read the file and give me my data. In Julia it took 30 seconds.
How did you load it? CSV.jl and TextParse.jl are the go-to fast ways to load CSV data. They used to be trying to catch up with Pandas which was the fastest CSV parser, but now I think they're in a friendly arms race with each other, having passed Pandas CSV parsing half a year ago.
Julia is a good language for computational simulation experiments but in a world that's heading towards heterogeneous compute enabled by GPUs, TPUs and intermediate representation languages/frameworks like ONNX, TVM [1] and Tensor Flow its difficult to take claim of "Language for Modern ML" seriously.
If you disagree please show me how many ML researchers/labs/companies use Julia over Python/C++. Its cool to claim "Modern", "Deep", "ML", but I don't see any evidence.
What's strange to me is that as people watch this transition in ML technologies, they can see and accept what's right in front of them but can't see what's coming next. There's growing evidence that that ML/AI is a programming language problem – that's why all kinds of new IRs are being created for ML frameworks, as you say. But these are never going to be good to program in directly, so the next obvious step is to put a really nice, general purpose surface syntax on them. Once you start thinking about what that surface syntax should be like, you quickly end up with something very similar to Julia. People don't seem to be connecting the dots just yet.
In some sense ML people are working from the bottom up while Julia is working from the top down. ML/AI frameworks are starting to put better IRs on top of their low-level codegen. They haven't gotten to the surface syntax part yet because they're just starting on the IR – but they will, because that's the next logical step. Julia, on the other hand, is working from the top down, starting from a really nice surface syntax that's excellent at codegen. First it has targeted CPUs, now GPUs, and in the future TPUs, Nervana chips, FPGAs, etc. It's already possible to target all kinds of different hardware with the same productive, generic high-level code. Which approach do you think is going to end up with a better, more productive developer experience in the long run?
We live in an age of libraries like cudnn which are vendor provided/optimized, for 99.9% of ML applications you won't need to write custom CUDA code. Further as I mentioned earlier with Intermediate Representation languages like TVM you are guaranteed to get the best underlying constructs across different computing architectures.
Julia might still be good enough MATLAB replacement for Computational Simulation style tasks, but its clearly not suited for Machine learning.
That's true when you're lucky. But if you're someone who does package development and methods research, you're usually not lucky. This is why pretty much all of the top / mainly used Python packages have lots of C++ and Fortran in there. As someone who develops algorithms rather than just using packages, I found this to infringe on my productivity in Python, whereas making Julia packages "production-quality" is straight forward, so even with the smaller userbase I think it's worthwhile to develop in Julia instead.
There are a lot of articles about Julia being the language of everything. I gave it a try but did not like the syntax. Why would anyone prefer it over other languages?
It's like Matlab or SciPy in terms of how easy it is to set up a quick script, but far more performant.
The syntax is fairly similar to Matlab, which makes it familiar for engineers like me.
And then there's the speedup. For one benchmark I wrote when evaluating the language, it had a 60x speedup over Octave, but I'll have to see what happens when I finish porting over all of my code.
I found it was a lot like my experience with Python and its indentation. First it seemed weird, but then I quickly got used to it and ended up appreciating it. A lot of careful thought actually does go into the design of the Julia language, and they take the ergonomics of the language very seriously.
The type system is really well thought out, its easy to write generic code with parametrized types. User-defined types are first class, so the conpiler provides the same performance benefits for those.
Matrix operations are good, and functions can be arguments. Macros are cool, code can be generated at runtime which can be very elegant in the right uses.
This is the language you want if you are reading a research paper and want to implement the mathematical formulas directly from the paper and still have good performance.
Its a serious high performance computational language, but somehow accessible and not arcane.
It's statistics in a funky new dress, and about as required for programmers in general as math-heavy type systems or in-depth concurrent programming.
But it's something in the webapp world that isn't just about massaging strings and reports or connecting libraries, so people flock to it both for resume-padding and much-needed variety.
No, it will be totally irrelevant in 5 years (as a career buzzword), to be replaced by the next fad -- like the 5+ fads that preceded it while I've been in IT (grid computing anyone? clusters? J2EE? How about ...transputers).
I studied this at university and have not yet had any use for it. I work with systems doing computer visualization but almost never write graphics code. Most programming is more about integrating specialized stuff made by experts in a field.
I also studied this at university. It turned out I graduated ten years too early, nobody had data or willingness to use it, and now that things have changed my resume is full of Java crap.
as usual, if you think it's fun/interesting and something you'd like to do more in the future - go for it, there's more resources now than ever.
if you couldn't care less and just want to be able to earn your bread - AI won't take your bread unless you're an uber driver or a customer support employee
Is this a common occurrence?