Move fast and don’t break things. Running a startup on Elm
A popular startup buzz-quote is
Move fast and break things
I know that Facebook has since changed their motto, but that quote is still heard all over the startup world, you can even buy pillows with that printed on. In Facebook’s case it’s not strange that this was their motto given that they worked with PHP and JavaScript. The alternative would have been “move slow and break things”.
Why not “Move fast and don’t break things?”.
That is exactly what Elm has allowed us to do. If the code compiles, We can trust that it won’t break, because We simply don’t get any run-time exceptions in Elm.
Elm has allowed us to move much faster than we would have done with JavaScript
You never miss adding a “,” that breaks you JavaScript app. Or forget to update an object to contain that new data structure you added. Or spend a day trying to hunt down a pesky bug that in the end turns out to be just a typo. Elm has allowed us to move much faster than we would have done with JavaScript by never letting us get stuck on frustrating bugs. Bugs also have the impact of making you fatigued, with Elm we can code for 14 hours and not be frustrated when we go to bed.
It’s not without some issues though, in the latest release 0.17, there is a bug where changes in certain files are not reflected in the whole app and the program compiles even though it should not. so it’s pretty commonplace for us to delete our build and rebuild. This is supposed to be solved in the upcoming release 0.18 .
So how did we come to write our application in Elm ?
Let’s start at the beginning.
In a recent podcast Evan and Richard talked about how they didn’t know of any big apps written from scratch in Elm. Well that is what we did 26,000 lines of code ago. We probably have the second biggest Elm-app in the world right now.
Who are we?
We are six graduates working out of a warm sweaty apartment in Sweden. Five of us are students from Linköping University and one from Stanford University. We have been working Elon Musk hours on our vision since the start of the summer.
As Richard Feldman would put it “By the way, we’re hiring!”. Shoot us an email at voice@ahead.life if you are into long working hours without a salary.
What are we building ?
We want to create a platform for all types of information that lets the user explore points of interests in a easy way. What says it better than a picture ?
Circles gets bigger depending on likes. Close to the ground is more social information and things relevant to people in that area. But if something of high interest happens there, that circle will be visible on a higher level and so on until it’s a world news story. Our vision is that you easily can explore our world and actually find out what is going on at different places after your own curiosity and not hear about stuff only if your newspaper decide to write about it. You can see our platform here https://ahead.life/.
Why Elm ?
A fellow co-founder and I had to write a master thesis, but we also wanted to spend as much time as possible developing our idea. Our Master’s Thesis was named “Elmulating Javascript” and is about “all” the libraries you need to get the same functionality as Elm 0.16. If you don’t want to read the Thesis, I don’t blame you (I wouldn’t want to either), but here is the TLDR:
- Pure functions -> Native
- Immutable data structures -> Immutable.js
- Higher-order functions -> Native
- Currying -> Ramda.js
- Static type checking -> Flow (Not JavaScript)
- No concept of Null -> folktale/data.maybe
- Reactivity -> Rx.js
- The Elm Architecture -> Redux
- Declarative UI -> React.js
We were going to start from scratch for this project so we really had free reign in choosing whatever technology we wanted. The choice really boiled down to React/Relay or Elm. Our stack would look something like this:
- Elm or React/Relay
- Phoenix
- GraphQL
- Rethinkdb (will write a blogpost on this choice aswell)
To decide between React/Relay and Elm we built two simple projects https://github.com/graphql-elixir/phoenix-hipster-stack
https://github.com/carleryd/elm-hipster-stack.
The pros of React was the huge community and previous work that had been done. We could probably just glue a bunch of premade stuff together to have a somewhat decent application. And we could reuse our acquired knowledge when building our React Native App. Despite this, we decided to go with Elm. Here is why.
What makes Elm awesome
Hard to write terrible code
This is a real issue in javascript where you always can hack something together, but in Elm it’s really hard to shoot yourself in the foot. You can probably do it but it’s very hard to write terrible code. React works really well if you are a pretty good programmer and you stay disciplined. As soon you get that one co-worker that starts binding to window or mutating state directly you’re in for a bad time.
Helpful for intermediate programmers
It was appealing to us that Elm had made so many decisions for us, and it really was just one way of writing your program in many cases. Being a somewhat of a intermediate programmer this is really helpful, since when in JavaScript we might not know what would be a good route and shoot ourselves in the foot down the line, given our inexperience.
Elm makes you a better programmer
Just as with other functional languages Elm makes you think about problems in another way and this is really helpful when going back and working on non Elm projects. We always strive to become better and some day acquire wizard status, so Elm felt like the right choice on a personal level.
The Compiler, Elm Format and The Elm Architecture
The compiler you might already have heard about? Otherwise, read this. Something that is not talked about as much is elm-format. Elm-format auto-formats your files so that its consistent between all programmers, and it’s a big deal that almost all Elm projects uses this. Because, when looking at someone else’s Elm code, it looks exactly the same as yours. Elm-format, combined with the fact that all Elm programs follow the same architecture, make it possible to understand a random Elm project much more easily than a random javascript project.
Easier to hire good talent
We are running our startup with the goal of being around for a long time and hiring more people is a natural part of that. In my mind, the people that know Elm or some other functional language are just like people that traditionally knew Python. They have not learnt it in school, instead they have sought to know it out of a genuine interest in programming. That, in and of itself, is a great filter for applicants.
When we look for talent we compete with other startups and one thing we can offer them is working with bleeding edge software, that offers a lot of possibility for opensource work.
Elm is fast
With all this awesomeness one might wondered how big of a performance cost you will have to pay to use it. Turns out it is zero!. Elm is super fast, and this is really appealing to us given that we want to write a highly interactive and complex web application.
Did we make the right choice ?
Elm really payed off and we could not be happier(or ofc we can), the complexity of our application stopped growing rather quickly, allowing us to still move fast when we reached several thousand lines of code. We have also started developing in another way, Compiler Driven Development. You make a change to a model somewhere and then just follow the compiler until the program compiles again. This way you don’t have to spend so much time thinking about what impact a change might have, just do the change and see what happens.
At times we have questioned our decision when we went up against a wall and had no clue how to solve it. We spent days just thinking about how to do stuff in the beginning, but as that got clearer and we found patterns to solve recurring problems, such as parent to child communication. Once we did this, repeating the same pattern has been very straight forward.
Elm is hard in another way than javascript can be, JavaScript might be easy and you can learn it in a couple of days and start doing stuff. But after while when you app gets complex and you cannot hold all moving parts in your head at the same time you’re in trouble. With Elm you cannot just hack stuff together, if it works it’s probably the right way. You get stuck until you learn the correct way but then its simple. A real downside to elm thou is that react-native feels way more painful now.
GraphQL and Elm?
Before we started the project we had one thing that held us back. We really wanted to use GraphQL, for which first class support was really lacking, until we found https://github.com/jahewson/elm-graphql. It did not even support mutations when we began, but we though that we might add that or that we could do a bunch of other stuff before we really needed that. In the end it kind of worked out that way. In the elm-hipster-stack we use an elm-graphql version that does not have mutations.
If you have any questions or want to contact us regarding work please email us at voice@ahead.life
