Become a member

Sign in

Why Crystal is the most promising

programming language of 2018

Sam Johnson
Jan 24, 2018 · 6 min read

Years ago a number of developers had the collective thought experiment “what if we took Ruby-like
syntax and wrote a fast-as-C, general-purpose, typed language that (like C/C++) compiles to native
binaries on any platform but keeps high level goodies like a rich standard library, full fibers support,
etc?” Fast forward a few years and this dream has manifested itself in the Crystal programming
language.
In the following article I will make the case for why Crystal — rather than the likes of JavaScript,
Elixir, Rust, Ruby, Python, or Go — is the most exciting and promising programming language in
recent history.

No more trade-offs: “Fast like C, slick like

Ruby”
The main draw of Crystal is that it appears to have shattered the barrier between syntactically sweet
interpreted/dynamic languages like Ruby and Python — which are loved for their readability and ease-
of-use — and the raw horsepower of C/C++ and low-level systems languages. Until now, you always
had the choice between writing a lot of hard-to-read, hard-to-debug, complicated, but extremely fast
C/C++ code, and writing a short 5-liner in Ruby/Python that does what you want, but wastes memory
and speed. In other words, we have always had to choose between performance and syntax. Since it is
much easier to develop an MVP in Ruby/Python than it is in C/C++, for the past 18+ years SAAS
companies large and small have simply accepted dynamic languages as a necessary evil and have taken
on these extra performance hits as an unavoidable cost of doing business. With Crystal, however, you
can do all the stuff you were doing in Ruby/Python but with the speed and memory footprint of a native
C/C++ binary. And did I mention your code will be beautiful and you can still use dynamic methods
sort of?

Why Crystal? 11 Reasons

1. Performance. As I mention earlier, Crystal is a statically compiled language based on the
venerable LLVM framework, and will go toe-to-toe with C/C++ and Rust any day of the week.
Crystal is “speed without semicolons”. Just look at some of the latest benchmarks:
https://github.com/tbrand/which_is_the_fastest
https://github.com/drujensen/fib
2. Syntax. Like many interpreted languages, Crystal will let you do pretty much whatever you
want in as few lines of code as possible, and in a way that is readable and aesthetically pleasing.
For this reason, Crystal is sometimes advertised as similar to Rust but easier to read and write.
3. Fibers. One thing you don’t get for free in the C/C++ world is Fibers. To avoid getting into a
huge discussion about this, a truly complete fibers implementation like the one in Crystal lets
you get around callback/promise hell (JavaScript) and makes it a lot easier to write things like
game/UI loops, events, asynchronous and synchronous IO, etc.
4. Static Typing. Crystal is a statically typed language, meaning every variable has one or more
potential types and these need to be figured out at compile time and accounted for. Ruby/Python
are dynamically typed, so it is very difficult to reason about and optimize Ruby/Python code.
By enforcing static typing, Crystal rules out a huge number of type related bugs and paves the
way for optimizations and static compilation. Even better, the Crystal compiler only requires
you to explicitly specify types when it is syntactically ambiguous what the type of a variable
should be, meaning that often you don’t even need to deal with types directly and can proceed
like you normally would in Ruby/Python-land.
5. Macros. In C/C++ land it is extremely difficult to do things statically without writing some
confusing macros using very antiquated syntax. Crystal lets you leverage a large percentage of
the language when writing macros, so you can do crazy powerful things that normally would be
impossible in a statically compiled language like having a library class written by person A
reason statically about and change its code based on the contents of an implementer class
written by person B at compile-time.
6. You can still dynamically define methods*. Many people are afraid to use Crystal because
they can’t dynamically define methods as it is a compiled language, but macros let you do just
that at compile time. I would argue that 99% of the time, your dynamic method definition could
be replaced with a compile-time macro in as many lines of code. It is extremely rare that there is
a legitimate use-case for dynamically defined methods — we just aren’t used to languages that
have the ability to do what always should have been possible to do at compile time. For more
information see method_missing in the docs.
7. Nil/Null-related errors impossible. The Crystal compiler treats Nil as a type and enforces
explicit nil checking before interacting with an object that could be nil. This means that those
 pesky errors where you try to access a method or property on an object that turns out to be nil
(and thus does not have that method or property) are physically impossible since the compiler
will throw an error.
8. Shards. Much like the gems ecosystem in Ruby and packages in other languages (e.g. Node),
Crystal has shards. They are super easy to install and maintain, and get compiled directly into
your binary executable via static linking. That’s right, even if you use 100+ shards, you will end
up with one monolithic executable.
9. Meteoric rise in popularity. Now that the language is more mature, people are flocking to
Crystal which means more shards and faster implementation of new features and bug fixes.
Recently Crystal shocked the world when it rose from 60th place to 32nd place in the Tiobe
index in a mere month. No other modern programming language has experienced such a high
rate of growth over such a short period of time.
10.Cross-platform support. At the time of writing, Crystal has first-class support on Linux and
OSX, with first-class windows support mere weeks away. This makes it perfectly suited for
writing cross-platform tools, utilities and even desktop applications. I expect that within a year
an Electron clone based on Chromium will emerge for Crystal, in addition to the existing cross-
platform Qt-based (qt5.cr) and Libui-based (libui.cr) user interface libraries. Cross-platform
support also makes it easier to reach developers on every platform.
11.Web frameworks. Amber, the most popular Crystal-based web framework, has been designed
from the ground up to be similar to Rails, but in a quintessentially Crystal way. It is also an
order of magnitude faster than Rails, and measures page load times in microseconds rather than
milliseconds. Similarly Kemal.cr (similar to Sinatra from Ruby) and newcomer Lucky also
provide a solid start

Why Crystal and not some other language?

Nothing else puts all of these ingredients together (compile-time macros, static typing, C-like speed,
Ruby-like syntax, gem-like package ecosystem, native binary compilation, fibers, and cross-platform
support). In this regard, Crystal is at least as deserving of attention as Rust, which has seen a massive
amount of popularity lately and is the closest language to Crystal in terms of the role it is meant to fill
as a fast C++ replacement with high level language features and syntax. I don’t think Crystal will or
should replace Rust (or Ruby for that matter)— that isn’t the point of this article and all three of these
languages have their respective places. I do think that Crystal could be the next Rust in terms of
popularity, and I think it deserves the attention.

And finally, some limitations

The five main limitations in the current version of Crystal at the time of writing are:
1. Windows support not yet completed (but will be very soon)
 2. No parallelism unless you link against C code that does the parallelism (concurrency is fully
supported by the fibers model, however). That said Go-style parallelism is coming very soon
and is already working in a test branch.
3. There are still small breaking changes every once in a while as they have not yet reached an
official 1.0. That said there are plenty of companies using Crystal in production.
4. Because Crystal is statically compiled, it is iimipioisisiiibiliei very difficult to have a true REPL,
though the Amber team have tackled this issue with the introduction of the amber exec
command-line option, which will execute Crystal code in the specified environment, and even
allows you to open up nano or your favorite text editor to edit and re-run said code (or pass it
as a command line argument).
Consider using Crystal for your next project!
• Programming
• Ruby
• Programming Languages
• Rust
• C Programming

Written by

Sam Johnson
CTO, BlockVue Inc.
See responses (23)

More From Medium

Related reads

Using Rust for Gamedev

Matthew Michelotti
Jan 4 · 5 min read
1.4K

Also tagged Rust

Stdout? More like Stdout of Order! (Rust)

Joe Kreydt
Oct 8 · 3 min read

Also tagged C Programming

Playing with Bitboard and Bitwise Operations in Unreal 4

BlueBubbleBee in The Startup

Sep 30 · 8 min read

54

Discover Medium
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage
- with no ads in sight. Watch

Make Medium yours

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and
inbox. Explore

Become a member
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just
$5/month. Upgrade
AboutHelpLegal
To make Medium work, we log user data. By using Medium, you agree to our Privacy Policy,
including cookie policy.