Biggest turn-off with Crystal for me is no native support for Windows. It’s kind of a big deal.
> However, if you are a Windows user, for the time being you are out of luck
We’ve been waiting for years.
> However, if you are a Windows user, for the time being you are out of luck
We’ve been waiting for years.
I know, and it's unfortunate that there's not been time to work on this. I don't think people understand how small a language like Crystal is though. There's just one person working full-time on it currently!
If you'd like Windows support, one thing you could do to help is donate time or money to the Crystal project [1].
[1] https://salt.bountysource.com/teams/crystal-lang and https://opencollective.com/crystal-lang
Given the current status of the Windows port or any other issue, it is no good as a programmer "Waiting for years" and not even donating to said project and expecting any progress. That's like creating a new motor company with zero funding with a small team of less than 20 and its users begging for progress on a production-ready concept car in Q4.
> If you'd like Windows support, one thing you could do to help is donate time or money to the Crystal project
That's the sort of impression I expect from any meritocratic open-source project these days. Anyone interested in the project can donate their time to getting Windows support working or if they can't do that GitHub sponsors provides the shortest route to donating to devs (Like yourself RX14) who work on Crystal. No excuses from 'interested programmers' who want to use Crystal to complain for years about Windows on Crystal then.
This means the port is in a place where the community can pitch in and help port little bits of the standard library, and help bring it into a release-ready condition.
Crystal looks like a great language, and clearly the developers aren't prioritizing Windows support - that's not a bad thing. But that does mean people who need to be able to use it on Windows have to look elsewhere.
Crystal is barely 5 years old born purely out of side project and free time. In its early days there were other project aiming for the same thing, ( I cant remember what that project was called ) and both author discussed how each of others implementations would not work. There were lots of unknown but just keep grinding when they have spare time.
I dont want to make this like a rant, but from the tone of it, apart from waiting I am not sure what the OP, or in fact 99% of the internet which somehow has this entitlement something needs to be done and they have done nothing about it. Donating would be a start. Even if it is a dollar a month. But as DHH has put it, he would not be surprised the donation only makes it worst because it make people feels more entitled.
- Cygwin (POSIX)
- Native Windows API support
Though I wonder if targeting .NET would be something to consider. It would not save much effort, compared to Windows API, but in principle, .NET is a portable platform (like POSIX).
Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows). The whole promise of LLVM is that your prog-lang just targets LLVM (so to speak) and doesn't have to worry about specific platforms.
LLVM would be smart too, but I suspect that having access to the complete .NET ecosystem from a Ruby-like language would be very appealing to devs who worked on Ruby at home (or at startups) and are now at big enterprises that demand big-name stacks.
"Platform" in this case mostly means executable format. LLVM is too low-level to be able to abstract away operating system features.
The hard part of porting a project like Crystal isn't generating a valid binary (since LLVM does handle that part well), it's adapting the standard library for dealing with all the places where Windows and POSIX offer different interfaces to userspace - stuff like filesystem semantics, networking behavior, and threading where the system calls can't always be translated in a straightforward way.
LLVM's concern is the generation of machine code. That does indeed work for Windows even with Crystal; you can cross-compile a "Hello, world!" program and it'll run just fine in the Command Prompt.
The actual problem lies in the OS-specific APIs. Windows and Unix are very different operating systems with very different designs and very different feature sets. LLVM can't really do much to fix that.
Spin up a Linux VM and get developing?
I do .NET for my $DAYJOB and we use Windows for development. It works, but I wouldn't constrain myself only to Windows for development. I have an Ubuntu VM at home that I do dev in for other stuff.
But yeah, I'd definitely count MinGW (or more modernly, MSYS2) as "native" in this context.
Not really, as it's built against MSYS2 libs, which are a fork of Cygwin.
Not sure if Swift works very well on Windows e.g.
That's a bit ridiculous. In the group of most desktop operating systems, Windows is the odd ball. Supporting it is a huge hassle, and from a certain point of view with a very small ROI.
I wonder why the Swift threads have far fewer complaints about missing Windows support. Perhaps the absurdity is more obvious in that case?
Hilarious considering it is, by far, the most used desktop operating system. It's almost like there's a reason small languages stay small...
You think so? The latest Stackoverflow survey says otherwise: https://insights.stackoverflow.com/survey/2019#technology-_-...
"Linux 53.3%, Windows 50.7% MacOS 22.2%"
Yes, since the question is slightly open, this could refer to target platforms instead of what the actual developers are using on their desktops. Still, a nice-looking datapoint ;)
Anecdotally, as an IT chief I see developers who use Windows struggle with tasks that are simple in Linux and MacOS. There's a reason why a) MacOS won so many developers and why b) Microsoft is spending so many resources making WSL/WSL2.
> For October 2019 the Linux gaming population on Steam according to Valve was about 0.83%, basically flat compared to September, at least on a percentage term. Meanwhile for the newly-published November figures it comes at 0.81%, or a decline of 0.02%.
https://www.phoronix.com/scan.php?page=news_item&px=Steam-Su...
Crystal not working on Windows indicates to me that are implemented the run time idiotically-- should have just reused the C and C++ run time & standard libs, as this would have given them portability from the get go.
Exposing Win API or .NET is unnecessary, just allow users to call into C code for that nonsense.
[1] https://github.com/vapor/vapor [2] https://www.tensorflow.org/swift
I see pretty much 80% of interesting developments happening on *nix first.