Making Critical Decisions

21 Jan 2019

In my previous post I discussed the anguish and disorientation that comes from being laid off. I also talked about a great book that I read right after losing my job and how it inspired me to look beyond simply pursuing more of the same. Finally, I also alluded to a tech startup opportunity that conveniently fell into my lap in the latter half of last year. Today I’m going to talk about one of the technical decisions I made for this startup and its pros and cons. If nothing else, this post might provide me with a good laugh a year from now, when I look back in sorrow at the dumb choices I made. Ha.

Comfort Zones

I first started learning about Ruby on Rails in January 2006 when I was “on the bench” at my consulting job. (I had lucked into a temp position at a member-owned software co-op right out of college and did the job well enough that they made me a member.) I was using Java at the time and was intrigued by this terse but expressive language that allegedly followed the “principle of least surprise,” as well as the amazing new framework that promised astonishing productivity.

That same month, I went to the first Rails conference ever held anywhere (Canada on Rails) and my excitement grew. However, I couldn’t get anyone at my co-op to consider using it. No one was willing to step out of their comfort zone. I wound up leaving that job to join a startup in Honolulu. I was still doing Java there, but when we decided to make a “white-label” version of our main app, I campaigned for using Rails and my co-workers agreed.

After that app was up and running, I decided to head back to the mainland and took a job at another startup, a company at which I wound up working for the next eleven years. This was a Ruby on Rails website which grew to 40 million users and over 8 million monthly visitors. Needless to say, I learned Rails thoroughly, as well as important tricks for avoiding downtime and keeping the site fast. So when I started planning out the technologies for my new startup, Ruby on Rails was the obvious tool to reach for. However, I have decided against that. Let me explain why.

New tools stretch your brain and provide new benefits

I’ve known about the Functional vs Object-Oriented debate since I was in college. I have long been intrigued by the Functional camp’s promise of fewer bugs due to immutability. In a functional language you don’t keep state in Objects and mutate that state. Instead you have simple, logic-free data structures that you pass through chains of functions. Given the same inputs, these functions will always return the same results. It becomes easier to reason about your application.

Around the time I left Honolulu to return to Portland, I was interested in Erlang: a functional language and application ecosystem developed by Ericsson Telecom in the 80s. It promised “nine nines” availability (99.999999999% reliable) and lots of neat features. However, its syntax felt cryptic to me, and I soon forgot about Erlang in the heat of adapting to my new Rails job. (Though, I still have Programming Erlang by Joe Armstrong on my shelf.)

While I was snoozing in Rails Land, a smart guy named José Valim had a great idea: make a Ruby-esque language that uses the functional paradigm and runs on the Erlang VM. The result was the Elixir programming language. Soon after came the Phoenix Web Framework, the Rails of the Elixir world.

In just a few years, this new language and framework have grown in popularity by leaps and bounds. Elixir is now at version 1.8 and Phoenix at 1.4 (around the same version numbers that Ruby and Rails were when I first started with them). There are Elixir meetups and conferences all over the world. Elixir/Phoenix are probably now at the point of growth and notoriety that Rails was ten years ago. That is exciting. Soon after losing my job, I dove into learning Elixir. I took an Elixir for Programmers online course by Dave “Pragmatic Programmers” Thomas and bought books on the language and the framework. But could I justify using this new language, which is new to me and has a lot fewer engineers working with it than most other mainstream languages?

Like a Phoenix rising from the ashes of my previous dead self ;-)

I decided that the answer was yes. First, I have been remarkably comfortable while learning Elixir. Most of what I have learned makes implicit sense to me. The few things that have thrown me (“quote/unquote”, I’m looking at you) will become clearer over time.

In return for this little bit of discomfort, I get a language that:

• Promises fewer bugs due to immutability
• Supports and encourages “composability”
• Offers easy and safe concurrency via message passing (Actor model)
• Runs on the Erlang VM, which has over thirty years of solid performance and improvements
• Is much faster than Ruby and Rails (astonishing to see Phoenix requests processed in microseconds!)
• Provides a large runtime ecosystem (background jobs, crons, etc are all Elixir apps)
• And more!

Also, as much as I am determined to get my startup off the ground, I need to consider what happens if the revenue stream takes a long time to build. I might need to get a job. Learning a new, up-and-coming language separates me from the crowd and puts me in a smaller pool. That, along with developing my public programming persona (blogging, speaking, open-source contributions), will help a lot, should that time come. Oh, and many of the good habits I learn in Elixir can be applied in Ruby as well.

Danger Will Robinson!

This is not to say that this decision is without peril. After a couple weeks, I’m finding my way around slowly, but I have had my share of frustrations.

The Phoenix/Ecto app structure is more baroque and less intuitive than a Rails app. I exacerbated this by starting my project as an Elixir/Phoenix “Umbrella” app, which puts the individual components (called Applications in the Elixir world) in an apps directory inside the top directory. I’m waiting to see the benefits of this (which will probably happen once I add more apps, like cron and background workers).

I also might have made things more confusing by using a library for user management (registration, login, password reset, etc). I chose Coherence, which has a lot of great features but unfortunately is falling out of date. I got it to work, but important things happen in the Coherence app instead of mine. You can’t dig into the code of a compiled dependency in your editor… though I can certainly look for answers in their github repo.

I have found this lack of activity uncomfortably frequent in the last couple weeks of researching Elixir libraries. Elixir and Phoenix are fast-moving targets, and it’s easy for a project that integrates with them to fall behind. I would never complain that an open-source volunteer isn’t giving enough time and effort. But I do worry that the Elixir world may be suffering from the “shiny new toy” syndrome. You know, the one where everyone wants to try out the hot new language/framework and churns out a project or tool, only to abandon it after the novelty has worn off. Well, at least it’s nowhere near as nightmarish as the Node/NPM world! Ha.

Onward and upward

Elixir and Phoenix are not the only new tools that I have decided to use for my startup. I will also be using the React and React Native libraries to build the user interfaces. These are also new to me. However, this post is already long enough, and I will probably have plenty to say about React when the time comes.

For now, suffice it to say that I am embarking on a grand journey, a bold and brain-expanding experience, and probably an adventure that will result in a bit of cursing and hand-wringing. I left my comfort zone thirteen years ago. Time to do it again. Let the fun begin!