I think you should recognise that it is an unrealistic expectation that the OCaml ecosystem can overnight have a fully maintained, regularly released Windows toolchain arriving out of every single OCaml compiler and platform tool release.
Getting to this end goal requires us to make steady, iterative improvements that both mechanise the release process (something notoriously difficult on Windows), and match the velocity of changes in a *nix-centred ecosystem (start testing new opam packages to at least stop more Windows incompatibilities creeping in, as the core compiler team has done for years, and then run health-checks on existing packages).
The Windows Docker images here represent:
a reproducible(ish) pipeline that builds an opam-repo/opam across all supported Windows toolchain combinations.
a composable pipeline, since you can stack more application builds over the base images, and swap base images to test out new toolchains fairly easily.
an integration point with modern development tools like VS Code, which supports seamless in-container development.
If you want to help get to our endgoal of a fully supported Windows/OCaml/opam ecosystem, we need more people spending time on trying out the containers and see how well it does work for them in Windows setups, and reporting/fixing incompatibilities in opam-repository (as @fdopen did with his opam-repository for a long time).
Once the testing pipeline settles down, we need to do the next set of steps to further improve support: roll this out to the opam-repository CI, and generate binary installers for Windows, and so on. But we’re not going to get there by hypothesising about the perfect beginners experience in forum threads
I fully agree with everything you said That’s why I said, ‘it will be critical to keep Windows support maintained in future’. I understand that it’s a critical piece of the OCaml Windows infrastructure. And it will help us to solve the ‘last mile problem’, i.e. delivering the perfect onboarding experience. The reason I started this thread is that I believe solving that will give OCaml a good adoption boost–especially once multicore is shipped and there is renewed interest and scrutiny.
Two weeks ago, I asked if there were experienced Windows developers using OCaml on Windows. One person/group ( @nojb at LexiFi ) raised their hand. It makes one wonder if this means there just isn’t a sufficient population of senior Windows devs out there, to make “a great native Windows experience” an achievable goal.
To state the obvious, asking on this forum isn’t a representative sample. @dra27 and @djs55 and @keleshev and many others using Windows and OCaml happily didn’t raise their hands. It’s an entirely achievable goal, and the hard work of several developers is incrementally getting us there. We just announced a massive step forward today…
Sorry I missed this post. I’m a happy Windows OCaml user too: I’ve been using OCaml for a long time and Windows specifically for about 5 years or so. I’m a heavy (and extremely grateful) user of @fdopen’s opam-repository-mingw which I’ve used as a base on top of which I’ve layered my own packages and pins. I’m really looking forward to switching my main Windows project moby/vpnkit to a more “vendoring” style with ocamllabs/opam-monorepo so that new developers can git clone and then dune build everything together. I’m also impressed with the available scalable I/O libraries for Windows. I’m currently using libuv via fdopen/uwt and am experimenting with aantron/luv, both of which are excellent.
Perhaps I’m biased since I work on Docker but I’m really pleased with the new OCaml on Windows base images. I’m planning on using these in CI, so I can docker build artefacts for release.
I completely agree that the ideal end state will be an ocaml.msi which installs all the tools, and where everything just works out of the box. I think we’re moving in the right direction and we’ll get there … and I will try to help where I can!
I would like to learn more about this native Windows experience that that we should strive for. What are examples of languages doing this right? Except for Microsoft-developed languages, of course.
I spend some fraction of my time using C# with Visual Studio and TFS, and it is an experience that I can’t recommend. A good debugger is the only excellent part of it, the rest is dreadful, in my opinion.
I also don’t follow any aversion towards Cygwin. As soon as you want to use Git on Windows, you have to install Git Bash which is based on Mingw, so you quickly end up using some sort of Unix. Same with Python, Node, Ruby. It seems that some kind of Unix shell is a strong prerequisite for almost all kinds of development on Windows nowadays.
I have never (ok, barely ever) had any problems using @fdopen’s excellent installer and then using opam from there. At work, we are using a monorepo approach similar to what @nojb is describing, so it is a bit more involved. The idea is very similar to what @avsm described in his 2019 presentation at the OCaml Workshop (can’t quite find the recording), just more hand rolled.
Together with with .NET FFI system csml from LexiFi you can build Windows desktop applications that are undistinguishable from native Windows ones. The questions is—who wants Windows desktop applications? At SimCorp, we are currently migrating our nice Windows applications (also ones backed by OCaml) to cloud-based offerings.
I agree that the messaging around OCaml on Windows is not very clear. Going to ocaml.org for installation instructions only to find that “this repository is deprecated” is not the best experience.
Let’s take a look at installing Node.js on Windows. First you go to the download page: Download | Node.js
Then you download the Windows installer (.msi) and run it.
Finally, to verify, you open the command prompt (or PowerShell) and run node -v and npm -v to check the installed versions.
No mention of Unix shells anywhere in this process. I think this is a good beginner experience. Of course it probably took a lot of work to get Node to this point. But it is an example of the end goal.
@yawaramin I think we are quite close to this. It takes a bit of searching to find the link to OCaml64.exe, which is a regular Windows installer, like the rest of them, and by the end of it you get a desktop shortcut which opens a shell where you can type ocaml, opam, dune, etc. Do people actually use command prompt (or PowerShell) with Node?
Good to hear there is a regular Windows installer already.
Yes, a lot or most Windows developers use the command prompt i.e. cmd.exe or PowerShell because usually all they need to do is run some server with e.g. npm run start command or npm test and then get into the dev iteration loop. They don’t need sophisticated Unix shell capabilities.
Yes. All of the main interpreted languages (node, python, ruby) are easily available in Windows. The result is that you can run them from the command prompt if you want, you can create full desktop applications with a GUI, run and debug from the IDE, etc. Of course, it’s easier with interpreted languages because you don’t need to make compilation work. Windows doesn’t even ship with an easily available C compiler, which compiled languages often require as part of their compilation process. But mingw can be thrown in there pretty easily.
git bash is actually the exception to the rule. Despite being an application (and therefore similar to interpreted languages), git is a mess of scripts often written in bash rather than a full application like mercurial. This is why a simple port to Windows was never possible. Regardless, it appears to me that most Windows users prefer to use a GUI such as Visual Studio Code to manage git (which is the smart way to go anyway since individual file management via the git command line is a pain).
Despite the fact that porting compiled languages to Windows takes more effort, it appears that Haskell now works natively on Windows, as does Rust, as mentioned above. Notice that they recommend installing through the best currently available Windows package manager, which is Chocolatey.
Cygwin is pretty awful. It’s very slow; it’s hard to track where it picks up dependencies; it’s completely foreign to Windows users; and when you want to install new packages, you need to shut it down and use the awful cygwin installer (I think there are some workarounds now, but it’s still not a great experience). The reality is that Windows users aren’t familiar with the world of sh and its countless utilities, and they don’t need to be – the Windows world works mostly via GUIs and IDEs that activate required functionalities. Few people in the Windows world want to worry about cygwin dlls and applications that require them, or which version of mingw to use to enable building fully-capable Windows apps on cygwin. This knowledge is usually reserved for a few technical people in the organization who set up the scripts for the GUIs to works, while other programmers just focus on coding.
I’ve just tried the installer on a fresh machine. Perhaps, an improvement would be if the installer also provided some simple wrappers around ocaml and opam to be able to run them in the command prompt (like in the last screenshot)?
That would definitely be a good step forward but what about things like eval $(opam env)? Do opam’s environment variable settings carry over properly into Windows? I realize I’m asking more than I’m answering. Wish I still had a Windows box to test this stuff.
It’s nice so see more momentum for a better OCaml on Windows experience. I’m stuck on Windows for work and I’m looking forward to the day where I can install OCaml as swiftly as, say, Rust.
One of the major user experience drawbacks of using OCaml on Windows for me are the link times. It takes 5-10 seconds to link binaries for me. I don’t know if my environment is messed up or if that is inherent to flexlink, but it would be nice to get closer to the instant compilation (+linking), which I consider one of the benefits of developing in OCaml (on linux).
@tjammer are you using the mingw build of OCaml or the msvc one? I vaguely remember that linking was considerably faster on one or the other. Maybe someone can help me out on this one.
Yeah, check out msvc port. Although it has its own problems. You might need to have Visual Studio, not sure. Also many packages with C bindings in opam-repository-mingw assume gcc flags or extensions, so need tweaking.
You were right!
I used same random small tool as an example, which takes 14 seconds for a clean build with mingw and only 2 seconds with msvc.
Quite the difference
That’s why I said, ‘it will be critical to keep Windows support maintained in future’. I understand that it’s a critical piece of the OCaml Windows infrastructure. And it will help us to solve the ‘last mile problem’, i.e. delivering the perfect onboarding experience. The reason I started this thread is that I believe solving that will give OCaml a good adoption boost–especially once multicore is shipped and there is renewed interest and scrutiny.
but I’m really pleased with the new OCaml on Windows base images. I’m planning on using these in CI, so I can 
