I'm not sure what causes it, but there seems to be an effect where btrfs loves you or hates you and few people with mixed experiences regarding data loss. One possible cause is distro choice tends to be per person and how up to date said distro keeps it's kernel. But, I'm not sure.

I certainly wasn't much more than sleepy and wanting to break the stereotypes on that particular expression when I wrote it.

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.

If you have free time, or free money, it'd be a great help to the effort.

For a language which claims to be fast, having to use a C-based JSON parser would be a bit of a cop-out :)

Agree that performance comparisons between Nim and Crystal are going to be largely moot. They're both "fast enough" for their target audiences.

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

There's one small error, where the article says "With Nim, we were also able to link both the Nim and C files into the same executable, which Crystal sadly cannot do." However, this is not true! You've passed the object file you created directly to the linker, so it is in fact included directly in the executable.

I'm a core team member of Crystal, feel free to ask away.