Re:Towards Crystal 1.0
by nicoburns on Monday March 30, 2020 @02:23PM
(#22730673)
Yeah, especially as the idea that adding windows support won't end up affecting public APIs is pretty naive. Windows and unix-like systems have very different APIs for lot's of things, and it's very easy to fall into designing something unix-specific if you don't make it cross-platform from the start.
[ Parent
| on HN ]
Crystal mostly copies ruby, so it's probably not that naive (though actually I don't know how ruby is on windows).
Ruby has a pretty solid Api story on windows (meaning code and gems generally work) - but it's not quite a tier one platform - it's gotten better, but eg automatic compilation of c level extensions isn't quite as good as on Linux. This mostly stems from using msys and not vc++ - and is similar to the issues python used to face on windows. But if I'm not mistaken python moved to vc a while after community edition became a thing.
We're also running some rather old code (w old versions of ruby) - and that's obviously not great - but also somewhat worse on windows than on Linux.
All that might make it sounds like ruby on windows is tricky - but it really has gotten quite great, especially after 2.4.
I wonder if this problem won’t go away after WSL2.0?
How far away are we from a Windows that can run Unix/POSIX out of the box?
If anything WSL2.0 has made it clearer than WSL is a development environment, not a universal compatibility layer.
WSL is an effort to bring into Windows the crowd that buys macbooks to develop GNU/Linux software, as they are unwilling to support Linux OEMs.
The Windows developer community at large, just like Apple developers, isn't that much into UNIX compatibility layers.