I don't know the Java ecosystem all that well, so I couldn't tell you how many developers and contributors to, say, popular Apache projects do most of their development on Windows. If you need things like high-performance linear algebra you often need to go through JNI and deal with interfacing native and JVM code.
Conda.jl should be quite useful for Python dependencies via PyCall, and maybe even R packages now too. But many of the C libraries provided there for Windows are built to work with Python, meaning using the same compiler that CPython was built with on Windows - Visual Studio. Visual Studio has lots of problems with scientific software, we have very experimental hacky support for compiling the core parts of Julia (LLVM, libuv, libjulia, etc) using MSVC but it's not exactly native and far from passing tests or a first-class solution. I also haven't seen many success stories of people from outside of the Python community using Conda as a build platform for scientific libraries in a way that would be usable and compatible with Julia. I personally prefer WinRPM since it has a comparable selection of existing libraries available at https://build.opensuse.org/project/show/windows:mingw:win64, and I've found it entirely doable to add new libraries there. You have an added complication of cross-compiling, but an advantage there is package developers never have to use Windows themselves if they don't want to. Having a fully automated system to build and distribute binaries is a great advantage, and as far as I'm aware anaconda.org does not provide automated Windows buildbots on their open source plan. On Tuesday, October 20, 2015 at 6:01:03 AM UTC-7, Páll Haraldsson wrote: > > On Saturday, October 17, 2015 at 3:29:32 AM UTC, Tony Kelman wrote: >> >> Why many packages don't support Windows? It's par for the course in >> open-source development, unfortunately. I gave a talk on this at JuliaCon >> in June where I discussed some of the challenges in making things work on >> Windows and how to go about fixing them, see >> https://www.youtube.com/watch?v=mbG-rqDCNqs - if you find packages you >> use that aren't currently testing on Windows but could be, I encourage you >> to submit pull requests adding appveyor.yml files and suggesting the >> authors enable Windows CI testing. >> >> Julia makes it easy to wrap C and Fortran libraries so people do exactly >> that quite often, >> > > You mean e.g. with Python. > > I can think of one exception (or not?): Java. > > At least in the beginning, that was one of it's point: > "write-once-run-anywhere" WORA (that assumed JVMs in web browsers..). > Strictly speaking, you can go out of the JVM, with JNI and have all the > cross-platform issues.. > > I understand WORA didn't quite work as intended, but aren't most Java > projects self-contained, only using Java code (or languages that compile > to) and Java's frameworks? > > Is it possible to replicate their (relative) success? If you use only > Julia code, you are portable already and codes just work.. > > > >> but building most of those C and Fortran libraries on Windows is >> nontrivial. Witness Anaconda, which exists to make binary installation of >> libraries in the Python ecosystem possible so you don't need a compiler on >> the user's machine at install time. In Julia we tend to focus on individual >> platform-specific tools, like WinRPM.jl for a large number of packages on >> Windows and Homebrew.jl on Mac. >> > > For non-Julia code, is Conda.jl the solution? > > >> >> >> On Friday, October 16, 2015 at 3:56:44 PM UTC-7, Joel wrote: >>> >>> Thanks for the information; food for thought. >>> >>> Out of curiosity, do you know why this is the case, by the way? >>> >>> Den fredag 16 oktober 2015 kl. 21:00:12 UTC+1 skrev Tony Kelman: >>>> >>>> Quite a few Julia packages are written in a way that assumes you're on >>>> Linux or Mac with build tools installed. Not all, and we're gradually >>>> fixing cases where packages can be made more portable. Best thing to do >>>> for >>>> now would be to submit a pull request adding a note to the readme that the >>>> package does not currently work on Windows, to save future users a bit of >>>> confusion. >>> >>>
