Live data from Hacker News

Julia 1.9 precompilation will be a turning point

twitter.com

11–17 of 17 posts

Re: Julia 1.9 precompilation will be a turning point

#13
post #4

I don’t understand how this wasn’t already implemented, it seems like such low hanging fruit

To elaborate on the sibling comment: Julia has (1) multimethods / multiple dispatch capabilities, (2) you can dynamically define new types and methods at runtime, (3) everything is aggressively devirtualized/compiled to machine code when possible. That requires the capability of discarding and recompiling code that has already been compiled and cached when a new method is defined at runtime. Worse even, just importing a new library might invalidate some of the compiled cached code. For me, capabilities 1,2,and 3 make the cost of a complicated compilation model worth it. But it also means it takes a lot of time to improve the compiler (this type of better caching was not at all a low hanging fruit).

Re: Julia 1.9 precompilation will be a turning point

#14
As package developers we need to optimize our packages for 1.9. It's quite a task but I am excited what's ahead in Julia. Matlab(is not open-source, R is slow and not really a general purpose language, Python is great but same issue 2-lang problem...why should I implement CUDA in C++ or Numpy in C. I want to be able to modify lower back-end code but with Python it's not possible. Julia fixes all of these problems and I am quite happy I invested my time in Julia. Present/Future is bright :)

Re: Julia 1.9 precompilation will be a turning point

#15

As package developers we need to optimize our packages for 1.9. It's quite a task but I am excited what's ahead in Julia. Matlab(is not open-source, R is slow and not really a general purpose language, Python is great but same issue 2-lang problem...why should I implement CUDA in C++ or Numpy in C. I want to be able to modify lower back-end code but with Python it's not possible. Julia fixes all of these problems and…

Thankfully my GPU programming is shadet related, thus I don't have to deal with all the compute issues, however a good decision of CUDA from early on was to have PTX.

GPGPU needs more languages that make it easier to do compute with feeling like doing Assembly.

Basically the productivity that can be understood by reading stuff about StarLisp and the connection machine.

Julia seems a nice addition to this idea.

Re: Julia 1.9 precompilation will be a turning point

#16
post #4

I don’t understand how this wasn’t already implemented, it seems like such low hanging fruit

The Julia compilation model is fairly complex, due to the Julia user's wish for dynamic capabilities combined with common features in statically typed languages. Although it may appear so, it was not low hanging fruit - it took a lot of effort building incrementally over several releases by a number of contributors.

In retrospect, how essential was it that Julia went the dynamic route in the first place (as opposed to taking a Haskell-like approach to inferred static typing)?

Re: Julia 1.9 precompilation will be a turning point

#17

Earlier quoted context omitted.

The Julia compilation model is fairly complex, due to the Julia user's wish for dynamic capabilities combined with common features in statically typed languages. Although it may appear so, it was not low hanging fruit - it took a lot of effort building incrementally over several releases by a number of contributors.

In retrospect, how essential was it that Julia went the dynamic route in the first place (as opposed to taking a Haskell-like approach to inferred static typing)?

It's a pretty major difference. Julia lets you write code that the type system doesn't understand, while in a static functional languages you generally have to explain a decent portion of category theory before someone can start writing code that passes around functions. (For a simple example, what is the type of `+`, and does that type allow you to make Int+Float=Float?)
Post reply on HN