10 ms·

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

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.

tombert 8y ago
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.
- lenticular 8y ago
  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/ https://docs.julialang.org/en/v0.7.0/manual/methods/
  - nicoburns 8y ago
    > 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.
    - vanderZwan 8y ago
      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.
  - tombert 8y ago
    Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?
    - KenoFischer 8y ago
      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.
you_owe_me 8y ago
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
- b_tterc_p 8y ago
  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.
- lenticular 8y ago
  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.
- dman 8y ago
  Wish advocates of all new languages stuck with this principle.
  - lenticular 8y ago
    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?
deleted 8y ago
[deleted]
kgwgk 8y ago
> Julia is homoiconic It depends on what you understand by homoiconic: https://stackoverflow.com/questions/31733766/in-what-sense-are-languages-like-elixir-and-julia-homoiconic/31734725#31734725 https://stackoverflow.com/questions/31733766/in-what-sense-a...
- lenticular 8y ago
  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.
  - kgwgk 8y ago
    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.
    - lenticular 8y ago
      They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.
      - Recurecur 8y ago
        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...

tombert 8y ago

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.

lenticular 8y ago
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/ https://docs.julialang.org/en/v0.7.0/manual/methods/
- nicoburns 8y ago
  > 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.
  - vanderZwan 8y ago
    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.
- tombert 8y ago
  Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?
  - KenoFischer 8y ago
    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.

you_owe_me 8y ago

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

b_tterc_p 8y ago
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.
lenticular 8y ago
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.
dman 8y ago
Wish advocates of all new languages stuck with this principle.
- lenticular 8y ago
  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?

deleted 8y ago

[deleted]

kgwgk 8y ago

> Julia is homoiconic It depends on what you understand by homoiconic: https://stackoverflow.com/questions/31733766/in-what-sense-are-languages-like-elixir-and-julia-homoiconic/31734725#31734725 https://stackoverflow.com/questions/31733766/in-what-sense-a...

lenticular 8y ago
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.
- kgwgk 8y ago
  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.
  - lenticular 8y ago
    They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.
    - Recurecur 8y ago
      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...