Yes, we run several production services on it. Much like Go, it's built for the web, and it's standard library will handle most things (files, http, memory io,

Yes, we run several production services on it. Much like Go, it's built for the web, and it's standard library will handle most things (files, http, memory io, ffi to c, compression and image formats, etc... quite extensive.) There's the likelihood that many future users will encounter it via a "from soup to nuts complete" web application framework like amber or lucky (ROR-like) that include scaffolding for models and migrations and such, or possibly with the sinatra/express'esque kemal framework that mostly concentrates on routing and exposing the request/response cycle, allowing you to inline middleware and pass the request context through your own stuff. .ecr templating (syntactically similar to .erb templates) is built into the standard library and compiles to actual crystal code. macros resolve to actual crystal code at compile time, so some of the ruby meta-programming requires a rethink. While some folks eagerly await true parallelism, which I THINK was here already and then revoked temporarily, but I might be mistaken, I'm quite content to build distributed applications with Crystal communicating over standard protocols or directly via some kind of socket (sockets network and local also being part of standard library) It's executables are fast, small, and don't use much ram (12megs is one anecdotal totally context-less number I'll throw at you, lol...) I use crenv for controlling the version churn, as someone else pointed out, they are ramping up to v1.0, and they now claim to have largely finished breaking changes on 0.35.1 and are prepping for 1.0.0 already on the basis of where we are at now. I also tend to use local shards (specific versions) to ensure build reproducability. Any specific questions?