Hacker News Reader

Hacker News

Comment by marmaduke | Hacker News Reader

Parent Full thread

marmaduke

> do not play nice with other python libraries.

Julia hasn't been around long enough to build ecosystem with multiple commerical giants building competing products.

> Julia does not make that sacrifice.

Sure, Julia sacrifices your sanity on the alter of stack traces, method resolution, time to first plot, among others.

> fairly limited subset of python

Fantastic comment, always brought up, except that this same subset of Python (really how to use CPU efficiently) is about the same that anyone writing about Julia performance is preaching.

View on HN

I think a really good example of how Julian tools are composable and work with the whole of the language, while that is not the case with Pythonic tools, is autodifferentiation. The many different julian autodiff libraries have little trouble performing the autodiff through special functions, weird data structures, and 3rd party libraries. In python, none of the autodiff tools play nice with scipy or with mpmath or with sympy (or qutip, which is something I need). This is not about commercial competitors either - all of the libraries I mentioned are non-commercial.

Julia provides the interoperability between such libraries, including custom datatypes, frequently with fast zero-cost abstractions.

I agree but think that Julia had the benefit of watching Python and MATLAB suck at auto diff and do better as a community. That said PyTorch and Jax are great.

> fast zero-cost abstraction

Until you get a compiler error and the stack trace takes up a few screens of text. Who maintains that abstraction by the way? Nothing is free.

>Fantastic comment, always brought up, except that this same >subset of Python (really how to use CPU efficiently) is ?about the same that anyone writing about Julia performance is >preaching.

This is completely and demonstrably false. Julia allows fast programming with macros, multiple dispatch, abstract types and more.

All those features have a cost that, in a performance oriented setting, require restricted the code to a subset of Julia that matches what the hardware is fast at.

Where are you getting this from? None of those features have a performance cost, if used according to some simple guidelines.

In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures.

Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance.

I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.

No, that's not true. I specifically mentioned features that can easily be made zero cost on both CPU and GPU targets.

In fact, those aren't special features and there is no other subset. Those are the core abstractions on which everything in Julia, down to primitive types and wrappers for llvm intrinsics are built. Without them you wouldn't have Julia.

Julia's GPU ecosystem wouldn't be where it is with just one or two people maintaining it without being able to reuse those features to plug into existing machinery.

I beg your pardon. What parts of Julia are not supported by its jit compiler?

Reply on news.ycombinator.com