Two years of Elixir at The Outline

I&#x27;m bullish on Elixir and I agree that ExUnit deserves to be singled out.<p>Whether you consider Elixir fast or slow probably depends on what you&#x27;re coming from and what you&#x27;re doing. Personally, I wish the performance story would significantly improve.<p>But, the reason I think Elixir should be your goto language comes down to process isolation and the ecosystem around it (the synergy of the runtime, libraries and language). If you&#x27;re doing a pure web app, you might not fully leverage it. But, for anything that involves long-lived in-process data (like a workflow&#x2F;pipeline, or persistent connections), the way to approach this in Elixir (with supervisors, processes, message passing and pattern matching) tends to result in highly cohesive and maintainable code. Message passing is a pretty effective antidote to coupling.<p>I just finished writing code that had to take a stream of unordered time-based data and dedupe it over a small window. I&#x27;m not overly pleased with the final result, but it&#x27;s completely isolated from the much larger app it sits in, easy to refactor&#x2F;rewrite, with no risk of someone taking a shortcut and just accessing some internal detail, and testable.<p>I feel like I wrote a microservice, but without any of the challenges of a separate app.

&gt; 90ms is a 90th percentile response time on The Outline. Our post page route is even faster! We got this performance out of the box<p>That&#x27;s one of the features you get when using BEAM VM -- your code will likely be scalable out of the box as it&#x27;s already built out of isolated independent small processes. If you want to handle more requests just run on a bigger machine.<p>&gt; The Community is wonderful!<p>I use Erlang mostly but one major thing I admire about Elixir is it&#x27;s community. Jose and team did a great job there. So it really has both - the great technical stuff, built on BEAM VM which was battle tested for decades, and the great community and tooling.<p>&gt; As soon as you get data from the external world, cast it into a well known shape.<p>Good advice. Have sane validation at the edges and then convert data to some internal format that&#x27;s easy to handle. As opposed to defensively sprinkling validation conditionals everywhere in the core code. That&#x27;s makes the code cleaner and easier to reason about.

As a long time Erlang developer I was suprised when I first heard of Elixir, and even more surprised at how nice it was.<p>That said I think Elixir is very unerlangish. It’s very much Ruby ported to a new platform, it’s heavy on meta programming with macros and using a giant solve all your problems web framework (Phoenix). Compared to Ruby on Rails I think it makes a lot of good arguments. It’s faster, mix is a better package manager, and the BEAM is reliable at small to medium scale.<p>Of course I recently posted about how I was moving away from the BEAM to Rust. I think Elixir has reached peak adoption, and I think the days of large frameworks like Rails and Phoenix that ask you to program in a DSL are sunsetting in favor of client side frameworks and smaller web services built off of thinks like Go’s net&#x2F;http.<p>I also think the reliability of BEAM is happening at the level of orchestration with containers and serverless. The BEAM itself doesn’t fit well into the cattle model of reliability and it has scalability issues when you reach a certain cluster size.<p>Erlang is also quite slow at processing data and performing computations. What it does provide is reliable latency and load as you scale, which lets you grow your build mess quickly without buying more hardware or performing software miracles.<p>I’m more optimistic about Rust because it provides the reliability I’ve come to expect from Erlang. We’ve been able to scale Rust to handle the same load as our Erlang cluster with a more manageable code base, lower average client latency, and lower memory usage on the same number of machines.<p>I also know that people like to treat dynamic vs static typing as a matter of taste, but in my experience dynamic typing only works until you reach a certain level of scale. I’ve watched several python and erlang codebases turn into incompressible messes because of this. This is why we’re seeing things like typescript and mypy become requirements rather than nice to have. So I’d rather just bite the bullet and get a really nice static type system up front.

When working on V2 of our architecture we tried out both Elixir and Go extensively. For our workload Go was roughly 8 times faster than Elixir, while both handling concurrent workloads exceptionally well. (bit of background on the type of work we do: <a href="https:&#x2F;&#x2F;stackshare.io&#x2F;stream&#x2F;stream-and-go-news-feeds-for-over-300-million-end-users" rel="nofollow">https:&#x2F;&#x2F;stackshare.io&#x2F;stream&#x2F;stream-and-go-news-feeds-for-ov...</a>)<p>That being said, I&#x27;d love to find an excuse to work on a little project with Elixir and Phoenix. Some really cool concepts. Especially the build in support for realtime is really nifty. With Go that&#x27;s much more work to get up and running.

&gt; consider going old school and rendering your HTML on the server; you might be delighted<p>One idea I&#x27;d wish more sites would consider.

Yeah, writing about using Elixir at The Outline is cool and all, but let&#x27;s not forget this place wiped out most of its staff, including developers.

I would like to use Elixir more at work, I&#x27;m hoping that we&#x27;ll be able to use it for some new projects. I love the language and the community.

Can you print an example of the random test error? I run a decent sized phoenix project (150K lines) and likely can help you out if you give a bit more detail.<p>With regard to associations, for simple belongs_to associations I will usually write separate changeset functions where the first argument is pattern matched against the record. I will give an example with Post&#x2F;Comment<p><pre><code> defmodule MyApp.Blog.Comment do def changeset(%Post{} = record, params) do record |&gt; build_assoc(:comments) |&gt; changeset(params) end def changeset(%Comment{} = record, params) do record |&gt; cast(params, [:body]) |&gt; validate_required([:body]) # Continue with validations, constraints, etc. end end </code></pre> In this case the changeset function calls itself once it handles building the association. For more complex conditions, I will usually write a &quot;Form&quot; module that may handle that case usually with a Enum.reduce combining multiple calls to `put_assoc` so that I can make nested associations in one insert.<p>Hope this helps a bit.

Does anyone miss or want type checking when working with Elixir? After working with Ruby to build large systems for so long, I&#x27;m missing a little bit of the safety that types provide. Typescript has been great.

&gt; 90ms is a 90th percentile response time on The Outline<p>How much of that is the DB, and what DB are you using?<p>I like the BEAM environment quite a bit, myself, and have used it successfully in several semi-embedded environments, where it really shines because of its robustness and reliability.

- Ecto is still a climbing hill for me. In fact I&#x27;m currently trying to warp my head around changesets and associations.<p>- Same for GenStage. I wanted to use them for workers pulling from an episodic queue but the docs with the emphasis on consumers pulling multiple events at once from a never ending stream didn&#x27;t really speak to me. Tailoring to my usage looked verbose: storing demand etc. I&#x27;ll have to revisit when I&#x27;m better at Elixir.<p>- I still think caching should be part of Ecto in some way, at least in the docs.<p>- I would still like more straightforward template inheritance in Phoenix (think Jinja2, Twig).<p>Excited for the future releases of Phoenix 1.4 and Ecto 3.

You should definitely CDN your data. A majority of a client-side latency is spent round-tripping to the server. Using a CDN greatly reduces this time.<p>I don&#x27;t know your workload, but 60ms doesn&#x27;t seem that fast. Don&#x27;t get me wrong, it&#x27;s pretty good, but for a read-heavy load it seems like this could be optimized to be sub-10 ms at the 99th percentile.