I saw this question first popped up at JuliaCon 2021:
Since then I have seen a lot of talk and discussion about it as well as some attempt (StaticCompiler.jl) to address the missing feature of producing small binaries.
I am asking about it because a lot of IT people around me are simply not interested in Julia because of that. I work in a large company and saw Rust and Go take off but no one wants to use Julia (even the small group of people who uses Python and R). They see simply no reason to learn a new language.
I would like to see Julia really take off. From my point of view it did not so far, and looking at some programming language ranking it is still laging behind Rust and Go.
Like one of the comment in the youtube video I posted above, I think the ability to produce binaries “would make this thing blow up” and would solve a lot of the latency issues the language has.
Jeff Benzanson, in the video, said that he does not have a specific deadline for separate compilation and that his personal goal was to present a prototype the next year…
I just have a couple of questions:
does the Julia core team think that having small binaries is a pressing issue or not?
-is there a roadmap to address small binaries/dll generation?
The problem with roadmaps is that they look great until you start following them. Then you discover all kinds of things you didn’t think of in advance, and the final product looks different than you expected.
But in short, I suspect a lot of people think this is important, and I think that Julia 1.9 prepares the groundwork nicely. My not-very-good crystal ball tells me that if you want to start preparing for a world where you can compile large applications as binaries, one of the most productive things you can probably do is start running JET over your code base and fix every runtime-dispatch you can. The more inferrable your code-base, probably the easier it will be to generate a good binary.
I faced the same issue at my workplace. (To be fair, the other reason being that Go has a better ecosystem regarding micro services & kubernetes integration.)
As I see it, it’s either a real or a perceived problem by those who’re not interested in learning Julia. But either way, it has to be solved (and I surely would like to help if I had the technical skills).
If it’s a real pb, well … duh
But even if it’s a perceived once, then either
your try to inform / communicate / educate (kindly) people about the actual lack of good reason. But this is very time consuming and quite hard once a general opinion is settled about something, which I think it’s now the case. So this is probably not the most cost/time-efficient.
… or you do it anyway to please the masses, which solves it once and for all.
So all in all, I’m glad to see that this problem is taken seriously, and hope all the best in that regards (but don’t hold my breath for it! )
A problem can be real even with people focusing their efforts elsewhere. Generally, compiling into “small” binaries is perceived as an issue to be addressed, but given the complexity, only a limited number of people in the community can address this and they have been focusing on other, more important issues.
Which is as it should be. In every release news file, we will find amazing improvements to compilation, type inference, etc. Would a lot of people trade any of these for small binaries now? I wouldn’t.
Actually, I am a bit of in a waiting state for it. My data analysis and data exploration needs are pretty well satisfied already.
On the other hand: there is nothing important where I have to decide now, ok, I need it now, so I use Rust instead of Julia. But I would like to have it rather now than later.
Ok, it looks I sounded complaining about the situation, whereas I was just sharing experience. So apparently it’s better to be explicit: I’m very grateful of each new release (and the v1.9 is very exciting). For sure, it wouldn’t make sense to dismiss current Julia users for “could-be” users.
It may be obvious for some, wasn’t for me (as in “it would be nice in an ideal world, but maybe later”), but now it is (thanks to Tim Holy’s answer).
Hmm … I’m not here to prioritize needs, but just making the following observation that being able to redefine struct would indeed greatly help streamline day-to-day workflows but not add new core functionalities (in a sense, it’s “just” a - quite painful - hindrance), while small binaries allows new things and usages. Relative complexities do not compare, though.
I totally trust the Julia’s core team to make the right calls, and even so, couldn’t even dare complain about what is a great open source (free…) programming language (very personal opinion)
The fraction of people who care about small binaries is clearly much smaller among current Julia users compared to eg Go users. It’s a direct selection effect.
Similarly for other Julia-specific issues, be it TTFX or struct redefinition. Julia users either don’t consider these a priority, or find workarounds that fit their workflows nicely. For example, as a heavy Julia user, I very rarely encounter the struct redefinition problem: I use notebooks for interactive work or on the first stages of code development when structs are in flux, and structs can be redefined in notebooks no problem.
Really, most important Julia issues for current Julia users are different than those most important for potential Julia users.
If you feel you don’t have the skills to tackle this (and really, most people could learn if they devoted the time to it), one potential option would be to look into financially sponsoring efforts to address issues that are barriers for adoption by your employers. If you can convince them that Julia would be X-fold more productive, but requires new capabilities that might be delivered for Y dollars, they can do the math and determine if it’s worth it. If a lot of employers banded together it might reduce the cost for each. Of course you’d have to find someone to do it, but I’d guess JuliaHub would at least be willing to talk to you about this.
)