Hacker News Reader

Comment by osalberger | Hacker News Reader

Right. Julia is looking fairly promising as a "real" programming language that is still an excellent Matlab replacement, and possibly to a lesser extent an R replacement, and it does show that there is nothing about filling the exploratory math programming niche that requires it to have the warts that the incumbents have.

Fundamentally, R and Matlab are probably best comparable to Perl in terms of how they got popular. While they are rather ugly, they were the first to provide a simple solution to a few specific problems that a lot of people had, which snowballed them into popularity and network effect advantages

View on HN

The fact that Julia requires compilation seems like such a huge hurdle to adoption in light of the above. When the alternatives are a REPL and the users aren't programmers, to use Julia they have to first learn the difference between code and compiled code.

Julia is JIT compiled and most people use it through a REPL. For a beginner there's hardly a difference in the experience.

No, there is a difference. My day-to-day use case is: start the REPL, start typing some code, wanna see a graph. I might literally only want to write a single command. If that takes a minute to compile, it's a problem. Julia is pushing hard to address this and I'm really interested to see where it goes - I tried it for the first time recently and saw a lot to like.

Project Jupyter's name is a reference to the three core programming languages supported by Jupyter, which are Julia, Python and R

https://en.wikipedia.org/wiki/Project_Jupyter

Julia isn’t compiled tho it has a REPL?

One isn't precluding the other. For example, SBCL is an implementation of Common Lisp that compiles everything ahead-of-time down to native code, and like all Common Lisp implementations, it offers a powerful REPL suited for interactive development. The compiler has low overhead, so you don't even notice that it compiles everything you type into your REPL.

Another common misconception is that AOT compilers can only be used to build libraries/executables, which then get executed. Again, SBCL is an example of an AOT compiler that works at function-level granularity[0], in accordance with Lisp heritage of image-based development, where you write your program by starting it, and then adding/removing/modifying code into a running instance. SBCL achieves this by having the compiler being a part of your application runtime.

I don't know how Julia is implemented internally, but since it's essentially a Lisp clothed in syntax that's more pleasant to the masses, it inherits a lot of Lisp family heritage. That could easily include a fast, to-native, in-process AOT compiler.

[0] - Or maybe even lower.

Julia's JIT is a just ahead of time method jit just like SBCL, and the language is designed around making idiomatic code as fast as possible with that approach.

So every function is a multimethod that gets compiled the first time any combination of types is first encountered, and at that point the type information is propagated to all function calls inside the method body, to eliminate dynamic dispatch on those & possibly inline the appropriate method. Julia has parametric polymorphism as well, so it's common for all types in the body to be inferable.

As a result, Julia code tends to make much more heavy use of polymorphism & multimethods than common lisp (where CLOS has a significant runtime cost instead of being a near-zero cost abstraction), since the language and the runtime were designed carefully together to make that fast.

Right, compilation time went down a lot with 1.6 by avoiding method invalidations during compilation. The other thing they did is ensure that the package manager properly compiles all dependencies in topologically sorted order when you install a package, instead of doing a lazy compile on package load where it would often waste time recompiling the same method.

A quick look an Julia’s get started guide shows it does not require compilation...

https://docs.julialang.org/en/v1/manual/getting-started/

Reply on news.ycombinator.com