Crash Like a Duck; Or Why the Future is Compiled

Perhaps it’s hard to believe but last year Ruby on Rails, the poster child of the new dot-com boom, turned eleven.

You can measure the success of Rails by the number of successful (and failed) startups it helped to build. Or by the number of Rails-related events happening throughout the world, particularly those aimed at junior or even non-technical people.

Rails is well-designed and opinionated. It’s easy to learn and relatively quick to master. And yet at its 11th anniversary, some high-profile developers painted quite a different picture in their opinion pieces.

Don’t get me wrong; I have nothing against Rails

I like the simplicity it affords, and I love the speed in taking an idea off the ground. What I hate is the process of growing Rails apps, not to mention the ongoing maintenance nightmare.

When it comes to front-back-ends, Rails-like frameworks are hard to beat. But scaling them is a nightmare, especially when you miss the right moment to break your monolithic, framework-based MVP into smaller, more scalable components.

Twitter faced a similar problem when Rails stopped scaling for them and an increasing number of users ended up seeing the now extinct fail whale.

When your product finds market traction and takes off, the last thing a management team wants is to hear from developers that the whole thing needs to be rewritten from scratch in a different technology. That sounds suspiciously like children demanding a new toy, and you’d probably agree that our community to some extent worked hard to earn this badge.

But the above again has nothing to do with the language or the framework. The point I’m about to make is equally relevant for Python or PHP.

Interpreted, duck-typed languages just don’t scale

And even in mid-term, they create more problems than they solve.

I’ve recently experienced that problem first-hand when writing a GRPC-based user and organization management system called Startup in a Box.

In our team of three, we all knew Ruby, so we settled on that as our language of choice and boy, it was a mistake. A backend system like GRPC server doesn’t lend itself to the quick iteration cycle we’re used to for web apps. You can’t just reload a page to see the results of your work or have your app crash.

So, the best you can do is write specs. The problem with testing is that for a language like Ruby, you basically have to test every line. Scratch that, not just every line. Every freakin’ variable. Every freakin’ method. You’ll never know where you’ve made a typo or used an invalid method signature.

All in all, at the end of the hackathon we ended up with a working product but at the expense of full test coverage. Tests are useful, there’s no doubt about it. But what we experienced was just ridiculous.

I started using Rails from version two onwards, and given that at the time I mostly used Java (J2EE), you can imagine what a breath of fresh air it was for me.

Everything seemed so great — the MVP model, the availability of libraries (gems), the community, the gentle learning curve. Fast forward several years, and I probably enjoy writing (and reading!) Java more than Ruby. And that’s true for more languages than Java — in fact, I like other languages even more.

So, what has changed?

In short, everything.

For one, I’ve changed as a developer, but that’s probably only a small part of the answer. Even if today I’m a more mature developer, if you transported me back to 2007 — with the experience I have now — I’d still find Rails 2.0 as refreshing as vue.js these days. So that’s not the entire story.

The ecosystem has changed as well. No matter how hard they try, dev tools creators like JetBrains and their ilk will never match the sophistication of their Java IDE in their Ruby, Python or PHP editions. That’s simply not an option for interpreted, duck-typed languages.

While I love IntelliJ IDEA and their newest Go IDE called Gogland, I never actually found a good reason to switch from a relatively bare-bones Sublime Text setup to RubyMine in my everyday Ruby development.

And yet every time I switch from Sublime Text to one of these modern IDEs, I get to see how much productivity and peace of mind I can get thanks to tools which are so efficient precisely because of the nature of languages I used to eschew.

Anyone could tell that the languages have changed too. Java 8 is a completely different kind of beast than Java 5. Lambda expressions can replace a lot of that annoying and unnecessary verbosity.

Even an abomination like C++ got a nice facelift in versions 11, 14 and 17, while still a pain to use (these compile times, oh boy!), it’s a bit friendlier these days.

And if the good ol’ Java isn’t your cup of tea, there’s a ton of alternatives to choose from, both on the JVM (Clojure, Scala, Kotlin) and outside with challengers like Go, Swift, and Rust.

Even your father’s Erlang got a fresh coat of paint thanks to Elixir. In general, these new languages tend to be safer than their predecessors because we’ve since learned that NULL is an expensive concept.

OK, so the development of languages is yet another thing. But programming, too, is not what it used to be in the early and mid-2000s.

Code sharing platforms like GitHub sparked a quiet revolution with their easy-to-use and well-maintained community-built libraries which eliminated the need to use things like J2EE, usually employed by enterprises and loved by no-one.

Rails might have been one the first outcomes of this gradual, unexpected shift. And that’s probably one of the significant factors that contributed to its popularity.

Rails was followed by similar frameworks (and microframeworks) for statically typed, compiled languages. It doesn’t matter if you use Ruby, Java, Elixir or Haskell. Today you’ll find a high-quality framework for every taste.

I can see two more revolutions in the IDE space on the horizon

The first of them is the rise of Docker in development and production which until now hasn’t really caused much of a splash in the IDE world. So far, we’ve seen some efforts from Eclipse and preliminary Docker support in some of JetBrains products.

But we’re nowhere near a situation where local or remote Docker containers could plug into your development environment and run discrete parts of development workflows.

Just like we can now mix and match previously cumbersome software components, I see the IDEs of the future becoming the orchestrators of functionality provided by external sources, local and remote, free and commercial.

With the rise of AI comes another opportunity to augment our fallible human brains. Our long-term goal at codebeat is to apply machine learning techniques to detect non-obvious defects in code which eventually lead to runtime crashes or performance problems.

Next, we want to start suggesting deep code transformations no 100% locally running IDE can handle due to the limited computing power and the required volume of training data. At first a standalone service, we plan that codebeat will over time become an IDE plugin that increases individual developer’s productivity and quality by the order of magnitude.

Based on our experience at codebeat, we’re confident that only a small part of this functionality can be achieved for a language like Ruby or Python for the same reason why JetBrains’ RubyMine or PyCharm will never be able to match their Java or Go counterparts.

The interpreted code simply carries too little metadata to allow sophisticated checks and transformations. And it doesn’t matter whether the bulk of that metadata is directly supplied by the programmer (like in Java), or inferred by the parser and compiler (like in Go).

Perhaps when the singularity arrives, sophisticated AI will be able to make perfect sense of the thousands of lines of Ruby or Python.

But let’s be real for a moment

In the foreseeable future, languages that are more rigid and structured will offer more opportunities for augmenting developers’ unique skills.

When I reflect on all the reasons that steered me away from C++ and Java and towards Ruby and Python, none of them are valid in 2017, and they’re bound to become even less valid in 2018 and 2020. Today I cringe every time I get a bug notification that would have been easily caught by the compiler.

Someone much wittier than myself once tweeted that “If it walks like a duck, and quacks like a duck, it’s probably gonna throw exceptions at runtime.” In my experience, some of these runtime exceptions will cost you a lost business. Most of them will cost you development dollars that could have been pumped into features or marketing.

During the last few years, web developers got so used to bitching about compiled languages, ‘bloated’ IDEs, or that evil that is Microsoft that we practically stopped looking in their direction. We haven’t noticed that the original reasons to jump ship no longer hold and that the place we used to run away from is probably more comfortable than where we are at right now. Worse still, we imprint our old prejudices on new generations of developers. I’ve heard way too many Java jokes from folks who haven’t written a line of Java in their entire life.

I dare you to try out languages like Go or frameworks like Phoenix. Try running a GRPC server in Java. Look into server-side Swift. If you’re a frontend developer, see how TypeScript can help you avoid the usual mistakes. If you’re feeling more adventurous, look at Elm. Whatever you end up doing, it’s good to forget about first- or second-hand prejudices and approach these old-new things with a fresh, open, and inquiring mind.

At codebeat, we believe software can help write software. We work on the set of tools that help developers deliver code that is robust, secure and easy to maintain.