It's extremely expressive. Notably, Julia is homoiconic, with full lisp-style macros. It also has multiple dispatch, which is a far more general technique that OO single-dispatch. This makes it very easy to define modular interfaces that work much like statically-typed type classes in Haskell. This allows you, for example, to define a custom matrix type for your bespoke sparse matrix layout and have it work seamlessly with existing linear algebra types.

I've done a lot of work in both Python with Scipy/Numpy, and Julia. Python is painfully inexpressive in comparison. Not only this, but Julia has excellent type inference. Combined with the JIT, this makes it very fast. Inner numerical loops can be nearly as fast as C/Fortran.

Expanding on the macro system, this has allowed things like libraries that give easy support for GPU programming, fast automatic differentiation, seamless Python interop, etc.

I'm not sure how I feel about multi-dispatch...I've had a few headaches chasing down problems with multimethods in Clojure...I'd have to try using Julia full-time to see how it feels.

I was unaware that Julia was homoiconic...I'm somewhat of a Lisp fanboy so I might need to give the language another chance.

There's pretty big differences in usage between multimethods in Clojure and Julia. I've used both a decent amount. All functions in Julia are multimethods by default. If you don't use type annotations, a new method will be generated whenever you call the function with new argument types. This explicit type specialization is a very important part of why Julia can have such a consistently fast JIT despite its dynamicity.

Errors from missing or conflicting methods tend to not happen much in practice.

https://docs.julialang.org/en/v0.7.0/manual/methods/

> If you don't use type annotations, a new method will be generated whenever you call the function with new argument types.

Damn. That's a pretty clever trade off between dynamic and static types.

I vaguely recall a talk by Stefan Karpinsky where he mentions meeting one of the big names in compiler land (working on V8 or something) and they said Julia's JIT is just a lazily evaluated AOT compiler, and as a result much simpler than the JITs typically seen in other languages.

Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?

The difference is run-time (semantically) vs compile time. If you had overloading at runtime in C++, you wouldn't need virtual functions or any of the thousands of OO "patterns" (visitor, factory, etc.), that are working around the lack of this capability.

> Julia is homoiconic

It depends on what you understand by homoiconic:

https://stackoverflow.com/questions/31733766/in-what-sense-a...

This is why the language creators usually avoid using the word 'homoiconic' because every time one uses that word there's a finite probability of being bogged down in an incredibly uninteresting semantic argument.

Instead, people prefer to say that julia code is just another (tree-like) data-structure in the language and it can be manipulated at runtime with functions or compile time with macros or at parse time with string macros and now with Cassette.jl[1] we can even manipulate the form of code that has already been written and shipped by other packages all with first class metaprogamming tools. It seems to me that even if Julia is not 'truly homoiconic', that we seem to get the touted benefits of homoiconicity to the point that it seems like an unimportant distinction.

[1] https://github.com/jrevels/Cassette.jl

Then why not just say 'Julia has macros'? Lightly perusing the description of Julia's features, that seems like a clear way of expressing what it is.

(I also vaguely recall Julia describing its type system as "dependent" in way that goes against convention. Maybe they just liked controversy in the early days!)

What I just said is why Julia people don’t tend to call it homoiconic or dependantly typed. It lead to so many semantic arguments that most just talk about actual features such as macros and various multiple dispatch features instead of using words like homoiconicity and dependant typing.

"macros" are unfortunately used by C and lisp to describe two different things, and both usages are as widely popular as their parent languages (i.e. very).

That's a good point that it doesn't have the direct homoiconicity of Lisp, but it is not buried deep, since we have full access to the underlying AST as just an Expression type. In practice, this makes macros much less painful than in other non-lisp languages. This means that macros are used all the time, and idiomatically. The most proiminent non-lispy language with a macro system that I can think of is Scala. Macros there are a nightmare, and so tend to be only used in library code that really, really needs them.

I agree that macros are better than in other non-lisp languages, but I find them ugly in Julia. Maybe not painful, but they don’t integrate seamlessly into the language.

They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.

What's actually sad (I learned this quite recently) is that the inventor of Lisp wanted to include a mechanism to evaluate formulas along the lines of FORTRAN. Something like:

(math "x = sin(a) * b ^ 2")

Lack of something like that turned me away from Lisp (LISP at the time) a (cough) long time ago, since I didn't like the impedance mismatch between Lisp code and math for numerics.

At any rate, Julia looks like a fine general purpose language, I'm going to see if I can contribute somehow. I'm hopeful that GC pauses can be avoided for large classes of Julia programs, but we'll see...

Throughout Lisp history, this has been done.

(Let's not count things like computer algebra systems written in Lisp that have some sort of actual math notation for input and output, just alternative syntax for programming in Lisp itself.)

As early as 1973, there was https://en.wikipedia.org/wiki/CGOL

That can actually be made to work today: http://abcl-dev.blogspot.com/2010/04/cgol-on-abcl.html

Please don't vilify Python or R thinking that will help with Julia's adoption or popularity. If Julia is as awesome as its evangelists say, it will gracefully displace its competitors without the need of a smear campaign

Criticisms of languages should not be taken as criticisms of their creators or users. I don't see anything wrong with saying "Language X does Y better than language Z in my use cases."

Languages are toolsets and programmers are always looking for appropriate tools for a given task. It seems crazy to demand that people not be able to talk honestly about their experiences using a given tool. Python doesn't have feelings, it won't be sad if you don't like it.

Even if it does, what's wrong with stating an opinion? Why does an honest opinion have to be branded "smear"?

You seem to be suggesting it’s not fair to make superior comparisons to python until Julia has mainstream popularity. That’s rubbish. Python is much less expressive.

Python does have excellent libraries and it fits many people's mental model of programming, but not mine. I still use it often. However, for a dynamic language, it is simply not very expressive. It has no multi-line lambdas, OO syntax that I find a bit awkward, and some other limitations. These can be seen as advantages, since they enforce the "there's only one way to do it" philosophy, but that doesn't work for me.

Hmm ... I remember when Perl was king and Python was the shiny new thing. I watched Python supporters belittle Perl as "line noise" and other quite silly descriptions. They were all proud of "there is only one way do to it" versus the linguistic Perl way of "there is more than one way to do it."

I am experiencing something of a sense of schadenfreude over defense of Python against a newcomer. 20 years on, Perl is still in widespread use, still unbeatable for its growing use cases. I don't wish to speculate where Python will be 20 years from now. I do know that Fortran will still be around. That's about the only sure thing.

Wish advocates of all new languages stuck with this principle.

I wasn't being disrespectful of Python. We are allowed to criticize languages. The fact is, by any reasonable measure, Julia is more expressive than Python, which was all I stated. This is an advantage of Julia. Both languages have advantages and disadvantages, and comparing them honestly is necessary for people to make a good choice when selecting a language for a project. C is less expressive than Python or Julia, but no one would say C is a bad language based on that. And no C programmer would disagree with that statement.

It's not about putting any language or community down.

By your argument, it sounds like we cannot talk about any advantages a new language may have over existing ones. If we stuck to that, how could we possibly make any argument over why one may want to select a newer language?

Can you give concrete examples of where Julia is more expressive than Python? I can think of defining custom units https://medium.com/@Jernfrost/defining-custom-units-in-julia...

I give examples of expressivity in my comment above. The multiple dispatch is completely ubiquitous in Julia, being the default. This allows for the definition of flexible and extensible interfaces similar to Haskell's typeclasses. Macros are used to make things like PyCall or generate fast and flexible CUDA code.

This is not easily possible in Python, especially not with high performance.

In a nutshell: it combines the modern language features a CS person expects with the numerical excellence of Matlab.

Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really. If your job is writing web pages, Julia will be fine but it won't excel.

But if your job is writing trajectory planning routines for robots or climate simulations or so on, you aren't coming from those languages. You are coming from Matlab. Matlab has great libraries -- every numerical method under the sun. It has a very shallow learning curve. It's good for prototyping. But the actual Matlab language, as opposed to the toolboxes, is absolutely painful for writing programs longer than a few pages. As a numerical methods guy with a CS background, it literally makes me want to tear my hair out. It feels like writing in BASIC, circa 1989.

Julia can also have a shallow learning curve. If you want to prototype a couple of pages of numerical methods, it works nearly as well as Matlab does. But if you then need to expand that code into production, it can do that too.

> Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really.

Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps? Because if anything I find Julia's type system a lot more interesting from a computer science point of view than Python or Scheme.

If I want to get things done, I'd stick to Python for now though due to sheer momentum.

"Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps?"

Yes, sure. Julia is an interesting language, CS-wise. My only point, inasmuch as I had one, was that there are other languages out there that have those same features.

"If I want to get things done, I'd stick to Python for now though due to sheer momentum."

I tried python, because you're right, it has the momentum and is the obvious first choice for numerical computing after you've had your fill of Matlab. Unfortunately, for a lot of the code I write, speed matters. In large part I'm prototyping my own numerical methods, not totally relying on numpy/scipy. The last time I tried python for numerical code development I ended up with a routine that was two orders of magnitude slower than it needed to be. I rewrote the entire thing in Julia, with little to no effort towards optimizing it, and it was immediately 50x faster than python and within a factor of two of what I needed. I put a couple of days of effort into optimization and I got it down to 2-3x faster than required.

You could argue that I should have gotten better at optimizing python, and maybe you'd be right. I'm no python expert. But in my limited interaction with the python community, the answer to faster python seems to be, at the end of the day, to write the parts of the code you really need to be fast in C and call them with the python FFI. Which is what numpy does, if I understand correctly. Whereas I can write that same code directly in Julia and it's generally fast enough.

For a lot of use cases speed doesn't really matter. But for robotics (my field) or self driving cars or machine vision or a lot of other embedded applications, it does matter.

I was playing around at work with some galois field stuff (very cs) and was very pleased to find that the lu decomposition for Julia "just worked" with the custom galois field type that I implemented. All in all about 75 lines of highly performant code, which is what I needed because I was conducting searches over 2^32 elements.

Did you ever try Magma? I graduated in pure maths from University of Sydney where Magma was born. It was great for doing Galois theory stuff.

Does magma compile down to highly efficient code?

That's cool! What were using the galois fields for?

this was interesting to me:

https://www.youtube.com/watch?v=Gh578e98qAk&t=567s

To name a few: beautiful type system, optional typing, multiple dispatch...

edit: as another comment mentioned, metaprogramming is also great!

Julia is regarded as similar in syntax to python, or at least they have similar readability. What I love about it though (fyi not a CS degree person here) is the elegant way it handles types, and generics. User defined types perform just as fast as the built-ins, and I never seem to labor over design choices needed to generate fast computation.

Multiple dispatch is such a great way not to have to write boilerplate code for every method, somehow java seems very awkward in comparison.

Julia feels like a thoughtfully designed and carefully constructed language. I don’t havd the training to understand why exactly.

I really like the multiple dispatch design.