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.
If I may break the awkward silence: I (and probably most other people) have neither the knowledge nor the capacity to work on a julia compiler. I am also not going to try to convince my employer to invest into julia as I have no idea if we would benefit from it.
I once started a company project in julia (because I read somewhere that AOT compilation works) until I realized it produces 200MB for hello world, after which I had to rewrite the whole thing in C++. But I have tasted blood, super nice programming experience, would love for it to be my home language.
Nobody has the right to demand anything for free from an open source volunteer community. All I’m saying is: Not being able to compile into small binaries is what’s keeping me from touching it again and also trying to convince everyone I know from ditching Python and C++ at once. And if I cannot use it at work, I will also rather do my private projects in Python and C++ so I get better at that.
Maybe if enough people chimed in with “I’d start using it right away if it could produce small binaries”, we can convince those up there () to tackle this if they want to see the community explode.
In 2018 my usecase was writing a plugin for a blender-like program. Now it is mostly machine control in industrial environments. But please don’t turn this discussion into “Why do you need small binaries for that?”.
Binary size doesn’t need to be squeezed, just reasonable. On par with other compiled languages.
I’ve seen similar sentiments crop up before, and it’s never been productive. Removing unneeded memory overhead is universally considered a plus, and I’ve never heard someone argue otherwise. At that point, more user complaints or demand affect neither the number of the relevant subset of developers nor the time they have to contribute. If developer-hours does not increase, we’ll just have to make do with the current pace. Separating codegen from the runtime can help a piece of it, but it’d be nice if more people can tackle the large BLAS buffers. For some applications, even resolving those won’t make binaries small enough because the runtime (GC, dynamic dispatch, tasks queue) takes up space too. If you can sacrifice a lot of features, you can try StaticCompiler.jl to approach the smaller binaries, though at that point you might prefer to manage memory in another language (and another cool example I remembered, you can see Arrays being replaced by manually managed MallocArrays).
I think there is nothing awkward or silent about that. It is pretty clear to everyone that if Julia manages to be a language to write libraries that are easy to distribute and call from other languages, that will be a huge step forward getting wider acceptance.
What most people that already use Julia think, though, is that if you can use Julia (which is not your case), it is very nice already, and shipping binaries is not a necessary feature for wider adoption.
I am also an advocate for smaller Julia binaries and am also in your camp where I lack the know how to contribute unfortunately. I was just curious
The good news is that people are working on this as far as unofficial public discussions goes, but there is not yet a concrete plan. There are some hard decisions to make like how static do we want the language to be, what features do we want to keep. On one end we have StaticCompiler.jl and on the other end we have PackageCompiler.jl. Hopefully soon we will know enough where we land in the middle of these. This PR is roughly the first step in that direction.
While you have a point (“don’t wait for small binaries, for Julia is already a great language for some applications”), I’d like to underline that’s exactly the survivor bias: only those who find Julia useful … use it.
So assuming that this is not a necessary feature is not clear cut (albeit being a respectful opinion).
On a small tangent, given that: 1) Julia is already useful as is; 2) many more could enjoy it thanks to small binaries; 3) one does not simply demand features in the Open Source world; 4) is often easier to help than it looks like; (i.e. the “four horsemen of the … small binary topic”)… I’m really interested in Julia core team’s position on it? How serious of a topic it is perceived.
Note: this is first an foremost a question out of curiosity
Afaik the core developers are certainly considering that one of the most important features do deliver now.
At the same time, the most popular language does not deliver small binaries, thus that’s not a necessary feature for popularity. What Julia users think is that it can be much more popular even without that.
)
