Support of any one platform has to be expected to stay within reason and within the capabilities of the core team (sometimes even some *NIX distros that run into problems). Anything beyond that would have to be handled by platform specific maintainers - and such a group apparently hasn’t materialized for Windows at this point. And again OSS software is always provided as is.
Otherwise, this whole thread is pointless and Elixir could just drop Windows support for good.
At this point things can be made to work on Windows - it’s just not all sunshine and roses.
And as was already pointed out earlier:
i.e. Windows support is non-trivial and addressing these issues means something else isn’t getting done.
which I think is a good thing for the community as a whole
“I want this, so there must be plenty of others who want it too” is a very common attitude among OSS users - but that doesn’t mean that adding the requested feature will invariably and effectively increase adoption.
The BEAM is a server technology and evidently some places use it on Windows Server because that is all they use. But if you are asking me they are asking for additional headaches by going that route. I’m more familiar with environments where legacy software runs on Windows Server within a VM on *NIX servers. In that environment accommodating software that is more at home on *NIX isn’t a problem.
Yes, but why does it seem you take this as a bad thing?
I’m not. I’m simply highlighting Microsoft hasn’t all of a sudden gotten all magnanimous and charitable but that its change in behaviour can be traced back to valid business reasons.
At worst there’s a lesson to be learned here about community building.
Mmmm - Microsoft’s interest in community is largely linked to keeping paying customers around Azure instead of them going to AWS or Google Cloud.
Linux distros have been proactively improving the end-user experience
So it shouldn’t be too much of a chore to give an Ubuntu LTS distro a spin, right?
Valve has helped a lot with expanding the horizons in that regard.
Valve only started that once there was plenty of cash flow from their Windows-gaming business. To some degree they were also creating a contingency in case something was going to negatively impact their Windows based business - and it was also connected to their Steam Machines effort in response to the growing (Microsoft/Sony/Nintendo) console gaming market.
Apparently now a fork of WINE (OSS which has existed since 1993) is an experimental part of their Linux platform.
Valve’s core business is still largely Windows based because that’s where the majority of their customers are - but now they have options.
this “Us vs Them” kind of mentality is really dangerous for growth
The thing is, by insisting that an OSS project support your particular OS (Windows) you are pegging yourself as a “Windows developer”.
For example in the past I have been tasked with:
- implementing some business capability within a 4GL RAD tool to be deployed to Windows desktop client machines
- moving/porting that functionality to a HP-UX (a less than progressive *NIX) daemon to reduce API licensing cost
- again moving that functionality into a Windows service because the product vendor decided to stop supporting HP-UX
Stuff like that happens all the time so I don’t get attached to tools (which includes OSs). A developer is supposed to solve business problems, not just be some sort of tools virtuoso.
If you check CSharp’s team on Github for example, you can see that they greatly care about compatibility while developing new APIs, and if I remember correctly Microsoft has still lots of documentation and guidelines to make this as inclusive as possible for all platforms.
Are you seriously comparing the resources of the Elixir core team to what Microsoft can throw at a problem here?
Lets please be realistic.
A softer problem is that windows-specific questions to the mailing list often go without an answer for a long time. Maybe there aren’t many windows users who are able or inclined.
