Quoting the conclusion:

————

Julia, like Dylan and Lisp before it, is a Goldilocks language. Done by a bunch of Lisp hackers who seriously know what they're doing.

It is trying to span the entire spectrum of its target users' needs, from numerical inner loops to glue-language scripting to dynamic code generation and reflection. And it's doing a very credible job at it. Its designers have produced a language that seems to be a strict improvement on Dylan, which was itself excellent. Julia's multimethods are type-parametric. It ships with really good multi-language FFIs, green coroutines and integrated package management. Its codegen is LLVM-MCJIT, which is as good as it gets these days.

To my eyes, Julia is one of the brightest spots in the recent language-design landscape; it's working in a space that really needs good languages right now; and it's reviving a language-lineage that could really do with a renaissance. I'm excited for its future.

This is a bit broader a point than the original post of "why you should use Julia", but bear with me. Basically, most languages (and even more generally, most tools) assume that you'll have external ways of dealing with their limitations. For example, we use slow but productive languages in conjunction with fast but tedious languages. Or we have a DSL for testing. Or we have a 3rd-party package manager. The assumption that these external tools will be there is generally true, plus it makes the language designer's job easier, so it's generally a no-brainer for them to make it. However, this pushes the complexity onto the system and the user, and creates redundancy.

There have been some attempts to forego this assumption and make a language that can do everything you need. This has led to the creation of Lisp, Forth, and Smalltalk, among others. (If you've ever wondered about the fanaticism generally associated with these languages, this is a major part of it.) Julia is attempting to be such a language, and in my opinion does a pretty good job of it.