Hacker News Reader

Comment by eigenspace | Hacker News Reader

As an enthusiastic Julia user, I can definitely attest to this. It's frustrating to just want to share with people what you find cool about a language, only to be accused of being part of some astroturfing campaign, or for any discussion of the language being immediately derailed by people complaining about 1-based indexing.

Granted, there are definitely cases out there where Julia users have been overzealous and undersensitive when trying to convince others to come try out the language, but my experience with these people is that they're almost always coming at it from a place of just being excited about finding a language that works well for them and solved so many of their issues, and so they want to share that with others.

____

D is a cool language and it's a shame it seems to get ignored so much. I hope D people continue to work at it.

View on HN

I think Julia has a very bright future. There's no fundamental reason for Python to be so popular in the number crunching sector. I expect a lot of that to migrate to Julia over the next decade. Unlike D, I believe it has significant funding.

I used to think likewise, until NVidia and Microsoft decided it was about time to make Python implementations actually embrace JITs.

If all Python needed was a JIT, this would have been addressed over a decade ago. The problem isn't a lack of a compiler, it's language semantics that make the job of a JIT nearly impossible.

The usual urban myth, ignoring JIT work in language semantics like Smalltak, Common Lisp, SELF, where anything goes and the whole process space can change in a method call.

JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy.

NVidia and Microsoft had to come into play to change this.

None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism.

In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.

This is not the case with Python, Smalltalk, Common Lisp, etc.

To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.

Python's semantics make both of those prospects incredibly dubious.

So I am lost, are talking about Python JIT compilers or C performance?

Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.

Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code.

At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support.

The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.

Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries.

They are as much Python as they could be Tcl.

Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.

> So I am lost

Me too.

Do you wish to suggest that Smalltalk implementations had "C performance" ?

Do you wish to suggest that some Smalltalk programs should still be a little faster than corresponding Ruby +YJIT programs ? (But then NodeJS.)

Do you wish to suggest that Ruby +YJIT programs should be faster than corresponding CPython programs ?

That person seems to just think that so long as the JIT is kinda fast, it's good enough. But that's really not the world we live in most of the time, especially if using that JIT broke binary compatibility with existing fast libraries.

I suggest that any JIT implementation will be faster than CPython default install, including the old ones at Xerox PARC, Genera and TI.

Calling out to C libraries doesn't count for CPython performance, that is C code, not Python, and any language with FFI can call into C libraries.

In context, something like: Julia won't take over because someone will make a sufficiently performant JIT for Python ?

(Name dropping ancient language implementations was confusing to me, and I'm ancient.)

There was a Python JIT a decade ago - Psyco [1]. It was/is a lot faster than normal Python. The community, however, decided to go down the PyPy route.

[1] https://en.wikipedia.org/wiki/Psyco

There's a gigantic graveyard littered with dozens of abanoned Python JITs, Psyco is hardly unique. The community has not at all gone down the PyPy route, nobody uses PyPy either, even if it's technically not abandoned.

There's little reason to think these new JITs will fare any better.

According to benchmarks, JIT implementations are still very slow.

It suffices to be on par with other dynamic languages with a JIT.

I am also curious how Mojo will turn out, from the last LLVM developers conference talk, it is quite interesting after all.

Python doesn't need JIT, python's strengths is "it's interpreted", therefore it runs everywhere without having to compile anything in one go, JIT is only useful for servers and long lasting processes, python doesn't fall into that category

At best it needs an AOT compiler, to accelerate final scripts, and that's where projects like Mojo start to become interesting

I think biggest Julia problem is deployment and focus on Academia/HPC, its nice language and pretty fun to write, but it seems to be not good enough to replace Python and lost tons of momentu from hype train in 2017-2018?.

Julia still have a sucess story and is a lot bigger compared to D.

Julia is the only programming language that makes me annoyed when I think of it, because it was so troublesome to package for Arch Linux and because of how little they care about increasing the safety in the language (like Rust or Ada).

What made Julia so difficult to package? I'm genuinely curious.

> ... because of how little they care about increasing the safety in the language (like Rust or Ada).

I think it's a bit harsh to compare Julia to Rust on that front. Julia has completely different design goals. Compared to Rust's borrow checker and C++'s move semantics, Julia's immutability-by-default (+ clever compiler optimizations) gives a good trade off between performance, safety and ease of use. While Rust goes for safety + performance, Julia goes for performance + ease of use (respectively dynamicity).

Nevertheless, I miss some features related to type driven development in Julia, which would improve safety:

  - A newtype idiom
  - Sum types
  - Explicit, type-checked interfaces : I actually would prefer something like C++20 concepts (a blacklist approach) to Rust's trait (or typeclasses, a whitelist approach), because it would be a better fit for Julia's design goals.

The main problem with packaging julia is that it requires a custom version of LLVM (since LLVM ships breaking versions every 2 years and doesn't do downstream testing for projects other than Clang). Lots of linux distros have repeatedly tried shipping Julia with random LLVM versions and as a result, shipped broken Julia versions to people.

Reply on news.ycombinator.com