About Julia's development policy regarding Windows

General Usage
1

This is just a thread to give feedback as a new user working with Windows and the problems I have.

I am a medical engineer and wanted to use Julia to develop software others can use (other engineers, laboratory workers, researchers etc.)

Since 100% (sic!) of our customers but also of my colleagues and collaborators e.g. in EU-funded projects use Windows or macOS on their desktop computers, of course I must provide software that runs under Windows. It does not matter if I like Windows, either I provide it, I can establish a product, or not.

I am a disappointed about how Julia is developed because Julia runs on Desktop computers - where Windows have > 80% market share. Therefore I assumed Julia is developed having in mind that Windows is the most important OS.
But this is not the case. Instead Unix-like OSes seem to have priority.

Examples:

  • install Julia on Windows
    The installer tells you “restart installer as Administrator to install Julia system wide”
    Therefore I restart the installer with Admin privileges
    result: Julia is by default installed to the user folder of the admin, not to the system. So under
C:\Users\<admin username>\AppData\Local\Programs\Julia-1.11.4

instead of

C:\Program Files\Julia-1.11.4

Also, the julia.exe is not added to the system-wide PATH environment variable of Windows.

So in fact, normal users of the PC cannot use Julia.
Mistakes happen, sure, but how can it be that nobody notices this? How is the installer tested?

  • PackageCompiler is a core feature of Julia because to be able to use Julia for other applications, you must be able to make either an app or a library out of your Julia modules. Now, after many hours of trying, I am not able to get it to work under Windows). So I cannot use Julia for my purpose.
    Also, I have for example two C-compilers installed, MinGW-w64 and Visual Studio, but PackageCompiler does not care, it always downloads its own version of MinGW-w64. How is PackageCompiler tested that it does not recognize an existing MinGW, despite this is in Windows’ system-wide PATH environment variable?

  • juliac is still experimental, but OK, it provides exactly what I need. So I gave it a try via Julia 1.12beta1. And I failed because it hardcodes Unix-special compiler settings. There is no cc compiler on Windows. And juliac does not provide an option to specify the compiler. Apparently juliac is developed without the OS in mind that has the largest market share. How can that be? As I developer the goal is that others can use my programs, and not to please me or my personal needs.

There are threads like this one notice that Julia is not becoming more popular. And my experience: because it does not work well under the OS most scientists and lab workers use.

Regarding the Julia project lead team the focus must be to supply a product suitable for most of the users. Julia 1.12 is in beta phase, and since I was once a release-manager of a large OpenSource program (FreeCAD), my self-understanding was that before we go out for beta testing, we must be sure the basic things work under the 3 main OSes (Windows, MacOS, Linux). And for example I had to postpone the beta several times because of issues under MacOS and it was worth it in the end.
But Julia 1.12 is out as beta despite the main new functionalities were apparently not tested under the most important OS. --trim is one of the main new things in Julia 1.12 but existing reports that this does not work, are unanswered since 2 weeks. I don’t understand the development policy: There is a bug report that the main new feature is not working under the main OS but a beta of Julia is released. Aren’t there checklists how releases are done?

This post is like an outcry to trigger something. As a new user I don’t know internals of the Julia project, if, what and how things could be changed. I can only say, as it is Julia is not attractive for average engineers and science-related software developers with the need to serve others using Windows.

5 Likes
2

Not so sure which installer you are talking about, but nowadays you should only use juliaup. Is this a bug in juliaup?

This are the official installation instructions for Windows:
Run this at the command prompt:

winget install --name Julia --id 9NJNWW8PVKMN -e -s msstore

I agree that the naming is confusing. This command actually installs juliaup.

9 Likes
3

Also juliaup does indeed add Julia to path on Windows.

2 Likes
4

I understand you’re new to the forum and may not really understand what it’s for, so I’ll explain why this won’t work. Users and package developers typically exchange information here, it’s not a direct line to all the core developers of the base Julia language. Github issues are more likely to reach them, and you’d still have to wait for anyone to get to you because there’s plenty of issues to work on.

Now, if you want to exchange information with other users, these are all worthy topics of discussion. I personally would like to learn more about most of them. However, if you want to invite properly focused discussions instead of a haphazard mixture or more likely avoidance, I suggest splitting your issues into separate topics, and you evidently already made a topic for one of them you can add to. “There’s 4-5 things I want different about Julia on Windows” also prematurely limits the discussion to Windows when some of these issues may not actually be particular to Windows. Provide your versioninfo() output in advance if you want to make it easier for people to discover platform differences.

3 Likes
5

I’m making these numbers up, but I think the Julia community is something like 47% Linux, 47% Windows (there’s overlap, some people use both). Given that Windows is…more difficult to deal with in various ways, it’s unsurprising that new features like juliac --trim are more likely to work first on Linux.

I will say straight up, Julia is not ready for the kinds of standalone applications you (and I) are thinking of, and there exist better tools and ecosystems out there. For example, an exe that others can double click and a GUI pops up, or something similar. It doesn’t mean it’s utterly impossible in Julia, it’s just that tools are brittle, there will be less support for non-trivial cases, and overall the UX is just not there and won’t be there in the near future. That sounds wild given that it’s so easy to call g++ or clang in one line and have a C++ program compile, but the way Julia is designed makes this difficult. So it is best to set your expectations accordingly.

8 Likes
6

You can install at Julia - Free download and install on Windows | Microsoft Store

1 Like
7

Windows is an important and officially supported platform. Installing Julia on Windows (via the store/juliaup) works well, afaik, developing Julia code via VS Code definitely works well, running code via the REPL or in notebooks works well. I think that your particular needs are quite a bit off the beaten path, so it is important to adjust your expectations. It’s not that nobody wants the features you are looking for, like small compiled Windows binaries. Probably everyone agrees that this is something that would open up entire new domains for Julia. It’s being worked on, but most of that work is in very early stages. There may be bit of a chicken and egg problem: there are not a lot of Julia users that need static binaries, because you that’s not really something that Julia can do at the moment. Your comments pushing for such features are most certainly welcome, and a reminder that there are untapped growth areas for Julia.

So I in no way want to dismiss your concerns, but your “surprise” that these things do not work out of the box is most definitely due to a mismatch between your expectations and the needs of the “average” (current) Julia user. I think that at the moment, you should assume that your “customers” will have to install Julia on their systems in order to run Julia code. I don’t know if that is really as much of a problem as you think it is, but if so, Julia is just going to be a tough sell.

As I said, Julia officially and unambiguously supports Windows, but Unix systems (Linux and macOS) are definitely dominant among Julia users. Although, yes, half of them use Windows at least occasionally. See the data from 2024 Julia Developer’s survey presented at the last JuliaCon. So Windows is definitely not the most important platform for Julia.

I don’t have data on this, but I would wager that a majority of the core developers primarily work on Unix systems (Chris Rackauckas being a notable exception, I think). So I’m not surprised that experimental feature work much better on Unix, or even are limited to Unix. From my own experience in physics, I would say that 80% of experimentalist use Windows, 80% of theorists use Unix, and >90% of computational physicist use Unix. Most more “serious” computational work happens on HPC clusters, which are of course 100% Linux. In any case, the 80% market share of Windows on desktop computers in the general public is not representative of the market share for Julia users, or computational scientists.

I don’t have data on this, but my impression is that only a tiny minority (<5%?) of Julia users use PackageCompiler (with the exception of creating system images), and an even smaller fraction produces static apps or libraries, especially on Windows. I might be wrong about that: I think Julia Computing is supporting quite a lot of “closed source” corporate environments, and things might be quite different there compared to the academic/open source environment that’s more visible here and on GitHub. But still, I’m definitely not surprised that there are a lot of rough edges with static compilation, especially on Windows.

I think that is their focus, but I don’t think your environment is representative of most users. This is not at all meant to dismiss your concerns. We can and we should provide better support for the kinds of needs you have been expressing.

Absolutely, but I would not count juliac and probably not even PackageCompiler as “basic things”. The basic things are running Julia from VS Code or the REPL and using Notebooks.

I might be wrong about that, but I was not under the impression that --trim is intended to be complete and polished with the release of 1.12. I would assume that it will remain an experimental feature for quite some time. So, I would significantly lower my expectations on this.

I would question whether that’s really the perspective of an average scientific software developer:

That’s quite a caveat, and I definitely agree that Julia has shortcomings in that particular market. Writing software for others on Windows (as in: deployment of static Windows binaries) is tricky at best. I would actually agree that Julia is not really a feasible option for that at the moment. But it is also not something that has been a priority in Julia’s development until quite recently, and may still not be a top priority. Unlike some other programming languages, Julia’s development is not driven by some huge commercial entity like Google, Facebook, Apple, Mozilla, etc. For the most part, development depends on open source contributors from varied academic and commercial entities. Some of those commercial entities might have an interest in pushing for developments like juliac. So the extent to which Windows is well-supported outside of core Julia itself (which does have rigorous and automated testing) really depends on how invested all of those contributors are in Windows. In many cases, that might be “not very”, hence Windows having a lot more rough edges.

19 Likes
8

Appropriately tempered expectations around juliac notwithstanding, you are absolutely right to expect the following to work smoothly:

I think we should suspend the other points of discussion until we’ve made sure this works for you. Unfortunately, I don’t have access to a Windows machine, so I can’t be of much help. Hopefully a Windows user can chime in and help you get to the bottom of this.

7 Likes
9

I have run Julia quite a bit in the past, but only on Linux. I have an old computer with Windows 10 installed though and got curious enough to give it a try.
I tried to approach this without leaning too much on my previous knowledge of Julia, to get more of a new user perspective. I might very well have failed this as it can be hard to realise when such knowledge is used.

I installed julia from the windows store as linked above

and it worked fine.
Opening the installed app I get a terminal windows saying

Checking for new Julia versions
Installing Julia 1.11.4+0.x64.w64.mingw32

and checking versioninfo just for reference

julia> versioninfo()
Julia Version 1.11.4
Commit 8561cc3d68 (2025-03-10 11:36 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 4 Ă— Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, haswell)
Threads: 1 default, 0 interactive, 1 GC (on 4 virtual cores)

Following the tutorial for the Library

I download the repository, navigate to the examples/ folder using windows command prompt and run julia -q --project as instructed.
This starts Julia, but trying to follow up with using PackageCompiler I run into following error

...
Failed to precompile PackageCompiler [9b87118b-4619-50d2-8e1e-99f35a4d4d9d] to "C:\\Users\\albheim\\.julia\\compiled\\v1.11\\PackageCompiler\\jl_5DD0.tmp".
ERROR: LoadError: ArgumentError: Package RelocatableFolders [05181044-ff0b-4ac5-8273-598c1e38db00] is required but does not seem to be installed:
 - Run `Pkg.instantiate()` to install all recorded dependencies.
...

though luckily it tells med to run Pkg.instantiate() which I do, but now this fails with

ERROR: UndefVarError: `Pkg` not defined in `Main`
Suggestion: check for spelling errors or missing imports.
Hint: Pkg is loaded but not imported in the active module Main.

so I figure I’ll try importing it with import Pkg. This then allows me to first run Pkg.instantiate() and then run using PackageCompiler.

Now for compiling the library, I run the create_library command as suggested which results in following output

julia> create_library("MyLib", "MyLibCompiled";
           lib_name="libinc",
           precompile_execution_file="MyLib/build/generate_precompile.jl",
           precompile_statements_file="MyLib/build/additional_precompile.jl",
           header_files = ["MyLib/build/mylib.h"])
PackageCompiler: bundled libraries:
  ├── Base:
  │    ├── libLLVM-16jl.dll - 81.921 MiB
  │    ├── libatomic-1.dll - 261.672 KiB
  │    ├── libdSFMT.dll - 115.094 KiB
  │    ├── libgcc_s_seh-1.dll - 767.164 KiB
  │    ├── libgfortran-5.dll - 11.162 MiB
  │    ├── libgmp-10.dll - 1.053 MiB
  │    ├── libgmp.dll - 1.053 MiB
  │    ├── libgmpxx-4.dll - 292.898 KiB
  │    ├── libgmpxx.dll - 292.898 KiB
  │    ├── libgomp-1.dll - 1.645 MiB
  │    ├── libjulia-codegen.dll - 103.447 MiB
  │    ├── libjulia-internal.dll - 13.010 MiB
  │    ├── libmpfr-6.dll - 2.526 MiB
  │    ├── libmpfr.dll - 2.527 MiB
  │    ├── libopenlibm.dll - 535.359 KiB
  │    ├── libpcre2-16-0.dll - 711.891 KiB
  │    ├── libpcre2-16.dll - 712.758 KiB
  │    ├── libpcre2-32-0.dll - 684.148 KiB
  │    ├── libpcre2-32.dll - 684.148 KiB
  │    ├── libpcre2-8-0.dll - 774.789 KiB
  │    ├── libpcre2-8.dll - 774.789 KiB
  │    ├── libpcre2-posix-3.dll - 127.047 KiB
  │    ├── libquadmath-0.dll - 1.137 MiB
  │    ├── libssp-0.dll - 143.898 KiB
  │    ├── libstdc++-6.dll - 25.187 MiB
  │    ├── libuv-2.dll - 984.719 KiB
  │    ├── libwinpthread-1.dll - 330.164 KiB
  │    ├── libz.dll - 232.336 KiB
  │    ├── libjulia.dll - 227.359 KiB
  ├── Stdlibs:
  │   ├── OpenBLAS_jll
  │   │   ├── libopenblas64_.dll - 37.669 MiB
  │   ├── libblastrampoline_jll
  │   │   ├── libblastrampoline-5.dll - 2.249 MiB
  Total library file size: 293.037 MiB
  Downloaded artifact: mingw-w64
âś” [04m:40s] PackageCompiler: creating compiler .ji image (incremental=false)
â ¸ [01m:43s] PackageCompiler: compiling fresh sysimage (incremental=false)
[pid 10884] waiting for IO to finish:
 Handle type        uv_handle_t->data
 pipe[628]          000001ee4c203820->0000000000000000
âś” [05m:56s] PackageCompiler: compiling fresh sysimage (incremental=false)
âś” [04m:25s] PackageCompiler: compiling nonincremental system image
Precompiling project...
  1 dependency successfully precompiled in 3 seconds
[ Info: PackageCompiler: Executing C:\Users\albheim\Downloads\PackageCompiler.jl-master\PackageCompiler.jl-master\examples\MyLib\build\generate_precompile.jl => C:\Users\albheim\AppData\Local\Temp\jl_packagecompiler_qz6f1M\jl_9A68.tmp
Incremented count: 1 (Cint)
Incremented count: 2 (Cint)
Incremented count: 3 (Cint)
Incremented count: 4 (Cint)
Incremented count: 5 (Cint)
Incremented count: 6 (Cint)
Incremented count: 7 (Cint)
Incremented count: 8 (Cint)
Incremented count: 9 (Cint)
Incremented count: 10 (Cint)
[ Info: PackageCompiler: Done
âś” [04m:25s] PackageCompiler: compiling incremental system image

In the beginning the Julia processes seem to use around 30% CPU and 1GB ram, though for the “compiling incremental system image” it went up to 50% CPU over 4GB of ram.
Then it was done, having generated a bunch of dlls in the MyLibCompiled folder. I never tried to actually use them though as it seemed the problem discussed here were regarding the earlier stages.

So contrary to your claim that

I think this shows it is at least possible to have an okay beginner experience with Julia and PackageCompiler on Windows. And while I did run in to some small friction, it was reasonably well explained what I needed to do when something failed, so I think I could overcome it without too much implicit knowledge.

Moving on to try to help you with your problem, are there any obvious differences between our systems or in the steps we performed? In the thread linked in OP, I saw you had both tried installing Julia on a network drive which was mentioned as a potential problem, and when you tried to install it locally you mentioned you did an admin install. Have you tried just the standard user install also? Have you tried the juliaup installer?

Are there any other problems with Julia, or is it working fine except PackageCompiler?

Could it be an issue with RAM? If you run out and have to start using swap space (I assume windows does this too?) that could slow everything down significantly. Though it seems you got stuck at the nonincremental image generation, at which point I only had around 1GB RAM used by the Julia processes.

18 Likes
10

On Windows, nothing is as smooth as JuliaWin.
Windows design of local DLL’s means each folder is pseudo container.
Use that and make the Julia installation Portable like.
This means it does not interact with anything system wide which creates a robust installation.

I haven’t worked with PackageCompiler.jl and such, just using Julia with VS Code / REPL.
The issues there is that most of Julia developers use Mac / Linux while a big share of its users use Windows. This creates a tail of issues which the developers are less aware of as it is hard for the to experience.

The path I’d choose for Julia binaries is StaticCompiler.jl in the context of integration with other applications. Not as flexible as the vision of juliac but probably easier to integrate with other projects through C API. I remember lately some users fixed some issues with it on Windows. So it might be viable for you.

11

I would not recommend StaticCompiler to anyone who is new to Julia. If you have enough experience and sufficiently restricted code, it can produce spectacular results, but otherwise it’s a path that is likely to lead to frustration.

6 Likes
12

That’s an understatement. AFAIK even most experienced users will find using StaticCompiler.jl excessively laborious for developing a nontrivial app.

Currently the only non-experimental option is PackageCompiler.jl, AFAIK. Trimming is on the horizon, I guess, but still experimental and unreleased.

2 Likes
13

By all means, give it a try, but do note that JuliaWin appears to be a personal project that is not officially supported. The last release was in 2022, which is quite a while ago. So, it is likely outdated.

I would recommend installing via the standard route first, before trying alternative solutions. I have no experience with JuliaWin (never heard of it), but other alternative installation methods such as brew on macOS or system package managers on Linux have been notorious for resulting in broken installations.

4 Likes
14

I’m curious: after Julia has been installed in the recommended way, is it possible to double-click a .jl file to run it as a script? If not, that might be something to improve on (but you could still, presumably, write a batch file to launch some particular code). If yes, then if I was @uwestoehr and needed to deploy a GUI application on top of scientific Julia code to Windows users, I would write such a launcher script. That script would set up the necessary environment and launch the necessary library code. I would then instruct my “customers” to install Julia and “ship” the launcher script to them. I would definitely not try to ship an .exe or an installer. I’m having trouble imagining an engineering or commercial lab environment where this is not possible. But I don’t know, maybe this is just so beyond the expectation in @uwestoehr’s field that it’s really not an option. I am aware that in the medical industry, Windows is incredibly dominant. So Julia may just not be a good fit for @uwestoehr’s specific needs. On the other hand, I also know that Julia is being used in a big way in the healthcare industry, see Pumas UI. @ChrisRackauckas can tell you a lot more about that, and is definitely someone with a lot of experience with Julia on Windows

2 Likes
15

See GivEmXL.jl (except for the GUI part).

2 Likes
16

After some more hours, I eventually found the issue:

  • the julia.exe must be in the Windows’ PATH environment variable. So the first example in my initial post matters because after installing as admin, the julia.exe is neither in the system-wide PATH nor in PATH of the normal users.
  • One must not use the environment variable JULIA_NUM_THREADS.
    (Here is my step by step instruction how it works for me.)
1 Like
17

The official one.

After installing Julia, there is no command juliaup. However, I first need to install Julia before being able to use any of its components.

I don’t see the need to become a customer of the Microsoft store. I have no time and will to read its long terms and conditions. And I also tried to install Julia for all users of the computer, not only for the current one. (Later on every user can and will have of course its own Julia packages.)

2 Likes
18

But this part of the issue I report here: The policy of how Julia is developed in respect to Windows.

  • Beta versions are released without the new features of a version were tested on the 3 main OSes
  • There are no rules and checklists how a release is made
  • the development is not done having the 3 main OSes in mind, instead platform-specific things are hardcoded. With a proper policy, such PRs should not be merged.
  • There is no Wiki where things can be documented - one has to search different channels (Discourse, Slack, Reddit etc. to find answers. one can also not just add , update of for documentation. Instead for every docs change one would have to make pull requests in GitHub. This is a very high hurdle and that why obviously many users don’t do this. Everybody is happy with the info he got in one of the channels, but the next users with the some issue, will probably ask the same question again and active users have to answer the same questions again and again.
  • As you told me now, one must become become familiar with GitHub in order to reach the development team. Not every scientist who maybe writes small Julia scripts knows about Git but he cannot just wrote something to a forum the Julia developers are reading. (I thought this forum is the right place to reach developers.)

I opened this thread to trigger a discussion on the development policy regarding Windows (the thread’s title). If there is a better place to do this, please tell me.
I just followed the website, stating

 For support and questions, please use Discourse.
 The primary online discussion venue for Julia is the Discourse forum.

and here we are.

1 Like
19

It is the first item in the release announcement.
And of course I expect every entry in the NEWS.md file to have been tested before a beta version is released.

And my second main complaint is that the development accepts PRs that either hardcode OS-specific things or only cares for one OS. The first case is for example that juliac hardcodes a cc compiler. With a proper policy, someone would have said in the PR revision process to think also about Windows, e.g. by adding an option to use e.g. gcc as compiler or to specify the fiull path the compiler executable.
The second case is that PackageCompler that always downloads MinGW-w64, also if it is already installed and in the PATH variable. Because the development is not done with having the different OSes in mind.

Reading the other comments in this thread I get the feeling that there is a denial of the problem. Everything is fine as it is. That there are betas released that were not tested under different OSes seems to be no problem. That new components are developed without having the different OSes in mind seems also OK. And then I should become a customer of Microsoft and its store just to be able to use Julia. (Some companies even disabled the store for good reasons.) That I used the official installer, is treated as I am the problem not the installer.

1 Like
20

Your broad complaints here are misguided. If you found a bug, open an issue on GitHub · Where software is built (one topic per ticket, please). That would possibly be useful. In contrast, currently you’re just venting at the other users/volunteers here, which is rude TBH.

Regarding trimming/juliac, it has been pointed out several times already that it’s not yet released. Even the release which ships it as an experimental feature is still in beta, so not yet released. If you need trimming, wait a few years.

EDIT: this message was a bit excessive, sorry about that.

2 Likes