Yes I mean that it is approved and also something that cannot be modified by the person running the software, which means it is not approved anymore. Anything printed by the software needs to conform to the local building code.
There are only degrees of guarantees that your users canāt modify your code. Even compiled binaries can be modified. But itās often not even that hard, a great deal of modern commercial software is based on interpreted code where the source is inside the application. Anything web based (whether served over http or locally via something like electron) is even easier to modify.
That being said, there are other reasons to want to be able to compile, and Julia should be much easier to compile. It is something that is getting better.
5 Likes
In the engineering world, you do not want the user to unintentionally change code that are specific for compliance for building code based material specific designed elements. Although I like open source in general. If you want to distribute software used for design for a profit based company as a service to engineers, you want to have the end user just use the software not necessarily know how to use the development platform or coding that went into it.
Another example would be the IRSās software that is antiquated and in need of being replaced. Those folks donāt want to necessarily know the programming part just the use part.
2 Likes
I think it would be more productive to keep the thread about the state of redistributable executables in Julia and what the options are, rather than get bogged down on the whys and why nots. This is a question about one functionality (that many users want and many developers are currently improving), we donāt need to debate big topics like open source practices or healing the planet (which was a reference to a climate modeling project that uses Julia, not a central goal of the language itself).
13 Likes
Agreed. I would like to state that there is a need for creation of binaries for distribution or otherwise. The why or why not of it and the open source discussion is are two different topics completely. A simplification of the process of creating the binaries built into the julia language is the main goal of the topic.
Since you (@Jon_Marcum) marked the post with āNew to Juliaā, it is probably useful to know that this is a very, very famous topic in the community and your points have definitely reached the the Julia developers many times. For example, last years survey showed clearly that it is the third most missing feature ( see https://julialang.org/assets/2021-julia-user-developer-survey.pdf Page 10). Many people want it and many people are working on it! But it also means that we cannot solve the general problem here with this topic 
To help with the particular question: The best approach will depend on your concrete case. There is no āone fits allā solution, unfortunately. For example, it would be useful to know the answers to these questions to give the right advice:
- Who will use the executable? (Collaborators or customers ā¦ )
- How often do you want to deploy the executables?
- Does the size of the binaries matter? (i.e. can it be between 200MB to 600MB or not?)
- What are the target platforms? (Only windows or also Mac/Linux?)
- Does your project depend on many packages? (Maybe which packages?)
Depending on the answer, it might be possible to create binaries (with PackageCompiler).
But there are also scenarios where Julia is currently not the right tool (in these cases, you have to decide to either use another language or allow some just-in-time compilation during execution.)
8 Likes
You are looking for this?
3 Likes
I believe itās always possible to make binaries for all Julia supported platforms with it, at least compile your code to one .exe Windows (setup) file, with one more step explained in the video (basically starting at that timestamp): https://youtu.be/jjJ2xHpxwHg?t=448
As explained there it compiled a rather tiny source code to 348 MB folder of files, yes, huge, but then down to ONE setup .exe file at only 58 MB (ātoo large to email, so Iāll be uploading it to my Google driveā).
But it can be smaller already. Some of the largest dependencies, including the largest LLVM.dll at 76 MB (and I believe libopenblas64_.dll at 33 MB depending on if you use linear algebra) can be dropped. Just try to delete them (before the Inno Setup phase). Also the largest file, your app, there HelloApp.dll at 101 MB can be smaller, if you strip out IR etc. (not explained in the video, see my other comment in the thread). My guess is 20 MB should be doable with that workflow, and with other tools 10 KB are already possible (not for all could, but similar to explained there).
You might think that say 10x larger source code would make for even larger binaries 3480 MB and 580 MB (and compile time 10x larger too, not sure, but I believe itās already much improved from the 7 min. in the video), but that shouldnāt happen, because thereās a lot of fixed size overhead.
The Windows binary is of course non-portable, as .exe generally arenāt, but also because of his Windows specific-code at 6:03 (so wouldnāt even be without compilation).
At 32:16, he mentions limitations, āonly works with certain packagesā. I believe thatās a legacy limitation, e.g. because some packages have path problems, what the new artifacts systems solve. I would like to know if there are any major packages that are not supported, or that is havenāt yet been made to work. I believe all future package can and should work, and older can be fixed.
ā[software] as a serviceā is a thing, where all (or part) of your software is run remotely, say from Amazon AWS, Google or Heroku, (all have Julia support), e.g. through a web-page (Julia seems to already have excellent support for). Thatās the only way to āhideā your (non-web client) source code, because decompilation is a thing (at least for other languages, will be for Julia too). Then you donāt need to compile the source code for the server, although you may optionally want to do that.
4 Likes
@Jon_Marcum,
How did the compiling go. Lack of a proper compiler support is single biggest barrier to using Julia for production development for me. Still paying for Matlab.
Not super awesome. I am also finding that there are other languages that are much faster and easier to create binaries with.
Do you mean anything other than C/C++/Java ?
Thanks
Yes. Rust, Go, Vlang, Python, Deno, Grain, C#, F#, Kotlin, D. Also, these are memory safe languages and Julia is not. I am also looking at languages that have wasm interaction.
what do you mean by Julia not being memory safe? at least with --checkbounds=yes it is
Didnāt make it to the NSA list number one. Number two it pretty much says so here
https://discourse.julialang.org/t/software-memory-safety/90132
Julia is as memory safe as most of the languages on the list. (specifically itās in the same class of memory safety as go if --checkbounds itās used) the list is far from exhaustive and almost all languages other than c and c++ should be on it.
4 Likes