A popular startup buzz-quote is
Move fast 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.
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 email@example.com 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 ?
- Pure functions -> Native
- Immutable data structures -> Immutable.js
- Higher-order functions -> Native
- Currying -> Ramda.js
- 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
- 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
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
Helpful for intermediate programmers
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
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.
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 firstname.lastname@example.org