Elm at a Billion Dollar Company with Aaron White

Elm at a Billion Dollar Company with Aaron White

We discuss how betting on Elm has paid off at Vendr and get a CTO's perspective on using Elm at scale.

PublishedOctober 10, 2022

Episode#67

Aaron White (github) (twitter)
Vendr (github)
Vendr, Software Procurement Startup, Raises $150 Million at Unicorn Valuation - Bloomberg
Make Impossible States Impossible
Luke Westby's talk on Web Components
Richard Feldman's 2016 meetup talk on Web Components
elm-spa-example
elm-spa
elm-spa-realworld example
Evan's elm-sortable-table repo
Actor framework or taco or Msg translator (nested TEA) didn't work out well
elm-codegen
Plop templating tool
Storybook
Evan's vision for data interchange
Vendr is hiring

Transcript

Have you ever wanted to invite a unicorn onto the show?

Yeah, all the time.

That's what I'm dreaming about.

After Matthew's nightmares, I want my dream unicorns.

Yes, let's make our dreams come true.

Well fortunately we've got Aaron White with us.

He is the CTO of Vendor, which is newly announced as a billion dollar unicorn company using

So Aaron White, thank you so much for joining us.

Yeah, thank you guys for having me.

It's a pleasure to be here.

And I'm sorry I didn't dress up in my unicorn pajamas for the occasion, but now that you've

thrown it out there, that might have added a bit of fun flair to this meeting.

Yeah, well it's really exciting to have you here.

I mean you guys at Vendor have done a lot of cool stuff over the years, a lot of cool

open source projects.

Matt Griffith is out there at Vendor.

Also it's just great to talk to a billion dollar company and the CTO of a billion dollar

company about using Elm in their tech stack.

I'm really pleased to get to have that conversation.

I am pumped to have it too for so many reasons.

How fortunate are we to be in a position, although I tell the team all the time, it's

kind of like the day one thing at Amazon.

You kind of have to keep re earning it.

It's not like you don't get the label and then get to coast on it.

There's a lot of hard work ahead of us, but a lot of awesome hard work we've already done.

Yeah, I'm super cool that it's a company using Elm because I've been, we're going to talk

about this, but we've been using Elm in the code stack since I want to say early 2017.

I remember, and it still happens today, people ask, oh, can you build scalable companies

Is this production ready?

Which is laughable to me.

I'm excited to share that perspective a little bit more broadly.

Is JavaScript production ready?

I think whatever that metric is, it's less ready for production than Elm happens today.

We know, Matthew, from Blissfully and other people from the Elm community from Blissfully.

My understanding is that vendor acquired Blissfully and hence the name has changed.

Can you explain to us what happens or how things happen?

I'll give you a tiny bit of my background.

We'll probably get to a little bit more later, but I've been doing tech startups for 20 years,

which explains all the white in my hair and my beard.

I thought it was the last name.

Yes, it's the last, name is destiny.

About 2016, my cofounder, Ariel and I, it was actually the second company he and I had

built together.

We built an ed tech company together in 2010 using Scala, which come back to that.

We started Blissfully in 2016 and we chose to help people wrangle with what happens when

you're just consuming so many SaaS apps, you lose track of them.

How does that transform IT, finance, operations, your employees day to day lives?

It's complicated.

That's why we started that company.

We would help people figure out what SaaS they had and then help them do all the things

they needed to do with it, whether it was optimized for spend or on and off board employees

or on and off board applications.

We would be there as a system of record of all your SaaS with a workflow engine that

would help you transform your inventory and your relationships to it.

Vendor started a few years later and its mission was to, and still is, to help people acquire

SaaS at fair prices with less headache.

If you're a fast growing company or if you acquire a lot of software, it's really time

consuming to acquire that software.

You've got to go evaluate it, do legal, do security, compliance, negotiate with it, sign

a bunch of documentation, convince a bunch of stakeholders, et cetera.

It's complicated, it's slow.

On top of that, you don't know if you're getting fair prices because I think we've all seen

that you get to the enterprise tier and it's like, call us.

It's like, okay, well, great.

I'm in the dark.

We have at Vendor all sorts of data and knowledge about what fair prices are, how to acquire

things efficiently, and we can really help our customers navigate that procurement process

with a lot of confidence, better results, and much faster.

That's Blissfully, that's Vendor.

You can see why these two things go really well together.

If you're going to be trying to help your customers procure their SaaS, well, it certainly

helps to know what they have.

It helps to know what they've historically been paying for.

It helps to know who's been using it historically.

It would help to have workflows drive and mediate that entire process.

It made so much sense for these two companies to become one.

I spent a couple of years in venture capital.

I've looked at a lot of M&A over the years and a lot of acquisitions fail.

People get a little too optimistic, they're too rosy eyed.

This is one of those that just made too much sense.

It was a little bit too good to be true.

So far, so good.

I think it turned out to be true, which is awesome.

So the two companies formed up into one and it's been awesome.

In terms of technology, the Blissfully tech stack, which is Lambda, TypeScript, GraphQL,

and Elm, code name legit, throwing an I for immutable.

So Lambda, Elm, GraphQL, TypeScript, fans of our functional style.

That tech stack now underpins all of the vendor offering.

What we've been building since late 2016, early 2017 has now become the platform for

this combined company.

We're off to the races yet again.

So that's a bit of the backstory of how we found our way here.

I'm really curious to hear about the origin story of picking Elm for the tech stack.

What did that look like?

What was the motivation?

Were you considering other things?

Were you moving from something else?

We have a lot of time to talk, right?

There's so much.

There's so much wrapped up in this question.

Let me frame a couple high level arcs and then I can deep dive on each of them.

Number one, when I went to school for computer science, I got introduced to standard ML and

my mind was blown.

I was like, how is the industry not using this?

This is the most amazing thing I've ever seen.

I was a self taught programmer, I've been using basic and Pascal and I taught myself

C and C++ and then went deep in the world of Java.

Then when I got exposed to standard ML, I was like, oh my God, this is clearly correct.

Strict static type safety, functional programming, separating behavior from state.

Like, oh my God, the world's going to transform after I bring Moses with tablets or Prometheus

I'm going to bring this out of academia and into the world, everything's going to upend

It didn't quite happen that way.

I know that Elm has been inspired by standard ML, but I've never seen any standard ML actually.

Yeah, standard ML, I mean, Elm is a marvel for so many reasons.

The primary one being, I think it's restraint in terms of what features and functionality

Standard ML was invented to help language designers and programming theorists do their

It was a language purpose built to write compilers and type checkers in.

It's weirdly self referential in that way.

Extremely powerful, but also it can be very complicated.

I would say on balance, not as complicated as I'm probably making it sound.

I think Scala is way more complicated as an example, but it's got algebraic data types.

It's got functors so your modules themselves can be functions.

First class continuation is an incredibly powerful feature.

I don't think I've ever seen or haven't seen since.

I'm sure some languages have it and the audience can correct me on that.

That was my first exposure to that type of programming language.

For what it's worth, actually, immediately after college, I did try to start up a business

around standard ML thinking truly this was like bringing the fire of the gods to the

It's not to be.

The important thing here in the context of why we chose Elm was that I knew the power

of functional programming and type systems, the amount of leverage they give folks.

It would be a recurring thing in my career.

The long and short of why I think it's so powerful is that restriction is expression.

What you choose to make impossible is as important as what you're attempting to do.

I think Richard Feldman has the best phrase ever, which is make impossible states impossible.

That's such a good framing.

If you can make guarantees about your code, why wouldn't you?

In fact, a professor at Carnegie Mellon where I went to college said, the only difference

between languages with these type systems and languages without is that in languages

without type systems, you're free to express programs that don't work.

That stuck with me.

Because we know there's a touring equivalence between things.

What are you really saying?

You're saying you can write languages that have undesirable states.

Yeah, great feature.

Why would you want that?

As coders, we should be trying to find the most amount of leverage we can.

The thing I didn't appreciate back then, which I have a much stronger appreciation for now,

is the cognitive load and the pedagogy of how you onboard people into these things.

It's really easy to get someone maybe into Python, and it's a little bit harder to get

them into one of these systems.

I don't think that's universally true.

I actually think it's maybe if you started with Elm, might be easier to understand other

program languages versus start with procedural ones and coming back.

This is one big background thread in my head.

My first attempt to actually force it was in 2010 when we started that EdTech company.

I chose to use Scala.

That was a disaster.

Total disaster.

I'd love to come back to that, but I'm trying to get to the why Elm.

That's one big thread.

The second big thread is whenever I start a company, I try to make a few strong technical

bets for two reasons.

We're talking cutting edge.

One thing that if you're starting companies, whatever tech stack you pick now is going

to be the tech stack you're mired in for the next 10 years if you're successful.

It is really hard to rewrite and evolve a platform once you've got customers on it.

You had better pick things that are going to serve you well.

Often that means choosing things at the border of cutting edge because if you're not choosing

cutting edge now, then you're going to be real behind the times in a decade from now.

That's painful.

That's one reason.

Leverage, you're going to be stuck with it for a long time.

The second one is, and I can't understate this enough, the smartest people want to work

with the best technology.

If you're not making a few aggressive technical bets early in your company's lifecycle, you

actually are missing out on a very strong recruiting angle because you will find folks

who are keeping up with the cutting edge, who are attracted to those kind of opportunities,

and you don't have the money to pay big company salaries.

You're a startup.

You got to make it a real awesome mission with great people and great technology to

attract the best folks.

The three big technical bets that I made when we started were Lambda, GraphQL, and Elm.

I can give you the logic on each of them.

It's real straightforward.

Elm was probably actually the riskiest and yet most obvious one to me, which is if we

have a human usable standard ML derivative or household cousin, but that mere mortals

I have seen all the errors that happen on the front ends.

That has plagued my career with complexity and pain.

In fact, I even wrote an app that would later get acquired by Crashlytics, which got acquired

by Twitter, that helped people track JavaScript errors in their front end browser.

I'm intimately familiar by how much people on there and all the pressures to build more

and more sophisticated apps.

To be able to stand on a language that provides iron infrastructure and not mud was huge.

It didn't seem like conceptually it was the right choice.

The question was, are there enough libraries?

Are there enough skilled people?

I knew there were ports and things like that or Elm native back at the time because this

was 0.17, I think, when we got started.

It wasn't quite resolved yet, but I just knew that front ends are brittle, error prone,

and I was also going to be a one man shop early on.

That was a bet that made just a ton of sense to me.

That was the initial stack choice or was that a migration at some point from...

No, that was the very initial stack choice.

Start with Elm.

Then just to round it out a little bit, GraphQL, because I've done a lot of API work over the

years, I got started with SOAP and WSDL and XSD and then went to the other end with REST

GraphQL similarly gives you iron infrastructure to stand on through a schema and the ability

to rapidly consume different types of payloads.

That was huge for me in terms of getting leverage both for myself and not having to create bespoke

endpoints for a team every time.

Then lastly, serverless Lambda, that was clearly the future to me in that when you get started

programming, you write one file programs.

Then at some point you're managing clusters of Docker containers and whatever, and it's

like, how did I get here?

I actually think that the future is heading to a world where the cloud carves up your

single file program for you into the infrastructure.

Serverless is that first step on that path back.

There are more aggressive things like Unison Web and things like that, but Lambda just

seemed obvious.

For what we were doing, parsing a ton of data really quickly, it was incredible because

I could burn down an entire organization's data in 60 seconds and show it to the user

streaming through their Elm browser over plain Wi Fi before Starlink and people's minds would

The tech stack was super facile early on.

It was a huge joy.

Each portion of that was a gamble, but it was also chosen for 10 year applicability

and the ability to attract world class talent.

Yeah, I love that idea that you have to pick something that is not at the tail end of its

You're really sort of peeking into the future a little bit as you make these decisions.

I'm also curious to hear more about what did that...

You said it was both the most obvious choice and the most uncertain one to pick Elm.

That was because the ecosystem and the...

Were there questions about boilerplate and these classic concerns?

I'd be really curious to look at what those questions were then and then compare them

in hindsight what has the experience been.

If you could talk to your past self and reassure your past self that this thing is actually

fine or warn your past self about something, I would be really curious what that would

Okay, those are great.

Concerns that I had at the time, many of which proved true by the way.

It's not like 2017 is different than 2022.

One was let's just talk about ecosystem.

Are there enough libraries to build the application you want to build?

Back then, I would say the answer was not quite.

Elm charts wasn't really a thing yet.

I don't think that existed actually.

How am I going to do charting?

That's huge in business apps.

It just seems obvious.

Things like that, that's probably actually the biggest one for what it's worth.

What does the package ecosystem look like?

Is there enough?

That was a bit of a leap of faith that I thought, well, I'll either find a way around it or

it'll solve itself over time.

I'm not saying that was solid logical reasoning, but that was the leap of faith.

That one's really torn between going deeper and enumerating all the challenges.

Let me enumerate.

The next one was what are the patterns to architect an Elm app?

There just wasn't enough corpus of open source or blog posts or discussions like this.

How do you organize it?

I knew the Elm update loop was conceptually the right thing.

I don't remember where React Redux was around that time, but it was just clear like, oh,

this makes sense.

I had done some functional reactive programming to build an iOS app in Swift about a year

Elm was still flirting with FRP as its foundational metaphor back then.

I'm glad it moved away from it because it's equivalent but simpler where we ended up.

That was just like, how do I architect this?

I don't know the answer to that, but we'll figure it out was my answer.

Then lastly, people.

How many people out there can code standard ML or Haskell, want to learn this cousin of

it, and then write for the front end?

If they don't exist, how many people are willing to jump in and learn this on their own?

How much of a burden would it be on the existing team who may know that to educate them on

That was a major risk.

They're going back on each of those.

I can pause there.

I'm sure there are actually more risks that I've glossed over, but those are the three

that stuck out to me at the time.

The first one turned out to be such a nonissue ultimately that I'm so, so happy.

However, I still don't think it's widely publicized.

I feel like I've done the Elm community a disservice by not piping up and sharing what

This is on, what's the library, the package ecosystem?

How much coverage truly is there?

People beat up Elm all the time unfairly for like, well, the language hasn't changed a

version number in a while.

The packages are stable.

I'm like, that's amazing.

Are you kidding me?

I have no idea.

That's a feature, not a bug in my book.

The thing that we would struggle with over the early years was ports were very complicated.

Let's say you want to make a little auto complete box, a type of head search that uses say a

service like Algolia to do your back indexing.

Well, you're going to want that little search box pairing real deep in your nested view

To have that coordinate all the way up to the root of your app through ports created

such spaghetti code for us.

It just meant that every last little widget had to have this thread all the way back to

the root of the application and that just sucked.

We tried to get around that with Elm Native.

This was okay, well, we can use Elm Native to kind of like hand wave past that.

For those that don't know what Elm Native is, because I think it's gone the way of the

dodo and I'm happy about that.

This was you could mix safe Elm code with unsafe JavaScript code and basically just

kind of bust through the type safety anywhere you wanted.

That defeats the premise of the whole thing in the first place.

But I'm glad it existed at the time because there would have been no hope for us.

We started using Elm Native for like Elm chart, not Elm charts, to do charts in Elm.

We used it to do this Algolia esque thing.

Any of these things that would otherwise require massive architectural rewrites of the code

base to thread the needle on these variables, we would use Elm Native.

But actually very quickly became our number one slash only source of production issues

was the fact that if something went wrong in that JavaScript, the whole Elm app froze

and took down the entire experience and there was no way around it.

That was a nightmare, right?

That's like the whole point of this is to prevent yourself from doing that.

I don't remember who pioneered it, but when we found out how to use web components instead,

that was the aha moment.

If I could go back in time and tell my former self, look for this word web components and

when you see it, jump on it like your life depends on it, I would.

That simplified things so much and now we have the best of both worlds.

You cannot break our Elm app.

It's rock solid.

It's bonkers how good it is.

No one ever believes us.

The rumors are true.

And yet if we need to get some cool calendar widget that we didn't build, we can just web

component to it and it all works out really well.

So that was huge.

That was unsolved.

We bled a lot trying to solve it ourselves and then when we saw that technique, it just

the skies parted, the clouds parted revealing the sunny sky and everything was great.

Thank God for that.

And I don't, did you guys remember who came up with that technique first?

Well, Luke Westby gave a really great talk at Elm Europe where he did a great job breaking

down an example of that and showing how he used an Ellie for the syntax highlighted editor.

I think Richard Feldman gave like a meetup talk early on showing how to use that with

Google Maps and so he might've sort of paved the path on that a little bit, but yeah, it's,

it is such a match made in heaven.

It's such an underused thing.

So it's really interesting to hear about your experience with that.

Like is that a core like leg of, of how you guys use Elm would you say?

So massive props to Luke and Richard for that.

I owe you our company.

It is a massive leg because you know, now with a straight face, I can, when people,

you know, even now we hire people in, in engineering product design, whatever, they're like, Oh,

Can we do everything we need to do?

You know, they haven't built up the experience with it yet.

And I can say with a straight face, any web component, any component you see on the web

that we ever want to use, we can drop it in.

You want to embed a React app inside of our app?

You want to embed our app and react?

All of it is on the table.

I have no reservations.

So you know, withhold judgment on this and let's see how we go.

And you know, that's just very reassuring to be able to explain with a straight face

and then also to show people in the app, you know, Hey, this complicated thing, we didn't

have to build it.

We could leverage the best of the JavaScript ecosystem and yet do so in a way that makes

everything still kind of fit the bounds of safety and ease of use.

So yeah, that's huge.

I, we struggled a long time with that one.

And then that actually bridges to point number two, which is like, how do you architect a

You know, this was before Elm SBA example.

And you know, props to Ryan Haskell Glatz for that and you know, a bunch of discussions

and he's on the team and does amazing work and we've learned a ton from him.

I think Jeroen was talking about Richard Elm SBA example, and then you're talking about

Elm SBA, which is also awesome.

And then there's, I don't remember what Ryan ended up calling it.

I think he was tempted to call it Elm SBA example example.

The repo where he converted that over.

But anyway, yeah.

Well, he is hilarious.

So that would not surprise me.

So, so sorry, thank you.

Well, so when we got started, we were just inventing things left and right.

You know, what's a, how do you write reusable bits of this or that?

And I think the big thing that we struggled with actually more than anything else was

this pressure from habit to create reusable components that published their interfaces

of the messages that they could handle and send out.

And so you'd have a lot of components embedded in views and you know, their respective model

update loops that you had to negotiate all this translation between the parent, you know,

message domain scape and the components.

And that was such a nightmare of boilerplate and dysfunction and just pain.

Nobody ever wanted to add a feature.

Nobody wanted to add a component because suddenly you had to just write like all of these different

translator message, translator things all over the place.

You're talking about for like adding a new page to the app that works.

Not just new pages.

I mean, I'm actually trying to remember there was a name for this technique.

Again, we're really, you know, delving into ancient history here a little bit.

Thanks for adding new pages, but let's say you want to make like a reusable dropdown

We would, you know, rather than just sort of isolate the view logic for that and say

that's the component, we would try to do the whole model update loop.

So each component would have its own model and its own update.

And it wasn't like types.

They were like little mini T apps.

You would be adding these mini, you know, the Elm architecture T apps within the context

of the larger one and thus forced to write all of these message translators.

And I could go find some of this old code someone published.

I mean, in fairness to them, it turned out to be the wrong technique, but a really helpful

tutorial on how to do this.

But it costs so many scalability issues for us.

We had no idea how to organize it.

So when we saw the Elm single page app example, that, you know, that was like, oh, I see.

We had our heads on backwards.

We were stuck in like, I don't call it react mentality because I've never coded react,

but that kind of like classic stateful OO component world, you know, we're just overly

fixated on that methodology.

And so our eyes started opening up and there were no watershed moments.

I mean, that was helpful.

What is a watershed moment?

Like a, like an eye opening, like an epiphany, these kind of like, you know, web components

were, it was a watershed realization for us, right?

Like, oh, that's, that's how you do that.

With the way we've architected our app over the years, it's lots of careful refinement

based on what we were trying to do that wasn't working.

And I feel like that might've been true of the entire Elm ecosystem.

We're all kind of trying to figure it out to a degree.

Maybe some people knew it, it just wasn't published, which is why I feel bad if we don't

publish our stuff.

But I feel like we got there and now I can point at our app and I can go point to example

repos on the web and say, yeah, that's the way to do it.

And it's, it's, it's good.

And if you feel the need to deviate, you know, just pay a little bit more attention because

you may deviate into somewhere quite painful like we did historically.

But there was no like a single aha moment.

That was like a bunch of accumulated learnings over the last, you know, five, six years that

helped us kind of see the light on, on how to pull it all together.

And now we're in a great spot.

You know, now we've got generators, code generators that will spit out fresh pages and, you know,

do things with queries and like, there's so much automation around our correct pattern

that a it's, you know, there's no boilerplate, you know, to be found at least in terms of

day to day authoring of code and be the patterns are no one's complained about the patterns

in like years, which is great.

It means that they're correct.

You know, they're not, they're not, there's no impedance to this match.

There's no cognitive, you know roadblocks.

There's no kind of functional shortcomings.

They just kind of work.

And so nobody even thinks about it.

But I remember how painful that was trying to figure out how to like organize our app.

So it is possible to write bad Elm code or at least it was possible.

Like that's, oh, it's still possible.

It's still possible.

I think if any, if you tried to write a self contained Elm component with that model, you

I think that's called the actor framework or that that's at least one name that I've

I think taco, we actually have a taco.

So no, I don't think taco is just like the single well for us it's the single like session

context that just threads through everything.

But yeah, I think it was the, maybe it's the actor model message translator.

If anybody's seen that, Google that message translator, like avoid that, you know, go

look at it and then don't do it.

Basically like the mini T mini Elm architecture for componentizing local state.

So that was, that was a pain point.

You guys thought that it was, and you were trying to like automate it.

It sounds like, and we weren't trying to automate that one.

We were just living with it.

You know, again, in the sort of every component should hold its state mentality.

That's the, that was the bad head space that we got into.

The other thing that was actually really helpful was Evan's, Lucky's table library that he

Sortable table.

Elm sortable table.

That was a really great example of the evolution of complexity in terms of how to evolve up

a more complicated component and yet have it fit in seamlessly.

That one was extremely helpful to kind of clarify my own understanding as we were learning

over the years.

That's really interesting.

So, so you mentioned code generation and this is one of the things I've been most interested

to hear your thoughts on because I hear a lot about the, the code gen stuff that you

guys are doing at vendor.

Matt Griffith, we just released an episode about Elm code gen and which is a super cool

tool which I hear you guys are using a lot internally.

So like tell us about that.

Tell us about how that has been like part of your success using Elm and what pain points

it's alleviated and like, what are your, like, what are you using code gen for?

Well, now I want to back up and talk about why Scala is a failure to tell you why I love

code gen and that's, yeah, don't seem connected, but they are.

We got, we got, we got time.

You can indulge.

I mentioned earlier that I like to choose something technically ambitious, both for

the future and to hire great talent.

In the ed tech company we did in 2010, again with my stick, you know, functional programming

with type systems is the, should be the norm, but it's going to be the future kind of disposition.

I chose Scala to write our, you know, our first ed tech startup.

And we raised a bunch of venture money and we did a ton of stuff.

So it wasn't like a kind of a fly by night thing, you know, we have like 15 million in

financing and team of 50 and you know, thousands of students were using us.

The problem with Scala, well, the reason I chose it was, you know, functional type system,

ecosystem of Java is available to you.

Seems like a winner.

However, the problem was twofold.

One, it attracted philosopher kings and queens to interview with us.

These are folks that like want to type about or talk about how monads relate to a billion

I studied all this stuff and I can't even make fun of it properly, but like they will,

you know, there was a large group of people that wanted to geek out on PhD level type

system concepts.

Not to say that those two are, but like they wanted to geek out on PhD level type system,

you know, subject matter versus building an application.

So that was failure mode number one.

The failure mode number two was Scala is like a kitchen sink programming language.

So you attracted smart programmers, but two smart programmers.

I wouldn't call them programmers.

I attracted smart type system philosophers.

That's different.

They're mathematicians by nature, right?

They're logicians, you know, they're not app builders.

It's a fine line.

I would tell anybody, if you're exploring one of these like esoteric, you know, academic

languages to be careful because you really need to be on the lookout for that.

In fairness to those folks, they just wanted to do the thing they loved.

It's just that sort of incompatible with building an app for humans.

But now in vendor, you have a lot of tool builders.

You have Ryan with MSPA, you have Matthew with Elm Cogent and Elm UI and even more I'm

Beyond that, there's a bunch of other cool stuff that I'm excited to evangelize around.

So you just tapped into something, Jeroen, that was like very important life lesson for

Hire people who have shipped product, preferably folks who have shipped it fully on their own.

If you've shipped a little app or a little open source library, I'm your number one fan

because it's really hard to build something from nothing and put it into the world because

nothing ever feels done, nothing ever feels good enough.

But that's a big deal to me.

So like our hiring process starts by trying to find those folks first, right?

People who shipped.

So we were attracting people that didn't ship and that was fatal.

That feels a bit weird to me because I feel like the more I am in this industry, the more

I feel like a tooling author and not someone who builds applications, which I probably

shouldn't tell to someone who I could probably...

But you're shipping tools.

Those are apps.

But I will still get hired to build products, which will not be tools.

So like my expertise will be in things that will not be in the direct interest of the

I think you're being maybe a little bit too critical, but so I can come back.

I am very critical of myself.

We can do a therapy session on that one.

The important part to me is not, are you shipping an app that consumers use?

It's just, are you shipping something self contained that provides value to someone else?

Library account.

Library account deeply.

And if you're leveraging automation for things that help you build apps, right?

That's all the more so.

Like there's something that I've been really inspired by the whole Toyota production system

stuff, how Toyota introspects and adapts their processes and stuff, the whole lean stuff.

And there's a quote I heard once that Toyota is not a car manufacturing company.

It's a car manufacturing improvement company.

They're in the business of improving cars.

And as a result, they happen to have this side effect of producing quality vehicles,

but like they're in the business of improving the process of manufacturing vehicles.

So I feel like that's what tooling authors do too, right?

They're in the business of improving app development, even though it's not directly app development,

it has a helpful side effect of helping you produce great apps.

Do you still keep hearing the opposite?

At least at my company where we say, well, we are not tool builders, we're an application.

We're building an application and we do that by building tools for ourselves, but we should

not lose track of what is really important.

I think keeping your eye on the prize is correct, but again, just to, before we get to our therapy

session a little bit later, if you ship things of value into the world and you've gone through

that pain of birthing something and putting yourself out there, high five, you're above

95 plus percent of folks that otherwise can't do it fully on their own.

They can't do the zero to one thing, taking something from an idea to into the hands of

Nobody can see me, I'm high fiving right now.

You're my people, I love it.

Back to my long winded, long winding thing back to CodeGen.

We were accidentally hiring philosopher kings and queens, big issue.

The second big issue was people, Scala has so much flexibility with the language, so

many deep powers and weird arcane invocations you can make that people would bike shed on

the simplest things because there were 25 different ways to do it.

That was like, oh man, what have I done?

To wit, that company eventually pivoted straight into Ruby on Rails.

That was a failed technical choice on my part, which I'm proud to say I learned a lot and

avoided since then.

Can we go back to one thing that you mentioned at the beginning is like you bet on Elm because

you wanted to make cutting edge choices.

What would you have said if choosing Elm was a wrong decision?

If two years down the line, no one was using Elm anymore and everyone went pure script

or something else?

I'm guessing that's...

I think if it weren't serving us as a company, we would have moved off of it.

I have definitely moved off of technology that does not work for us.

We didn't get into the Lambda backend, but it didn't start as TypeScript, it didn't exist

We started as plain old JavaScript and then we layered in flow type and then we did a

painful migration over to TypeScript.

We will do the heavy lifting to evolve when we need to.

I am not afraid to say I screwed up, this was wrong.

I'm glad I took the bet.

The bet didn't turn out the way I might have hoped, but I learned a lot.

Scala, too many different ways to say the same thing cause a lot of lack of traction

where people are like, well, should we use this dot operator?

Should we do this functional chain thing?

Should this be a functor?

Should this be just a regular library?

Should it be a class?

God only knows.

One of the things with Elm that was so surprising was it removed a ton of deep power.

I think if you show up from Haskell and Elm, you're like, why can't I create functions

that produce libraries and all this sort of like my higher kind at XYZ?

You don't have all that.

It's very straightforward.

Elm code is so straightforward in terms of what it's capable of doing.

The downside is you might have to write a lot of boilerplate, but that's where CodeGen

What you're looking for is a simple language that kind of makes the easy things easy and

the hard things clear.

Not necessarily short, but clear.

Clarity matters more.

We just leaned into CodeGen left and right, not just for like, hey, here's how we do a

page, but oh, do you have to generate some complicated encoder decoder?

Well, we can write a library that can spit out that code and you're never going to modify

that code by hand.

You can modify the upstream source code.

But the beauty is rather than complicate the language, you've kind of pushed it upstream

into your build process and on balance that works so well.

It works so, so well that we use CodeGen all over the place in the front end.

We use it all over the place in the back end.

And I prefer it to advanced language features because then you start getting into this hellscape

of, hey, I'm trying to instantiate a value of this type, but I barely even understand

what the type signature is, let alone what to do with it.

It just makes things really hard.

So one testament, I think, to Elm's simplicity here is we hire people that have never touched

Elm, never touched a language like Elm, have never done stateless programming, where it's

kind of all purely functional.

And they're like, I don't think I can do this.

I'm like, no, no, no, give it a try.

And then they go through it and then we haven't even talked about how good the compiler is

yet, but there's only so much the language can do.

It doesn't actually take that long to learn the basic things available to you.

The conceptualization might be hard, but the tool itself, it's just like, you got some

lets, you got some functions, you got function application, you got your data type definitions,

and you're off to the races.

It's fairly simple.

And that's not the case with Scala.

And so the trade off is, well, you might have a lot of boilerplate, but good news, if you

can express it in a higher order way, you can use CodeGen to bridge that gap.

And so back to the pain of Scala, this simplifies the language and gets me out of that mire.

And I mentioned the third thing was, the third risk was, could we hire people that can learn

I have not run into philosopher kings and queens in Elm land.

I have run into application builders, tool builders, people who like shipping things

and appreciate the relative simplicity, because they're not here to geek out on isomorphism

XYZ, they're here to build things.

And so it's just struck such a hard to explain, but powerful balance for us.

How long does it take for you to, how long does it take for a new hire who doesn't know

Elm at all to be somewhat productive in your opinion, or in your experience?

That's a good question.

I have two schools of thought on that.

Three, two and a half.

One benefit of building in Elm is that there's so many people who are interested in doing

Elm full time, we have not had trouble hiring folks that want to do Elm and already know

it, which isn't to say that if you don't know Elm, we're not willing to teach you, we are.

But how lucky are we that there's so many smart builders out there who already know

this who would love to do it full time?

That's awesome.

That's a real strong selling point for us in terms of our front end.

So you kind of have the same hiring strategy as NoGrading.

You just say, we're using Elm and people flock.

They could flock more.

Hey folks who want to flock, listen in, we're hiring.

We are, we are hiring.

Yeah, it hasn't been a problem.

I can be in different Elm communities and see people doing cool stuff and reach out

and say, that's freaking awesome.

By the way, we're hiring or hey, we use that thing you did.

Thank you so much.

Oh, how are you using it?

Well, I have a team of 50 plus engineers.

Here's how it's all going down.

They're like, oh wow, can I talk to you?

Like, yeah, please.

That'd be great.

So it's a strong hiring advantage for sure.

Now, the world of Elm programmers is still relatively small compared to everything else.

So if there were 20 of us out there doing this, well, maybe it would start to get a

little bit more competitive.

That might just drive more people to learn Elm.

I don't know, but so far so good.

And in terms of teaching people, here we used to hire folks and teach them very one on one,

but we're growing so fast right now as a company that there's not a lot of time to invest in

kind of that hands on mentorship that I love so much.

And we do, I do as much as I can and the team tries to do it, but like it's just challenging.

The rate that we're growing is just such an insane pace that things are breaking everywhere.

You know, you got to really be careful with your time.

What's amazing about it is we, I let folks know that when you join vendor, we're going

to be hiring you either primarily for your backend skills, even if you're a full stack

developer or for your pure Elm front end skills, but you are welcome to cut through the stack,

however you like to get the job done.

So we'll have, you know, folks that ostensibly were hired to be a backend engineer who were

like, well, I want to make this feature real and there's no one else available in this

moment to help me with it.

Let me cut my teeth on it.

And there's a lot of nervousness followed by, I just kind of said what I wanted to have

happen and the compiler took care of the rest.

You know, I can point to like, you know, dozens of Slack messages that kind of back that point

So I think there it's just, we take a learn by doing approach because it's hard to go

I wouldn't do that same approach to the backend.

It's way too easy to, you know, create a security risk or to, you know, conflate customer data

if you do your SQL statements wrong or, you know, otherwise cause an error and blow stuff

You know, on the Elm side, I think the worst outcome is you might have code that someone

else could have cleaned up a little bit better later.

And that's a real low risk.

You know, it's like if it falls in a forest kind of situation, like it's not that big

of a deal in practice.

So we've had, you know, fingers crossed, we've had really good luck with folks that felt

adventurous enough to come up the stack and try it out and kind of happy with what they

You know, we might quibble on the style of parts of it, but it's in the realm of quibbling.

It's not like, oh, you architecturally dorked this thing up.

That would be really hard to do.

Before we get too far away from it, I wanted to dive in to a little more detail on some

of the code generation things, if I could.

Like I think that a lot of people would find this interesting because I personally think

that code generation is probably underutilized.

And I think it's kind of an emerging space that people are really starting to explore

now in public at least.

So I'd be really curious how you guys have leveraged that internally and like, so what

do you use Cogen for?

So you use it for like, I believe you guys have either LMSPA or a similar tool.

And I don't want to steal any thunder from folks that have maybe not released things

that I could talk about.

I've got that on my mind too.

But to be fair, we do have an episode scheduled with the particular person I believe you're

Okay, so I won't spill any beans then.

We'll get into it and you can edit the section out if I've run afoul.

So we definitely use LMSPA ask Cogen for one, which is...

Now we existed before that did.

So we invented this on our own and we weren't using Matt's library because it wasn't out

So we used a tool called Plop.

If anybody's seen that, P L O P. Very simple handlebar templating tool set.

But what's great is, I shared how we struggled with architectural patterns, but we finally

figured out what those patterns are.

And so now when a developer wants to create a new page, you go yarn Plop new page and

it has created the routes to handle URL routing, the T model update view loop, all the scaffolding

It will then launch your browser straight into that page and you'll see a hello world

So it is trivial for us to set up a new page in exactly the right way we want, complete

with analytics, everything, which is awesome.

We have a couple of fun internal phrases and I don't know if people are fans of the matrix,

but agent Smith taught me an important lesson, which is never send a human to do a machine's

Writing boilerplate code is a machine's job.

So we put the boilerplate into this templating library and it spits it out and you don't

have to think about it and it just, it's up and running and you've got that kind of like

tight loop of thought and creation and seeing it live.

So that is freaking awesome.

So that's a big one.

The other big one, here I'll pause in case we need to edit it out.

The other big one is what we're doing with GraphQL now.

I mentioned that GraphQL was one of our earliest bets.

We're big fans of the interplay between GraphQL and Elm, which Dillon, I know you in particular

can appreciate deeply.

It is incredible to have a system where when we launch changes to our scheme on the backend,

we know a priori if it's going to break the live front end and we also never launched

front ends, which are incompatible with the backend.

We don't have those kinds of API errors.

It's pretty insane.

I mean, someone will have a browser that their laptop came out of sleep two months later

and it's like a Rip Van week and the world's different and you get a brief set of errors

before it auto updates.

But in general, it's pretty remarkable.

And there's so much room for automation with that because you've got schema published by

So, what we have now is you can specify a GraphQL query, which our backend team will

do for you, right?

Like, oh, here's the query to generate this kind of information that you'll need.

Feel free to modify it and you can use your GraphQL client library like Altair and Somi

or Postman where you happen to have to kind of make sure you're getting the right data

with your local server.

And then you drop that into a folder and it auto generates all the queries, decoder, encoder

stuff for those queries.

And then on top of that, it will generate this sort of like default set of records to

load that data into and then make it available to that page.

And so, you don't have to do anything except write in native GraphQL and suddenly you've

got a function that returns a well structured object that specifies perfectly the type model

for that query in the first place.

That is an amazing accelerant for us.

I think there were like proto versions of things like this, like JSON encoder and decoder

You give it a sample and it will do this, but a lot more powerful when you've got like

a fixed schema to work with.

And that gives us the benefit too of, you know, we can just go through our code base

and modify or introspect all those files if the API ever changes and make sweeping changes

to the application.

You also get dead code elimination, you know, really fun stuff.

Speaking of, you know, automation like that, we use Elm Review to create a, you know, a

Zamboni task every Sunday that goes and finds dead code and, you know, otherwise it juzzes

up the code base.

So, we lean into that stuff all over the place.

But that actually makes me sad, but...

It makes you sad, why?

Because you only use it once a week.

You should run it every time.

So, I think you have performance issues.

So, maybe let's talk at some point.

Yeah, let's talk.

I'm not saying we don't run it every time.

We at least run it once a week automatically.

But anyway, so, you know, that code gen, you know, if you look at the kind of work that

we were doing before around anything related to encoding and decoding, it's very time consuming

and, you know, at the scale that we're at, right?

And I'm trying to walk away with a line here, Dillon, because I've used and loved your library

And I like, it was instrumental for me in understanding both GraphQL and Elm.

But that said, like, it's one of those things where we're trying to educate new people.

There's a lot that happens, and that's probably the most complicated sort of interplay of

types where you're translating from one type to the next.

So kind of just removing that, except for the cases where it matters, has been wonderful.

Where it matters is when you want to do something kind of more complicated, more nuanced.

You want to go straight into a particular type.

You know, you need to handle errors in certain ways.

But for most boilerplate pages, you're just kind of doing like a query and a write back

That makes sense.

Or if it's just a mutation where maybe you don't even care about getting some data back

and you're just like, send this off.

Fire and forget.

And then we also use CodeGen for, I believe, Storybook.

So we'd like to have our component library available for ourselves, our designers, to

see what we have, see what it looks like.

We have a Storybook plugin that I don't know if we might have written it.

But is it a real Storybook or is it a Storybook like?

The real Storybook.

So we've got type safe bridging between Elm and Storybook because of code generation.

It will generate all the sort of sample stuff for us, including some fuzzing, I think.

So like we can, it's actually, it's a lot of fun.

We use CodeGen and Lean into Automation for, we have a SaaS directory.

So we have this library of like 10,000 SaaS apps plus that we're tracking across the industry.

We have a little Elm app that will help us render these little directory pages.

And there we use a combination of GraphQL, CodeGen, static rendering to produce all these.

So yeah, there's a bunch of use cases for CodeGen.

But in general, I think if you're bemoaning the lack of like functors or higher ordered

kinds or something, like just let CodeGen pop into your head for a second.

You might find like a pragmatic solution for mere mortals.

I really like something that Matt's been talking about a lot recently.

He talked about it on our recent Elm CodeGen episode of instead of this idea that Elm is

verbose, like Elm is verbose, but it's sane, it's safe.

And he's talking about, well, what if we say because Elm is safe and because Elm is sane,

we can use that to make it really convenient, like leveraging that safety to give you convenience.

And then you get the best of both worlds.

And I'm really hearing a lot of that from what you're describing with the CodeGen workflow.

And I think there's like sometimes an extra step that's missing where you mentioned like

automatically generating JSON decoders and encoders.

I imagine a lot of people are going to websites for automatically getting a JSON encoder or

decoder, dropping in some JSON, which they fire off, however, through some REST client

or Insomni or something like that.

And then they copy paste that into some tool online and then they copy paste the JSON encoders,

decoders they get.

I think there's some automation missing in that process where they're copy pasting JSON,

they're pasting it into an online tool, they're copy pasting that generated Elm JSON decoder

And when you take that little bit of glue and maybe you are using some tool to automatically

write a file with your JSON decoders and maybe it's automatically wiring it up for you somewhere.

The things you're talking about are making me think how much that last mile effect is

And I think there's a real opportunity for people to lean into the CodeGen more there.

I was like champing to the bit to interject.

No, I love this topic.

I think that...

You know what I've seen through the Elm community over the years, and I don't mean like the

kind of folks that are in it and kind of part of the Elm and Noddy.

I'm talking about the new entrance to the world.

It's hard for folks to do basic things out of the box.

And by basic things, I mean trigger an HTTP API call and decode the response.

And we've seen this over and over with beginners, decoding things in a type safe way is just

unnatural and challenging for folks that have learned from the Python or JavaScript or those

ecosystems that do the automatic object translation.

It's like, why do I have to do this?

This language sucks.

Why is it making me do this?

Because they haven't yet fully grok the power of type safety.

And they're being asked to serve this new type safe master by doing a bunch of what

I wouldn't call it boilerplate.

I'd call it like, but why am I even doing this at all?

I don't get it.

Just do it for me.

And that's really unfortunate because I think anybody trying to build an Elmap of substance

is going to call an API call really, really in its life cycle.

And they're going to get burned by this conceptual mismatch.

But it doesn't have to be that way.

I would encourage folks even to ask this frankly in the Elm docs of getting started.

You could lead into a world where you take a TypeScript type definition, a swagger definition,

or even just a sample blob of JSON and have a tool that spits out a decoder for it that

will just work and say, don't worry, this piece may feel like magic.

We're just saving you from writing this stuff by hand.

You may want to write it by hand later because parse don't validate is like the coolest concept

But just to get you going and make sure that you don't feel like there's any impedance

mismatch between I want to build an app and I heard this is a cool way to do it.

I find that's true with beginners up until they write their first JSON decoder.

And then they're like, screw this thing.

Why am I doing this?

And that's unfortunate because it gets better.

It gets so much better.

But I feel for folks that run into that.

That's a very like, yeah, I don't understand that.

And I don't have the context yet to get it.

And even if you did have the context, I don't want to spend my time writing decoders.

I want to make the app.

Nobody wants to spend time writing JSON decoders and non coders.

But Elm developers have chosen that they don't want to debug a no pointer error in the dark

recesses of their application logic because the contract was not what they expected either.

And so we've chosen that trade off in the Elm community.

But what if you didn't have to make a trade off?

What if you could have the convenience?

And like Evan has a gist where he describes his Elm interchange vision, I think is the

name of the document.

Yeah, for data.

Data interchange or something.

Data interchange vision.

So I think it's really cool to talk about automatic serialization, deserialization tools and languages

like Haskell where you can say serialize this type and it infers a JSON decoder essentially

And, you know, people can say, well, why don't we just do that in Elm?

But the fact is, then you're introducing magic.

You're introducing an extra layer of abstraction to understand how the language works.

And if something goes wrong, what do you do?

Well, now my and now your types are coupled to your logic of, you know, the serialization

format and deserialization format, which is a weird coupling that eventually you're going

to want to get around somehow.

And then you have to build in hacks for that.

And so like decoders are great.

They're just inconvenient.

But what if they were great and convenient?

Now there's no problem.

So if you go at it from that angle, code generation can like alleviate a lot of things we don't

like while giving you the things we like, explicitness, debug ability, traceability,

simpler mental model.

Violent, violent agreement.

Emphatic agreement.

And and I'm so fearful of additions to the language that would take it back to what I've

And, you know, Scala and those other sort of air quotes, more powerful systems.

We want simple and we want clear.

And you know, if you can remove the friction via things like this, that's great.

I would love to see a lot more code gen.

There's probably some norming we'll have to do as an ecosystem around it.

Like do we have, you know, code gen directories or code gen file, you know, dot code gen dot

But some, you know, let's start establishing some of these patterns so that people, when

they see code gen don't, you know, run in fear, they know how to operate it and and

can benefit from that kind of friction reduction because it's it's it's big.

And it keeps the core language simple.

And that's so maybe it's not underrated, so valuable to me at least that that, you know,

I wouldn't ever want to pervert that.

I'm I'm curious, Aaron, do you have thoughts on you've talked about betting on elm at

BlizzFly at vendor and how it panned out has turned out to be it sounds like an important

tool in the toolkit for success.

Is that something that the types of problems you're solving make it uniquely well suited

Are there like spaces that it might not be suited for?

Do you have any opinions on that?

You know, I I'm going to run run the risk of being like, you know, too much of a bombastic

fanboy, but I've got the weight of a business behind me that maybe can help cover.

Use it, use it, use it.

Here's, you know, my fundamental belief, right?

Like you should need to make impossible states impossible.

Thank you, Richard.

We want to stand on steel girders, not, you know, mud foundations.

And so, you know, or the more constraints you can build into your, you know, your fundamental

tools, the faster you can go.

And I'll say in startups, I have a quote, startups, I'm borrowing and modifying injuries

in Horowitz here.

Startups are eating the world, but startups eat, but software is eating the world, but

software eats other software first.

And the reason I believe that is because, you know, everything is going to become a

software business to some degree.

It's really easy to clone software that you've seen out in the wild because someone's done

the hard work of finding a business model that software can help with and then kind

of encoding the domain and providing the value.

And so, you know, speed matters a ton and nothing kills speed like retreading, you know,

where you've been historically, right?

So if you're always fixing bugs, if you're always kind of slowing down to, you know,

do things that a computer could otherwise do for you, you're losing the, you're losing

the war, which is determined by speed.

And so Elm has given us such incredible speed of development.

And it feels weird to say, and I think, you know, the, when folks hear the number of like

front end developers to back end developers here that we have, I don't know, call it like

a, it's like a one to 10 ratio.

Wait, one front end for 10 back end?

Yeah, that's about where we're at.

Now that seems insane.

It seems like what I hear internally is, oh my God, your back end must be really complicated.

Well, it's not as simple as I'd like it to be.

That's true for everything because, you know, I have, I'm never satisfied and have high,

high hopes and dreams for everything.

But it's actually because our front end engineers are so freaking productive that they can do

so much on their own.

I don't need, you know, a lot of pods typically are like 50 50 front end and back end because

you're just that hard to write quality front end apps.

That's not the case for us.

It's actually like we get by with very few folks on the front end, which is amazing.

And we've started raising our ambitions.

What we're coming out with in, it's an alpha now, you know, being beta soon and GA, you

know, before end of year, we have this beautiful, beautiful workflow builder.

It's like two products smashed up into one.

It's like type form for, you know, designing forms in the fly.

We love our types in a type safe way.

So all the data, we know the types and from a customer perspective and obviously the infrastructure.

So that's part one and then part two is this like drag and drop, you know, pan zoom, re

layout reflow diagram build, you know, on par with the best.

And it's all built in Elm and it's incredibly fluid and highly animated and running at like

60 frames per second.

And it's just bonkers.

So like on the one hand between code gen for pages, code gen for queries and our graphical

API, we could spit out, you know, boring business pages in the app left and right, like nobody's

business and maintain them really, really easily because when something would break,

we know everywhere it breaks.

We don't need like, you know, tests harness everywhere and humans manually traipsing through

pages, you know, every bill, there's something terrible like that, which in a lot of companies

And we get to have these like highly interactive, really satisfying, almost video game quality

ask experience in terms of, you know, what it feels like to build the thing is just super

So it's like, yeah, what is Elm good for?

I'm like, well, I just, it feels like both right now.

You know, like I can spit out business pages and experiments really rapidly.

We can build incredible consumer S quality experiences.

I feel really great about it, you know, and we do it with very few engineers relative

to, I think the normal ratio that other companies have with zero errors in production.

Like how could I not be been, you know, bombastic about that?

Like it's hard to contain my excitement for where we're at and what it means for us over

the next couple of years.

Like I'm just thrilled by the setup that we've found.

And again, it may not have ended up that way in a different universe, but in this one it's

working, you know, amazing.

I think I'll let my enthusiasm derail me from answering your original question.

Oh no, I mean, I think you answered, I was just asking, you know, I mean, to be fair,

what other response could I expect?

I mean, I was genuinely interested to know if there's something particularly about vendor

that makes Elm a good fit or if, you know, I mean, I'm sure there are certain types of

use cases, but for, it does seem like building, I don't know, maybe if you just are pulling

a bunch of off the shelf libraries and that's all you need and you don't have a lot of business

logic, that's like the classic thing that I think about for maybe Elm's not the right

You know, it's tough for me to say, I'll tell you what we have not done yet that would be

a little bit less clear to me.

Like we, well actually a few more things, you know, some people are like, well, server

side rendering Elm doesn't do that yet.

And in fact there was talk of like 0.20 doing server side rendering, if I recall.

Not a problem for us actually, because the only time as a business we care about that

is for SEO purposes.

And there what we do is we have Lambdas render the Elm, thunk the API, serialize the Dom

and then send that to S3, you know, for like cloud caching at the edges.

And that's exactly what Google wants to see.

So there's no loss there for us.

You know, we do a lot of that and that's great.

And then maybe you'd think, oh, like streaming interfaces, you know, highly like real time

web sockety things.

That we have not explored yet.

You know, I don't know what it would be like to build a Figma in Elm.

You know, if it renders a billion bucks, we just saw a Figma exit for 20 billion.

So maybe real time matters, you know, we're going to figure that out.

I actually don't have enough experience to say, oh, Elm would be great for that.

I do believe there's plenty of experimentation making video games in Elm.

And I think those folks are kind of answering de facto whether that's doable or not and

how that scales from a code standpoint.

I'll defer to them because we don't have a need for it presently.

But you know, I built EdTech, I've built consumer, I've built B2B and there's nothing about

we're doing that doesn't presently feel like it'd be appropriate for all of them.

I guess mobile, you know, you can put me in a corner, I'd say mobile.

Like if you're going to do it native, go native and maybe React Native is better than what

you'd get from Elm until someone has built Elm native.

And you know, maybe that exists already.

I have no experience on that.

So I couldn't say.

But yeah, otherwise it feels pretty versatile.

So something that we've seen asked quite a lot in the Elm community is how do I convince

my CTO that we should move to Elm?

And there's probably no one asked you because you already chose Elm from the get start.

But yeah, do you have any advice on that?

Like how should one talk to their CTO or how would you even talk to another CTO about recommending

Boy, do I share this person's pain.

And by this person, I mean the dozens and dozens of folks that I've seen ask that in

Yeah, it's a lot easier for me.

I didn't have to convince anybody but myself.

And I already had the background in programming language theory and type systems that allowed

me to appreciate what those mean.

I think in a lot of ways, the reason or one of the ways I think people struggle to convince

their teammates or their boss to use Elm is because Elm feels a little bit like shooting

Like if you go all in on it, you won't get errors.

But that's not a very gradual slope.

And so if you've never experienced the literal magic of no errors and insanely robust, and

that undersells it, perfectly robust refactoring, you do not have the mental model to appreciate

what the language can bring.

And so trying to convince someone that's never used one of those languages that this thing

is that powerful sounds like crazy sauce.

Like it's just such a giant bridge.

So I'm really sympathetic there because I'm in CTO groups.

I talk to my peers about, here's what we're doing.

Here's how we get away with so few folks that are so powerful and so productive.

We don't have these kind of errors you're talking about.

Like it just never happens.

And I honestly think that even though I would like to believe my fellow peers in those groups

respect me and would default, give me the benefit of the doubt, it's not like I'm going

to follow it up in any way.

Like, hey, I'm actually thinking that might be right.

Like can we talk more about it?

It's just, it's too out there.

So that is a really hard one to solve.

I think there's a couple of ways to solve it over the medium to long term though, which

is more conversations like this, more companies saying they've had success like this, which

means more projects start with this kind of tech stack in the first place and skip that

whole who do I need to convince.

I think the other ways to approach it are, it's cool that you can embed Elm inside other

You can embed a little Elm experience inside an existing webpage or a react app.

That's awesome.

Using web components again.

Using web components, right?

That's really cool.

But I think the challenge still remains, which is any amount of Elm in a code base means

that someone has to understand this mental model.

People have to be comfortable learning how to work in a functional system.

That's just a far bridge for folks.

So this gets to the same pain I had with like, why isn't the world using standard ML in like

the 2000 era where I'm like, no, this is obvious.

Well, it wasn't obvious.

It's still not obvious.

I think the tides are shifting though.

I think between TypeScript, Rust, like these very popular languages now that have type

systems in them and people are moving away from the pile of mud that was JavaScript or

the security hellscape that is writing kind of native C code.

These languages are educating a whole new generation of folks on why data modeling is

so important and how to do it in a really sound way.

Rust more than TypeScript, obviously.

That I am hopeful that folks will show up with the right default perspective in the

future to go kind of all in on these things.

Maybe that's wishful thinking, but the trend seems to be finally pointed in the right direction.

So a lot of companies are starting to use TypeScript now and I'm guessing that they

want the same guarantees that the Elm gives you or at least that's the direction that

it wants to go to.

But TypeScript and Elm are not equivalent.

You have experience with both.

How would you tell a CTO, no, TypeScript and Elm are not the same?

Again, this is so true and so frustrating.

It's like that shooting the moon.

Like, well, we have TypeScript and we still have errors.

I'm like, oh my God.

You are TypeScript.

I love that we have it because we have a JavaScript backend.

So like, thank God for TypeScript relative to the alternative.

But you can still drop to any.

You can still have mismatches with your types and your libraries.

Things can go weirdly wrong all over the place.

It is nowhere near as rock solid sound as Elm.

And unless you've played with a language from the Elm universe of languages, you really

have no hope of appreciating it.

That's the thing that burns me.

It's like you have to get someone to play with it and see before they'll have that aha

moment because otherwise you'll have these false equivalences.

You can write anything in any programming language.

Types aren't all they're cracked up to be.

They don't solve everything.

It's like, well, what type system did you use?

Like Java with nullability and class casting and all this factory pattern nonsense that

seems really painful.

Yeah, I can see why you think that.

Or TypeScript, which is also really freaking complicated and not bulletproof.

I can see why you think that.

Dear world, please, and this audience is deaf ears because you're already there, but please

Try a Haskell, try an ML.

I'm not saying you would use those other ones in production in quite the same way, though

But it is a world of difference.

I don't have a good way to help bridge that gap.

I can see it really clearly because we live with both, but you have to experience it to

You crack that.

You figure out how to communicate that to folks without them having to experience it

and the floodgates will open.

But I have not in my 20 year types crusade figured out how to do that because the nuances

matter a ton and Scala, Java, TypeScript are not the same, nor is Haskell.

So there's a real Goldilocks thing going on here.

It requires a lot of ecosystem experience, I think, to appreciate.

I wish I had a better answer on this, honestly.

If you're CTO, I won't use Elm.

Email Aaron.White at V and the R.com and we'll solve it.

But I would like more folks to use it.

I think it would create a better world for sure.

And it would be much more satisfying and robust.

But I haven't found the magic turn of phrase yet to skip people into that aha moment.

I mean, they will try Elm and then they will be stumped by JSON decoders.

So then it's game over.

So I think as a community, we can start solving the onboarding problem here and showing some

of that power sooner and not getting people caught up in things that they take for granted

from the simplicity of other languages today.

Well, the reason it's so easy in JavaScript is because all bets are off.

But you don't know that because you've been living in that world and you've got Stockholm

syndrome and you think that null references must be a part of life.

And they don't need to be.

That's the deep secret.

They don't need to be.

You're just you've been abused for so long.

You didn't know any better.

But there's a better way.

On that topic, what do you think that the Elm community needs to do to grow?

Because it's not like we've seen the Elm community explode in numbers.

I think in part due to the fact that COVID happened, there were a lot of conferences

that were canceled and I'm sure other reasons.

So what do you think it needs to do to grow?

And what would you like to see happen in the Elm community?

I think there's three things that I'd like to see, one of which I'm responsible for.

So maybe I'll start there, which is I think folks that are using Elm need to just publish

more, whether that's libraries or blog posts or technical analyses, whatever it is, publish

If you hear that vendors a billion dollar company and it's on a tear and all this great

stuff is happening and you see our reports from Sentry that show you exactly how few

front end errors we have and how it was grammarly until we fixed that one weird thing.

Not yet, but I'm putting the onus on me right now.

I'm saying we need to be doing this.

Anybody who's using Elm needs to be publishing more.

And credit to the folks that are, like No Red Inks of the World, et cetera, published

left and right.

Richard has in this way as well.

So that's valuable.

We need a lot more of that.

Number two, and the COVID thing really bums me out because we were starting to host Elm

meetups and it's just awesome to talk with folks and it's hard to replicate that kind

of, oh, this is real.

This isn't some weird forum online.

So COVID really is a bit of a downer in that regard.

But I think more examples made easier to access.

So I would love if the Elm page leaned into marketing a little bit more than it does.

I'm talking about like elm.lang.org.

None of us can change that one exactly, but we've got some maybe social sway here.

I think that matters.

I think it's one thing to keep a page simple and say, here's what we do and here are the

But to link out to a well structured gallery of all the cool apps that have been built,

the techniques, things like that, I think shows the actual momentum of the community

in a way that you can't find in your first contact.

You go to a lot of pages and they'll be like Facebook, Google, da, da, da, da, da, and

it's like there's social proof.

We have some social proof.

It's not quite the same, but it's only going to get better.

So leaning into that or galleries, but otherwise just investing in that, sharing what's already

been accomplished.

It's not even making stuff up.

It's not being mobastic.

It's like, let's just put it out there and that doesn't need to be corporate logos because

I know that some folks will hear me saying that.

I think that I want my logo plastered all over a bunch of pages.

It literally could be galleries of apps, links to blog posts, but spend more time on that

Then I think this one takes a long time, but I think some bootcamp needs to start with

We need to get Elm injected into the education of coders earlier.

I think one big problem that languages like Elm have is by the time people get exposed

to them, they've already been mutilated by having done some work in some other lesser

Every bootcamp is teaching everyone how to do React.

But React is super complicated at scale.

It's real weird.

A lot of problems with it.

It's not a panacea.

But once you've learned procedural code, once you've learned object orientation, once you've

learned this framework, you have a fixed set of assumptions about how the world could

or should work that are harder to undo later.

But if you get in earlier, you can make folks lives easier.

I would say this is the thing that always got me.

There's, backing up to my Comp Sci background, there's Turing machine based languages, the

procedural languages, and there's Lambda calculus based languages, the functional languages.

If you have coded at all in both of these, you are a superhero because you can see through

the matrix of how this stuff all works.

But most folks only ever get exposure to procedural languages.

And they do their long term cognitive ability, a massive disservice by not giving themselves

this alternative model, which I actually think is easier to reason about.

That's the other crazy part.

It only seems so hard because the world discovered it and kept promoting it through the lens

of math programs and computer science, the philosophy logic arm, not the computer engineering

And so it's like it leans way too heavily into theory when in practice it's actually

way simpler to reason about.

Your function is inputs and outputs.

There's no outside world except those two things.

I can write that.

So I think getting folks educated earlier in their careers in this stuff is its own

form of opportunity.

One, it's a 20 year horizon, but you could serve the broader realm community through

But two, I actually think it would make for better coders because I think you start to

learn about constraints and functions and reasoning at a kind of a pure level versus

a hack the machine to make it work by doing weird little copy paste incantations.

It's somewhat unfortunate that the biggest selling point of Elm is look at how nice it

is to work with existing code.

And when you're being introduced to something new, that's not the first thing you do.

So you don't get to experience that, let alone a larger scale, more complex real world situation.

So you don't get that sensation.

And what's more, one of the pain points that we've been talking about is the boilerplate,

the multiple sources of truth for wiring up a single page app and wiring up JSON decoders

and things like that, just getting all those things in order.

But hopefully, so that can be people's first experiences.

Oh, I have to write a JSON decoder to do this.

Oh, I have to wire up all these things.

But then you get things like Elm SPA making that more mainstream, a more normal way to

And suddenly, that initial experience of playing around with Elm hopefully becomes more frictionless.

And so I hope that our future has more of this type of thing.

Yeah, I would hope so too.

And I think at the end of the day, with the refactoring ability of Elm is something you

only appreciate when you've done large scale refactors and failed frequently.

Suddenly, it becomes a lot more attractive, but if you're just starting out with it, you

have no basis to appreciate the difference because you've never experienced it.

And you're not going to get there right away either.

It's going to take your own corpus of work to then see the power of it.

Yeah, that's tough.

I think I mentioned this on a different episode, but I think that if someone starts learning

Elm and then they discover JavaScript, they'll be like, oh, this is so much simpler to do,

like JSON.parse or mutating something.

This is a lot less code to write to do the same thing, without understanding that there'll

be trade offs like crashes and stuff like that.

I'm not entirely sold on the fact of learning Elm first, because I think people will be

jealous of easier solutions or seemingly simpler solution that will seem simpler than Elm.

Yeah, I wonder a little bit on that.

Nobody played Delos Advocate, which is you're probably already a good JavaScript coder,

so you don't remember the pain of learning JavaScript or your first procedural language

as much anymore.

But I learned on C, so it's burned like PTSD scar tissue for me because things would just

like crash, segfault, like no feedback, no idea why that happened.

And having to manually reconstruct the whole program I had every time to find out that

I abused a pointer somewhere, to literally reload all that context because I had no steel

girders to stand on was brutal.

This is why I think my professor said that thing once upon a time, which is like, the

only thing you can do is write programs that don't make sense.

Well, yeah, because all I'm doing is I have a mental model of how the code should work,

and I'm looking for where my keys hit the keyboard, and it mismatched my preferred understanding.

There's this segfault pain loop in the middle to get me there.

Why can't I just tell the computer this stuff?

So I think a lot of folks learn JavaScript the first time, run into null reference exceptions,

undefined is not an object, things like that, and are just left like, just, what the hell

And it takes a while to get through that.

Once you're past it, yeah, JSON.parse does seem easier.

But you have to feel the pain, right?

Yeah, you got to feel the pain first, and that's the part that I think senior coders

have forgotten, is just how awful that was.

Versus when I show people an Elm compiler error, they're like, oh, I wish I had this

when I was learning to program.

That's usually the first response.

I wish I had it too.

It's like a buddy telling you, oh, I think you mistyped this.

Did you mean this thing?

Like, oh, thanks, friend.

Yes, I did mean that.

Let's keep going.

And comparing a trust alter to Haskell or ML, the culture of even those, and I'll speak

more to ML, was like, function f goes from alpha to beta to gamma to whatever.

It's like you're not even talking in terms of type variables that have human names.

The culture is just throwing a mathematical blah bar.

And then it's no surprise nobody bothered to invest in compiler errors that were readable

by humans because the types were inscrutable anyway.

So saying you can't unify this to this didn't matter because it was some strange Greek symbol

to some other strange Greek symbol.

The world's evolved a lot since then.

The compilers can do more and they can be helpful copilots in a way that no one ever

thought they would be previously.

They were theorem provers.

That's very different.

So I think that the value of that as a pedagogical tool is massively underrated, mostly because

most people that, again, I think you've just internalized the pain too much.

We're all here with abuse and Stockholm syndrome and it's hard to see past it.

That's my theory anyway.

Well, Aaron, thank you so much for this conversation and for all the open source stuff that's coming

out of Vendor, for sharing your story, for being social proof of a company that's using

Elm as part of the core of their success for a very successful large business.

Thank you so much.

This has been a pleasure.

Thank you both for having me.

I really appreciate the chance to stand in that soapbox for a little bit because I could

do this all day.

This is a lot of fun.

We are fortunate to be playing with some really awesome tech to do really cool things and

it just feels great to share it.

It feels like a great time for Elm.

What should we leave people with?

Is there anything you want to share before we say goodbye?

Life advice, self serving requests to the community.

Number one, I think this is a good kick in the pants for me to make sure that we publish

what we're doing to help other folks that would do the same or seek to convince their

peers or their bosses that this stuff could work.

I feel your pain.

Maybe I can arm you with a little bit more ammo than I'm doing today, which is not nearly

So that's my takeaway.

The easy one is we're hiring.

But I think the thing that I love though is just how much better a coder Elm has made

myself and others in terms of just I have a newfound appreciation for the quality of

your domain modeling influences the quality of your code and the quality of your product.

And Elm really brings the domain model to the forefront as opposed to an unarticulated

abstraction in your head while you're coding.

And that's huge.

And so if you're not yet thinking in that way, domain model first, types first, I would

encourage folks to try it because that's the beginning of that switch over from I'm just

kind of like throwing things together to like making truly scalable systems that are pleasant

So best of luck.

Thanks again, Aaron.

Until next time.

Thanks for your time.