Hacker News Reader

Comment by lordgroff | Hacker News Reader

I've been thinking about jumping on the Julia ship for a while. I like the LISP-like nature of R and miss its flexibility very much while working in Python (a language I also enjoy, but not particularly for data science). Julia, specifically its macro story and speed, fascinate me.

One of the things that still keeps me at bay is the JIT and the pre-compilation in general. It seems like it's still not very easy to actually compile a Julia library or an executable. There is PackageCompiler.jl, but my understanding is that it necessitates pulling in sys.so, which is some 130 MB in size, making it prohibitive for many projects.

View on HN

We are always working on streamlining PackageCompiler.jl and building binaries. Bug reports always appreciated.

I'm curious to understand why the 130MB is prohibitive. Are you looking at embedded or resource constrained environments?

It's more generic than that. For basic general purpose computing with some calculation and where performance is of some importance, I can design and ship the whole thing via something like Lazarus in 5-10 MB, or -- from my understanding -- 130+ MB in Julia. I understand that this might be just asking Julia to break out a bit too far out of its intended use case, but it would be nice.

I know for me the documentation and general process of using PackageCompiler.jl is a little daunting for me in a way that other parts of the ecosystem and docs haven’t been.

I was just trying to do a quick test app the other day to see if I could build a Hello World app, and (this may have been my fault) but I hit the threshold of cognitive overhead before deciding to revisit later. This isn’t a criticism so much as a recognition that compiling binaries may take a bit more care / attention / learning in Julia than something like Go, Rust, or even Racket.

As for binary sizes, for some serverless deployments smaller binaries can open up a little easier path.

I’ll try and take another run at PackageCompiler and give it a more fair shake. If in that process I find anything constructive to report or submit documentation PRs, I will do so.

Thank you for your work on Julia. Julia was on my radar a few years ago and then dropped off again. I’m excited to see where it has come in that time.

In a few use cases, such as big-data processing and things like that, a common pattern is to haul a tiny data-processing kernel to several machines to do an operation on some data they hold, rather than shuffle the data around.

This pattern can be seen in several places and frameworks like Spark & company, and it's also pretty much the foundational idea behind processing data with Joyent's Manta[0]. It always pretty much boils down to "serialize a function, and send it somewhere, to run on the data locally".

Some of these frameworks do it only through native functions (Spark runs serialized JVM procedures, and for Python functions I believe it shells out to an actualy Python interpretes), others are completely agnostic to this and work with binaries (Manta).

It'd be pretty hard to do, and have a lot of overhead, if all of those "functions" that I'm shuffling around are, at the lower bound, 130MB in size.

I understand that a lot of this can be done directly at the Julia layer for Julia things (much like Spark does with JVM things), but it kinda limits the applications of this nonetheless.

[0] https://github.com/joyent/manta

Julia can already do this in its `remotecall` API (actually has done this since v0.1), which serializes a closure and sends it to a remote node for computing.

https://docs.julialang.org/en/v1/manual/distributed-computin...

However, this is not related to the system image (sys.so) that is used to start the Julia process, which has a compiled version of base, stdlibs and whatever else you choose to build in.

I don't know about him, but I come from a somewhat weird angle, I'd want to use Julia to replace Python for command line, Opsy/DevOps type tools. Go has quite a few things I'm not a big fan of, at the moment, so Julia seems the perfect candidate. But right now its deployment situation is too complicated, I just want a static binary or a self contained zip.

I think for that, you might want to look into https://github.com/dmolina/DaemonMode.jl. This is essentially a just a clever utility for keeping a background julia session running that you feed scripts to, rather than spinning up a new session every time you launch a new script.

This is a nice alternative to the AOT compilation offered by the likes of PackageCompiler.jl

I want a simple deployment solution to random computers.

Sorry, I think I missed your final sentence when I originally read your comment. Yeah, DaemonMode.jl won't help that part. Perhaps combining Docker with with DaemonMode or PackageCompiler would solve some of these woes, but that might still not feel fully satisfactory.

Hopefully we'll have more / better AOT compilation and deployment in the near future. There's a lot of rumblings of exciting things starting in Julia AOT compilation, and I think it'd make a killer combination with our package manager's binary artifact deployment story.

From the Package.jl description: "Creating custom sysimages for reduced latency when working locally with packages that has a high startup time." That sounds really far from statically compiling everything with a compiler that will strip out all the code you don't code, inline aggressively, etc... Static languages at least let us ~pretend that even if our dependencies are bloated, our binaries will be elegant tightly optimized things :)

Julia does at least inline fairly aggressively, and it respects the `@inline` macro so long as the call is type stable.

In practice, it may often inline more aggressively as there aren't any boundaries that will prevent inlining.

If you write function `foo` calling `buz` from package `Buz.jl`, which calls `bar` from package `Bar.jl`, `bar` can be inlined into `foo`.

You can think of it as always have `-lto`, because the source of the Julia functions you're calling will always be available to the compiler and thus subject to (potentially aggressive) optimization.

In a recent talk about PackageCompiler, the speaker said that an image compressed into a .tar.gz is ~80 MB.

Reply on news.ycombinator.com