Speed was never a real concern of ours. Node is more than quick enough. The big issues for us are code clarity, runtime errors and memory usage.
We like to run our sites inside docker containers so they're easy to reproduce from dev to live environments. A compiled language like crystal, with it's own standard library and tiny memory footprint means we can, with low traffic sites host more together on a server and keep our clients hosting costs low. With higher traffic sites we can use that saved memory for in-memory caches for high use resources.
As mentioned in the article the cms typically uses < 5mb of Ram. In our development environment that really helps. Running lots of sites locally isn't a problem. Node_modules folder for the node version of our cms is 430mb, vs our crystal shards of 773kb. So disk space isn't an issue either.
Type checking has helped reduce runtime errors, it's hard to compare with the node version as the number of errors is often related to code complexity. But anyone who uses typescript will know that moving from a dynamic to a statically typed language is a real eye opener for how many errors we make as programmers. Unlike Typescript, crystal isn't just pretending to have types so there is no `:any` to cheat the system.
If there are any specific metrics you'd like I'll see what I can come up with. But hopefully that gives you an idea of our motivation and the benefits we get.
Crystal is great! It's still being under development but there's not many breaking changes after 0.20.0+ and it's getting smoother day by day.
Parallelism and Windows support are on the way. BTW feel free to join the superb friendly community on Gitter https://gitter.im/crystal-lang/crystal :)
[Shameless plug] I'm the author of Kemal(http://kemalcr.com/): Fast, Effective, Simple web framework.[/Shameless plug]
Crystal is a Ruby inspired compiled language, allowing it to run blazingly fast with a very low memory footprint. It relies on LLVM for emitting native code, thus making use of all the optimisations built into the toolchain.
1. We need to get windows support to cover the entirety of the standard library (when it's possible of course). This will also allow us to cross-compile the Crystal compiler onto Windows, which bootstraps the whole Windows port and makes it truly usable.
2. We then need to merge that windows support into the standard library. We have already identified the abstractions required to make sure we can isolate the platform-specific parts of the standard library and have started moving some platform specific code there (see [1]). It's early days but this work should continue and will allow us to slowly merge windows support as a series of small and reviewable PRs, instead of one massive unreviewable chunk.
The first part of windows support is already merged and in the latest release here [2].
[1] https://github.com/crystal-lang/crystal/tree/b3c8f87fbe43669...
[2] https://github.com/crystal-lang/crystal/pull/4491
