It generates efficient code (similar to a C program, e.g. you could write a reasonable ray tracer), and is concise. Many Ruby programs would not see a size expa

It generates efficient code (similar to a C program, e.g. you could write a reasonable ray tracer), and is concise. Many Ruby programs would not see a size expansion from being written in Crystal. It's also good at interoperating with C programs; it's employs LLVM in a fairly orthodox manner (so, for example, if you run `perf` under Linux, you will get good symbolic output) I think the Achilles heel for Crystal is its compilation time on small programs with large dependencies. Note the time to build the entire compiler and standard library is not extraordinary for a large program. It's more like, a small program adding its first few dependencies will find itself pulling in a lot of the standard library to compile, and then will level off in its compilation time. To illustrate why this may be the case, consider the Crystal feature allowing redefining parts of classes, including ones in the standard library. This is both very useful, and if you think about how it affects features like incremental compilation, immensely complicating. Here's some practical crystal programs. This Postgres wire protocol driver is comparable to libpq in performance, and supports a lot of features in the protocol, too: https://github.com/will/crystal-pg/ https://github.com/will/crystal-pg/ The Crunchy Bridge CLI: https://github.com/CrunchyData/bridge-cli https://github.com/CrunchyData/bridge-cli