# Release strategy for juliac?
**URL:** https://discourse.julialang.org/t/release-strategy-for-juliac/112563
**Category:** Community
**Tags:** binarybuilder, juliac
**Created:** [April 5, 2024, 9:24am UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563 "2024-04-05T09:24:03Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [April 5, 2024, 9:24am UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/1 "2024-04-05T09:24:03Z")
In another thread @mbauman said:
> [@Julia slower than Python for finding pangrams?](https://discourse.julialang.org/t/julia-slower-than-python-for-finding-pangrams/112481/8):
>
> The good news is that we’re getting closer to having a real `juliac` that can output compiled stand-alone executables with significantly lower startup times like `cc` does.
which, of course, triggered my inner excitement and I had to open this discussion.
At the time, this, the `juliac`, is _ready_, the core Julia people together with us, the community, should, in my opinion, consider some points:
- _ready_ = should be NOT just ready for the enthusiasts but especially for new to Julia people, because those will be attracted most. The current Julia users are mostly from data science who are already quite happy with Julia as it is. But with `juliac` a whole new world is opened, which will attract many developers which are just new to Julia. They should experience a satisfying first Julia experience with `juliac`.
- releasing `juliac` should really be accompanied by some kind of larger marketing campaign. Orchestrated press articles, good professional Blogs at higher level sites and similar actions.
- Looking at the statistics at [Some Julia growth/usage stats](https://discourse.julialang.org/t/some-julia-growth-usage-stats/112547) , Julia is doing well it seems (it’s difficult getting good numbers) . Setting up something better to measure Julias overall usage in the world would be a good thing BEFORE releasing `juliac`. Knowing about the impact of `juliac` on this measurement would be of quite some value.
These are just my immediate thoughts when I read that a `juliac` is in good progress.
What do you think? What’s the proper release strategy for `juliac`? What do you think about a `beta` period, where some of us heavily test out the new `juliac` ? Or perhaps I am just overreacting and `juliac` should just be silently released into the world of Julia, for a more slowly organic growing? Of course a big marketing campaign can throw back and do harm instead of being of value.
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [April 5, 2024, 1:47pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/2 "2024-04-05T13:47:28Z")
Why would they do anything other than a standard release cycle like all software developers do?
---
### Author:  [@greatpet](https://discourse.julialang.org/u/greatpet)
#### Post date: [April 5, 2024, 2:24pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/3 "2024-04-05T14:24:44Z")
Can’t wait to see the effects on Debian’s BenchmarkGames! 😀
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [April 5, 2024, 2:54pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/4 "2024-04-05T14:54:07Z")
> [@oheil](#):
>
> Setting up something better to measure Julias overall usage in the world would be a good thing BEFORE releasing `juliac`. Knowing about the impact of `juliac` on this measurement would be of quite some value.
This “something” would have to be some kind of instrumentation in the Julia client. Unless you’ve got something clever in mind that no one else has come up with before. Two issues with that:
1. Last time we tried to do that it was a big fuss, and I’m very reluctant to propose anything like that again. However HyperLogLog hashing might be ok with people since it has pretty nice anonymity properties.
2. If we do that it wouldn’t be in clients until the next Julia release, which would be 1.12, and that’s the same release juliac stuff is likely to be ready for.
The only option to get a better way of estimating user base earlier would be to put it into 1.11 or 1.10 before their next release, which is possible but seems a bit iffy; or delaying the release of juliac, which seems counterproductive. We should also have a discussion about adding HyperLogLog hashing on the client in the first place here on discourse and see if people have objections.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 5, 2024, 3:09pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/5 "2024-04-05T15:09:16Z")
> [@StefanKarpinski](#):
>
> However HyperLogLog hashing
How would that work? Count downloads? Count computers that have Julia installed? What if there are different Julia versions on one computer? Which data would be transferred to the server?
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [April 5, 2024, 3:29pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/6 "2024-04-05T15:29:05Z")
> [@StefanKarpinski](#):
>
> Last time we tried to do that it was a big fuss, and I’m very reluctant to propose anything like that again.
I am aware of that, I was part of the discussion, and I know how difficult this is.
No, I don’t have new ideas in this direction. I just want to see the impact of `juliac` somehow, I expect it to be huge, but I am often wrong with my prognoses. In general I think it doesn’t need perfect count numbers in an absolute meaning. It would be enough to setup a measurement, perhaps on base of your stats thread above, and just let it constant (difficult enough) for a few years. This would give enough insights in the ups and downs.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [April 5, 2024, 4:05pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/7 "2024-04-05T16:05:59Z")
The code in Pkg that talks to the pkg server would generate a HyperLogLog hash value, which would be saved in in a `~/.julia/servers/$server/info.toml` file and sent along with each Pkg client request as a header value. Whereas UUIDs, which are 128 bits, can uniquely identify and thus be used to track individual users, HLL hashes would only be a few bytes and thus cannot be used to track individual users. Multiple different Julia versions would use the same hash value, so it would allow estimating installs across different versions, projects, etc.
The anatomy of an HLL hash is that there’s a uniformly randomly chosen bucket part and an exponentially sampled part. The hash value would be generated something like this:
```julia
bucket = 0x1fff & rand(UInt16) # 13 bits
sample = leading_zeros(rand(UInt32) | 0x1) # 5 bits
hllval = bucket | UInt32(sample << 13) # 18 bits
```
I would probably Base64 encode this hash as three ASCII bytes, something like this:
```julia
base64 = ['A':'Z'; 'a':'z'; '0':'9'; '-'; '_']
hllstr = base64[(hllval >> 12) & 0x3f] *
base64[(hllval >> 6) & 0x3f] *
base64[hllval & 0x3f]
```
Then the header would look something like this:
```julia
Julia-Pkg-HyperLogLogHash: Fp5
```
While 18 bits is enough for 262,144 unique values, these would be randomly generated on clients with no coordination, so the birthday paradox implies that you’d start getting collisions after only on the order of 2^9 = 512 clients—if these were uniformly generated. They aren’t uniformly generated, however, so you’ll actually get collisions way sooner than that. Which means these hashes are pretty useless for tracking people—after a few dozen people, there will be lots of duplicate hashes.
By the miracle of HyperLogLog estimation, however, these tiny, non-unique hashes would let us estimate how many unique clients have made requests—up to around a billion clients with less than 1% error, which is more than good enough for our purposes.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 5, 2024, 4:56pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/8 "2024-04-05T16:56:25Z")
But if I delete the .julia folder and re-install this would count as a new user?
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [April 5, 2024, 5:01pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/9 "2024-04-05T17:01:28Z")
> [@Julia slower than Python for finding pangrams?](https://discourse.julialang.org/t/julia-slower-than-python-for-finding-pangrams/112481/8):
>
> we’re getting closer to having a real `juliac` that can output compiled stand-alone executables with significantly lower startup times like `cc` does.
@mbauman, why do you say that? And what would it involve? I mean, I see no movement on the PR, plus it’s just a “placeholder”:
>
>
> Following the discussion in #50974, it became clear that there is significant ob…jection to changes to the behavior of the julia CLI driver. Some commenters found changes to the behavior acceptable if they were unlikely to impact existing code (e.g. in the case of #50974 using \`\_\_main\_\_\` instead of \`main\`), while other were worried about the reputational risks of even changing behavior in the corner case. In subsequent discussion it became relatively clear that the only way forward that did not raise significant objection was to introduce a new CLI driver for the new behavior. This may seem a bit drastic just for the change in #50974, but I actually think there's a number of other quality-of-life improvements that this would enable us to do over time, for example:
> - Autoloading/caching of all packages in the manifest
> - auto-selection of julia versions (integrate juliaup?)
>
> In addition, it doesn't seem so bad to have some CLI design flexibility to make sure that the \`juliac\` driver is aligned with what we need.
>
> This PR is the minimal infrastructure to add the new drivers. In particular, it does the following:
>
> 1. Adds two new cli drivers, \`juliax\` and \`juliac\`. At the moment, \`juliac\` is a placeholder and just errors, while \`juliax\` behaves the same as \`julia\` (except to error on the deprecated \`--math-mode=fast\`, just as an example of a behavior difference).
>
> 2. Documents that the behavior of \`julia\` (but not \`juliax\` or \`juliac\`) is pat of the julia public API.
>
> 3. Switches the cli mode based on the argv\[0\] of the binary. I.e. all three binaries are identical, except for their name, the same way that, e.g. \`clang\` and \`clang++\` are the same binary just with different names. On Unix systems, these are symlinks. On windows, separate copies of the same (small) binary. There is a fallback cli option \`--cli-mode\` that can be used in case the argv\[0\] detection is not available (e.g. for some fringe embedded use cases).
>
> 4. There is currently no separate \`-debug\` version of the new drivres. My intention is to make this dependent on the ordinary debug flags, rather than having a separate driver.
>
> Once this is merged, I intend to resubmit #50974 (chaning \`juliax\` only), and then finish and hook up \`juliac\` shortly thereafter.
> Adds two new cli drivers, juliax and juliac. At the moment, juliac is a placeholder and just errors
That’s just supposed to be a CLI “driver” yes, so I’m not sure where to look for actual work on the actual compiler improivments, that is at JuliaLang (I know of I think all the outside efforts). Plus, I thought that in effect juliac would just be a standard way, just invoking what’s more or less possible already with PackageCompiler.jl (PC), i.e. not a huge improvement.
Julia precompiles packages already, so it alone can do that, and I DO want arbitrary scripts to be compilable also, it doesn’t seem like a huge leap to do that (and including its dependencies), since PC does that, into one file. But it doesn’t seem it would be better or worse than with PC, it might even be done by it, by juliac downloading it for you and, invoking PC. For now people need to know of it, I suppose it’s documented in Julia’s official docs, or could be with a link.
There’s also AppBundler.jl in case people only want packages easily distributable apps in one file. I belive PG only gives you precompiled in one directory, not file, and you need to distribute it or in a manual step make an installer (e.g. for Windows, it’s documented how in a YouTube video at least). AppBundler does NOT compile (it’s not always needed), and it could be used with PC, at least theoretically.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [April 5, 2024, 5:13pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/10 "2024-04-05T17:13:49Z")
Yes. Or if you just delete the `~/.julia/server/$server/info.toml` file.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 5, 2024, 5:16pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/11 "2024-04-05T17:16:25Z")
So I would count as 10 new users per year… I also have multiple computers…
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [April 5, 2024, 5:19pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/12 "2024-04-05T17:19:30Z")
Yes. If you have some other suggestion for counting, please let’s hear it. Do you want to scan people’s retinas when they start up Julia or something?
---
### Author:  [@Amval](https://discourse.julialang.org/u/Amval)
#### Post date: [April 5, 2024, 5:24pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/13 "2024-04-05T17:24:18Z")
Only if it that comes with astronomical VC funding and putting Julia in some sort of blockchain.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 5, 2024, 5:31pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/14 "2024-04-05T17:31:47Z")
> [@StefanKarpinski](#):
>
> Yes. If you have some other suggestion for counting, please let’s hear it
I mean, I guess most of the Julia users do not re-install Julia as often as I do…
But it might be good to have a small sample of users that report how often they installed Julia in the last year… Could be part of the yearly survey…
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 5, 2024, 5:35pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/15 "2024-04-05T17:35:26Z")
The “driver” is the least interesting part of the work (IMHO). There’s _lots_ of compiler work necessary to actually output an exe that’s reasonably small and fast — and do the compilation reliably and in a reasonably short amount of time, too.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [April 5, 2024, 6:46pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/16 "2024-04-05T18:46:47Z")
At some point you just have to stop and consider whatever proxy number you have to be good enough. Looking at a HyperLogLog estimate of monthly unique installs seems fine to me. Is this exactly the same as the number of people using Julia? Obviously not, but we’re never going to get that number. What even counts as a Julia user? Do we want to count every person who has ever typed an expression into a Julia REPL? Not only is it unclear how to define a “Julia user” in the first place, but the measures it would take to count that accurately are simply too absurd to go through with. And what does it matter? What are you even going to do with that number?
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [April 5, 2024, 7:08pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/17 "2024-04-05T19:08:47Z")
> [@tbeason](#):
>
> Why would they do anything other than a standard release cycle like all software developers do?
Some people earn the living with Julia, or some people want to do that.
> [@StefanKarpinski](#):
>
> If you have some other suggestion for counting, please let’s hear it. Do you want to scan people’s retinas when they start up Julia or something?
This gave me a laugh… but the counting measure is something important in general and should be discussed separately in detail.
Back to the
> Why would they do anything other than a standard release
A `juliac` opens up a complete new world for Julia as a proper language. Currently it is a bit constrained on data science (and similar) because of its _scripting_ nature.
For many commercial software products it is still important to be closed source, well, not for the products but for the sellers. Small executable also fit better into current usual release distributions. So do binary libraries. Another world is cross compilation and embedded systems. Just to name a few examples.
With a `juliac` Julia is suddenly a viable choice as a programming language for so much more fields.
In my opinion this is even more important than a somewhat Julia 2.0 in any future. But a Julia 2.0 would generate quite some echo in the media.
Of course, this is my view on a `juliac`, and my point of view is, that `juliac` should be, first, well tested and extraordinary good, because and second, should be a major public event reflecting its impact it could have.
---
### Author:  [@\_bernhard](https://discourse.julialang.org/u/_bernhard)
#### Post date: [April 5, 2024, 7:16pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/18 "2024-04-05T19:16:01Z")
To add to, what @StefanKarpinski already said - these stats are, in my opinion at least, most interesting as relative metrics, i.e. for comparison to some earlier point in time.
Under the assumption that the relation between our surrogate metric and the value we’re interested in is fairly static, this allows us to track the effect that various events might have on the rate of julia adoption, like the introduction of an ahead-of-time compiler.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 5, 2024, 7:38pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/19 "2024-04-05T19:38:33Z")
I hope you can see how you’re being somewhat self-contradictory here. You simultaneously want `juliac` to be well-tested and extraordinarily good, but also not to be released before its ready and released with a splash, but you’re are also excited to beta-test it, but also (I imagine) wanting it to be open source… all while also not being involved in its development. I’m similarly excited and similarly on on the sidelines. 🙂
I do see your point that the name `juliac` _already has_ a significant cachet attached to it… and perhaps the name itself could be held back a bit?
---
### Author:  [@dlakelan](https://discourse.julialang.org/u/dlakelan)
#### Post date: [April 5, 2024, 8:01pm UTC](https://discourse.julialang.org/t/release-strategy-for-juliac/112563/20 "2024-04-05T20:01:50Z")
> [@StefanKarpinski](#):
>
> Looking at a HyperLogLog estimate of monthly unique installs seems fine to me.
Definitely not terrible, particularly if the logs of the IP addresses aren’t also being stored.
I also think some kind of opt-in reporting of startups could be useful. For example a package PopularitySurvey.jl could be created. This contains a single function `PopularitySurvey.reportpop(fraction=0.001)` or something. This generates a random cryptographic number and if it’s less than fraction (a number between 0.0 and 1.0) it spawns a thread that makes an effort to PUT the current Unix time and its fraction value to [http://julialang.org/popularity](http://julialang.org/popularity) or some such thing with some timeout. Perhaps make the default be 0.001 or something and the max fraction be 0.01 so we’re not hammering the server, and of course updated package versions could change the default. With a default of 0.001 and 300M people starting Julia on average 10 times a day, it’d be 35 hits a second on the server.
Then people opt-in by installing PopularitySurvey.jl and putting
```julia
using PopularitySurvey
reportpop()
```
in their startup.jl
While this doesn’t count _separate users_ it does allow to estimate _frequency of startups per second_ globally. At least among people choosing to participate.
growth through time would be due to two factors
1. Adoption of the voluntary reporting
2. More frequent usage of the language.
[Next page](https://discourse.julialang.org/t/release-strategy-for-juliac/112563.md?page=2)