> 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

>> We’ve been waiting for years.

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.

There's a lot of people like myself that can code, but aren't at the level of doing Windows ports. Strictly speaking, it would be a very big effort for some folks, so they wait.

The basic foundations of a Windows port are already in place for Crystal, merged into master. In fact you can can already cross-compile a "Hello World" on Windows.

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.

I'm sure the crystal devs have done a great job, but again let me echo, just because I can write code at an intermediate level, doesn't mean I'd have a clue where to start or what to do in a project like this. I suppose you can never learn if you don't jump in, but it would be very difficult and time consuming. Maybe if there was a way to specify exactly what needs to be done so those less saavy could be directly pointed towards where to help? I'm not sure how this is really done.

I'd disagree with the point of sponsoring really. In theory it's a cool idea... but if there are not enough devs to even start the effort, there won't be any to maintain it either. Adding windows support now would only slow down development that is happening now. And potentially it could place the authors in an uncomfortable situation where they feel obligated to support something they've got no interest / expertise in.

I'm not sure why you're being downvoted. A car might be a great vehicle - but if you work in the ocean then the car is useless.

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.

>I'm not sure why you're being downvoted.......and clearly the developers aren't prioritizing Windows support

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.

I read your comment and realized I don't think much about what it means to have native Windows support in a programming language. A crystal issue page [1] talks about two ways to support Windows:

- 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.

[1] https://github.com/crystal-lang/crystal/issues/2569

If Crystal added CLR[1] (what you likely meant by .NET) or WebAssembly as a target, I guarantee its popularity would vastly increase.

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.

1. https://en.wikipedia.org/wiki/Common_Language_Runtime

The GP is talking about the standard library support etc. of the compiled objects, while still being native.

> 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.

"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.

> Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows)

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.

Having LLVM support is only half of the story, someone needs to make the runtime and standard library work on the platform as well.

>We’ve been waiting for years

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.

I don't think it's a big deal. Plenty of users aren't on Windows, and plenty of people have no use for code on Windows.

What other languages you work with that have native Windows support?

Aside from Crystal what languages don't support Windows? You pretty much have to go out of your way to make a language that won't run on Windows.

>You pretty much have to go out of your way to make a language that won't run on Windows.

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?

> In the group of most desktop operating systems, Windows is the odd ball.

Hilarious considering it is, by far, the most used desktop operating system. It's almost like there's a reason small languages stay small...

>Hilarious considering it is, by far, the most used desktop operating system.

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.

Each one picks the survey it suits them best.

> 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...

Yeah, that's a good point, given how Crystal might very well work as a language for making games.

Swift is Apple garbage and there is no expectation it would run on anything outside of iOS.

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.

Swift runs on Linux just fine. There are web frameworks in swift. Tensorflow is working on Swift support [2]. Yes it is Apple supported but it’s open source and runs plenty of places besides iOS. You may still think it’s “garbage” but you’re misinformed about where it can be used.

[1] https://github.com/vapor/vapor [2] https://www.tensorflow.org/swift

Swift is a corporate-backed language, and everyone knows Apple is trying to lock-in customers (both users and devs).

Windows support is often behind other platforms though. Linux and Mac support tend to get prioritized for new languages.

Not sure if Swift works very well on Windows e.g.

Rephrasing: what other non-mainstream languages do you work with that have native windows support?

I see pretty much 80% of interesting developments happening on *nix first.

I'm having a harder time coming up with a language that doesn't have native Windows support. All of the language runtimes I've worked with (node, ruby, python, java, c#, php) have had native Windows binaries.

bash? (outside of mingw/wsl/cygwin)?

There's a Windows-native version of bash included with the Windows version of Git, no?

But yeah, I'd definitely count MinGW (or more modernly, MSYS2) as "native" in this context.

> There's a Windows-native version of bash included with the Windows version of Git, no?

Not really, as it's built against MSYS2 libs, which are a fork of Cygwin.

> I'd definitely count MinGW (or more modernly, MSYS2) as "native" in this context

what about cygwin?