Web Development with Lucky
Part 1: Introduction

“Build lightning fast web apps with fewer bugs” — we read on Lucky’s home page. A shiny new web framework written in Crystal promises a lot in terms of performance and productivity. All web frameworks do. Are the promises justified in this case? They very well might be, and I have two arguments to back this claim.
First of all: Crystal. Crystal is a programming language that aims at combining Ruby’s productivity with C’s performance. In a huge simplification you could call it a statically–typed, compiled Ruby with focus on concurrency and parallelism. For me it sounds like just what I’ve been looking for. One of the things that made Ruby so popular was the immense freedom it offered. Suddenly there was a language that allowed you to do almost anything — a welcome change in a rigid, Java–dominated world. No longer did you have to write tons of boilerplate code to achieve the simplest task, your code was readable, and programming was fun again. The thing about great freedom, though, is that great responsibility comes with it. When used carelessly, Ruby can turn from programmer’s best friend to their worst enemy. The advent of dynamic, interpreted languages, needed as it was, entailed throwing some babies out with the bathwater. Static type checking was one of them, and people seem to be realising now that they could really benefit from some enforced type safety in dynamically–typed languages.
Crystal gives you the safety of a statically–typed language while doing its best to retain Ruby’s productivity and readability. Type annotations are optional as long as inference can be used in their stead. Chances are you’ve grown used to seeing this:
NoMethodError (undefined method `do_stuff' for nil:NilClass)It’s probably the most common exception in Ruby. You thought you knew what the type of something was, but you were wrong. The worst thing about this is that such an error can be hiding in your production code for months before the right conditions cause it to occur. You can write extensive tests to lower that risk, but the possibility is always there — it’s just part of the dynamic nature of the language. In Crystal errors like this would be caught at compile time — the best time for a programmer to learn that their assumptions were wrong.
But let’s get back to Lucky. It is safe to say that Ruby attributes its popularity to Rails. It was that particular web framework that made it a mainstream programming language. We can see a similar trend with Elixir and Phoenix. Will Lucky follow in their footsteps and become the catalyser for Crystal’s success? With new programming languages it can be tempting to jump right in and start rewriting your favourite libraries. Especially if the syntax is so similar. Paul Smith took a different route with Lucky. He didn’t want to copy Rails or any other web framework. Rather, he chose to build something altogether new. And that’s the second reason why I think Lucky and Crystal can be the next big thing in web development.
In this series of articles I’m going to explore Lucky using the immortal blog application example. I won’t be speaking from the position of an expert though. Quite conversely — it’s my intention to use this opportunity to learn myself. In the second part it’s time to get our hands dirty generating a Lucky project.