[rienko]

multithreading is working with the -Dpreview_mt option, it's decent if the units of work are large enough at least 0,01ms, otherwise the channel overhead will dominate.

I find the API nice and easy specially for those familiar with CSP or go. Performance should improve once it gets the necessary love for it to be released to be on by default.

Windows requires a lot of boring work, especially considering most of the core devs use Linux / MacOS. Once they make it as priority it should be doable within a few months of work.

[ternaryoperator]

Half of all devs work on Windows platforms, so IMHO, if the team wants the kind of traction needed to reach for Crystal to reach a self-sustaining level, this should be a high-priority task.

Note that all of Crystal's competitors give first-class support to Windows: go, zig, nim, ruby, etc.

I say this as a suggestion, rather than a critique. Actually, as a hopeful suggestion. :-)

[yellowapple]

Further: I'm in the other half of developers, but if I'm going to use Crystal to develop desktop applications (which I'd like to do - particularly games, because that'd be a nice change of pace from business software), it'd be nice to be able to support the platform that - for better or worse - the vast majority of desktop users use.

[filleduchaos]

It's worth noting that Ruby's support for Windows could not be described as first class for a long time. And that was in a world without WSL.

There's sense in just releasing for nix platforms if you have them ready to go, especially when you expect your initial target market to be deploying on nix systems.