spotifyovercastrssapple-podcasts

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.
October 10, 2022
#67

Transcript

[00:00:00]
Hello Jeroen.
[00:00:01]
Hello Dillon.
[00:00:02]
Have you ever wanted to invite a unicorn onto the show?
[00:00:07]
Yeah, all the time.
[00:00:11]
That's what I'm dreaming about.
[00:00:13]
After Matthew's nightmares, I want my dream unicorns.
[00:00:18]
Yes, let's make our dreams come true.
[00:00:20]
Well fortunately we've got Aaron White with us.
[00:00:22]
He is the CTO of Vendor, which is newly announced as a billion dollar unicorn company using
[00:00:29]
Elm.
[00:00:30]
So Aaron White, thank you so much for joining us.
[00:00:31]
Yeah, thank you guys for having me.
[00:00:33]
It's a pleasure to be here.
[00:00:34]
Likewise.
[00:00:35]
And I'm sorry I didn't dress up in my unicorn pajamas for the occasion, but now that you've
[00:00:41]
thrown it out there, that might have added a bit of fun flair to this meeting.
[00:00:45]
Absolutely.
[00:00:46]
Yeah, well it's really exciting to have you here.
[00:00:49]
I mean you guys at Vendor have done a lot of cool stuff over the years, a lot of cool
[00:00:53]
open source projects.
[00:00:54]
Matt Griffith is out there at Vendor.
[00:00:57]
Also it's just great to talk to a billion dollar company and the CTO of a billion dollar
[00:01:03]
company about using Elm in their tech stack.
[00:01:06]
I'm really pleased to get to have that conversation.
[00:01:09]
I am pumped to have it too for so many reasons.
[00:01:15]
How fortunate are we to be in a position, although I tell the team all the time, it's
[00:01:19]
kind of like the day one thing at Amazon.
[00:01:21]
You kind of have to keep re earning it.
[00:01:23]
It's not like you don't get the label and then get to coast on it.
[00:01:27]
There's a lot of hard work ahead of us, but a lot of awesome hard work we've already done.
[00:01:31]
Yeah, I'm super cool that it's a company using Elm because I've been, we're going to talk
[00:01:37]
about this, but we've been using Elm in the code stack since I want to say early 2017.
[00:01:43]
I remember, and it still happens today, people ask, oh, can you build scalable companies
[00:01:48]
using Elm?
[00:01:49]
Is this production ready?
[00:01:51]
Which is laughable to me.
[00:01:54]
I'm excited to share that perspective a little bit more broadly.
[00:01:57]
Is JavaScript production ready?
[00:02:00]
Less so.
[00:02:01]
I think whatever that metric is, it's less ready for production than Elm happens today.
[00:02:07]
We know, Matthew, from Blissfully and other people from the Elm community from Blissfully.
[00:02:15]
My understanding is that vendor acquired Blissfully and hence the name has changed.
[00:02:20]
Can you explain to us what happens or how things happen?
[00:02:23]
Absolutely.
[00:02:24]
I'll give you a tiny bit of my background.
[00:02:27]
We'll probably get to a little bit more later, but I've been doing tech startups for 20 years,
[00:02:32]
which explains all the white in my hair and my beard.
[00:02:36]
I thought it was the last name.
[00:02:38]
Yes, it's the last, name is destiny.
[00:02:43]
About 2016, my cofounder, Ariel and I, it was actually the second company he and I had
[00:02:47]
built together.
[00:02:48]
We built an ed tech company together in 2010 using Scala, which come back to that.
[00:02:52]
We started Blissfully in 2016 and we chose to help people wrangle with what happens when
[00:02:59]
you're just consuming so many SaaS apps, you lose track of them.
[00:03:02]
How does that transform IT, finance, operations, your employees day to day lives?
[00:03:08]
It's complicated.
[00:03:09]
That's why we started that company.
[00:03:10]
We would help people figure out what SaaS they had and then help them do all the things
[00:03:15]
they needed to do with it, whether it was optimized for spend or on and off board employees
[00:03:21]
or on and off board applications.
[00:03:23]
We would be there as a system of record of all your SaaS with a workflow engine that
[00:03:27]
would help you transform your inventory and your relationships to it.
[00:03:32]
Vendor started a few years later and its mission was to, and still is, to help people acquire
[00:03:39]
SaaS at fair prices with less headache.
[00:03:43]
If you're a fast growing company or if you acquire a lot of software, it's really time
[00:03:48]
consuming to acquire that software.
[00:03:51]
You've got to go evaluate it, do legal, do security, compliance, negotiate with it, sign
[00:03:58]
a bunch of documentation, convince a bunch of stakeholders, et cetera.
[00:04:02]
It's complicated, it's slow.
[00:04:03]
On top of that, you don't know if you're getting fair prices because I think we've all seen
[00:04:07]
that you get to the enterprise tier and it's like, call us.
[00:04:09]
It's like, okay, well, great.
[00:04:11]
I'm in the dark.
[00:04:12]
I don't know.
[00:04:13]
We have at Vendor all sorts of data and knowledge about what fair prices are, how to acquire
[00:04:19]
things efficiently, and we can really help our customers navigate that procurement process
[00:04:25]
with a lot of confidence, better results, and much faster.
[00:04:28]
That's Blissfully, that's Vendor.
[00:04:31]
You can see why these two things go really well together.
[00:04:34]
If you're going to be trying to help your customers procure their SaaS, well, it certainly
[00:04:39]
helps to know what they have.
[00:04:40]
It helps to know what they've historically been paying for.
[00:04:43]
It helps to know who's been using it historically.
[00:04:45]
It would help to have workflows drive and mediate that entire process.
[00:04:50]
It made so much sense for these two companies to become one.
[00:04:54]
I spent a couple of years in venture capital.
[00:04:56]
I've looked at a lot of M&A over the years and a lot of acquisitions fail.
[00:05:02]
People get a little too optimistic, they're too rosy eyed.
[00:05:05]
This is one of those that just made too much sense.
[00:05:07]
It was a little bit too good to be true.
[00:05:09]
So far, so good.
[00:05:10]
I think it turned out to be true, which is awesome.
[00:05:14]
So the two companies formed up into one and it's been awesome.
[00:05:18]
In terms of technology, the Blissfully tech stack, which is Lambda, TypeScript, GraphQL,
[00:05:23]
and Elm, code name legit, throwing an I for immutable.
[00:05:27]
So Lambda, Elm, GraphQL, TypeScript, fans of our functional style.
[00:05:31]
That tech stack now underpins all of the vendor offering.
[00:05:35]
What we've been building since late 2016, early 2017 has now become the platform for
[00:05:42]
this combined company.
[00:05:43]
We're off to the races yet again.
[00:05:46]
So that's a bit of the backstory of how we found our way here.
[00:05:49]
Amazing.
[00:05:50]
I'm really curious to hear about the origin story of picking Elm for the tech stack.
[00:05:58]
What did that look like?
[00:06:01]
What was the motivation?
[00:06:02]
Were you considering other things?
[00:06:03]
Were you moving from something else?
[00:06:07]
This is great.
[00:06:08]
We have a lot of time to talk, right?
[00:06:09]
There's so much.
[00:06:10]
Yes, we do.
[00:06:11]
There's so much wrapped up in this question.
[00:06:15]
Let me frame a couple high level arcs and then I can deep dive on each of them.
[00:06:20]
Number one, when I went to school for computer science, I got introduced to standard ML and
[00:06:25]
my mind was blown.
[00:06:27]
I was like, how is the industry not using this?
[00:06:30]
This is the most amazing thing I've ever seen.
[00:06:32]
I was a self taught programmer, I've been using basic and Pascal and I taught myself
[00:06:36]
C and C++ and then went deep in the world of Java.
[00:06:39]
Then when I got exposed to standard ML, I was like, oh my God, this is clearly correct.
[00:06:47]
Strict static type safety, functional programming, separating behavior from state.
[00:06:51]
Like, oh my God, the world's going to transform after I bring Moses with tablets or Prometheus
[00:06:57]
with fire.
[00:06:58]
I'm going to bring this out of academia and into the world, everything's going to upend
[00:07:02]
overnight.
[00:07:03]
It didn't quite happen that way.
[00:07:04]
I know that Elm has been inspired by standard ML, but I've never seen any standard ML actually.
[00:07:11]
Yeah, standard ML, I mean, Elm is a marvel for so many reasons.
[00:07:14]
The primary one being, I think it's restraint in terms of what features and functionality
[00:07:19]
of ads.
[00:07:20]
Standard ML was invented to help language designers and programming theorists do their
[00:07:28]
modeling work.
[00:07:29]
It was a language purpose built to write compilers and type checkers in.
[00:07:33]
It's weirdly self referential in that way.
[00:07:38]
Extremely powerful, but also it can be very complicated.
[00:07:43]
I would say on balance, not as complicated as I'm probably making it sound.
[00:07:47]
I think Scala is way more complicated as an example, but it's got algebraic data types.
[00:07:53]
It's got functors so your modules themselves can be functions.
[00:07:58]
First class continuation is an incredibly powerful feature.
[00:08:00]
I don't think I've ever seen or haven't seen since.
[00:08:03]
I'm sure some languages have it and the audience can correct me on that.
[00:08:07]
That was my first exposure to that type of programming language.
[00:08:12]
For what it's worth, actually, immediately after college, I did try to start up a business
[00:08:15]
around standard ML thinking truly this was like bringing the fire of the gods to the
[00:08:21]
masses.
[00:08:22]
It's not to be.
[00:08:25]
The important thing here in the context of why we chose Elm was that I knew the power
[00:08:30]
of functional programming and type systems, the amount of leverage they give folks.
[00:08:35]
It would be a recurring thing in my career.
[00:08:37]
The long and short of why I think it's so powerful is that restriction is expression.
[00:08:43]
What you choose to make impossible is as important as what you're attempting to do.
[00:08:49]
I think Richard Feldman has the best phrase ever, which is make impossible states impossible.
[00:08:54]
That's such a good framing.
[00:08:57]
If you can make guarantees about your code, why wouldn't you?
[00:09:01]
In fact, a professor at Carnegie Mellon where I went to college said, the only difference
[00:09:06]
between languages with these type systems and languages without is that in languages
[00:09:11]
without type systems, you're free to express programs that don't work.
[00:09:15]
That stuck with me.
[00:09:16]
Because we know there's a touring equivalence between things.
[00:09:21]
What are you really saying?
[00:09:22]
You're saying you can write languages that have undesirable states.
[00:09:25]
Great feature.
[00:09:26]
Yeah, great feature.
[00:09:27]
Why would you want that?
[00:09:28]
As coders, we should be trying to find the most amount of leverage we can.
[00:09:33]
The thing I didn't appreciate back then, which I have a much stronger appreciation for now,
[00:09:37]
is the cognitive load and the pedagogy of how you onboard people into these things.
[00:09:46]
It's really easy to get someone maybe into Python, and it's a little bit harder to get
[00:09:51]
them into one of these systems.
[00:09:52]
I don't think that's universally true.
[00:09:54]
I actually think it's maybe if you started with Elm, might be easier to understand other
[00:09:59]
program languages versus start with procedural ones and coming back.
[00:10:03]
This is one big background thread in my head.
[00:10:07]
My first attempt to actually force it was in 2010 when we started that EdTech company.
[00:10:12]
I chose to use Scala.
[00:10:14]
That was a disaster.
[00:10:16]
Total disaster.
[00:10:17]
I'd love to come back to that, but I'm trying to get to the why Elm.
[00:10:20]
Sure.
[00:10:21]
Almost there.
[00:10:22]
That's one big thread.
[00:10:23]
The second big thread is whenever I start a company, I try to make a few strong technical
[00:10:28]
bets for two reasons.
[00:10:30]
We're talking cutting edge.
[00:10:32]
One thing that if you're starting companies, whatever tech stack you pick now is going
[00:10:36]
to be the tech stack you're mired in for the next 10 years if you're successful.
[00:10:41]
It is really hard to rewrite and evolve a platform once you've got customers on it.
[00:10:45]
You had better pick things that are going to serve you well.
[00:10:50]
Often that means choosing things at the border of cutting edge because if you're not choosing
[00:10:54]
cutting edge now, then you're going to be real behind the times in a decade from now.
[00:10:59]
That's painful.
[00:11:00]
That's one reason.
[00:11:01]
Leverage, you're going to be stuck with it for a long time.
[00:11:04]
The second one is, and I can't understate this enough, the smartest people want to work
[00:11:10]
with the best technology.
[00:11:12]
If you're not making a few aggressive technical bets early in your company's lifecycle, you
[00:11:18]
actually are missing out on a very strong recruiting angle because you will find folks
[00:11:23]
who are keeping up with the cutting edge, who are attracted to those kind of opportunities,
[00:11:28]
and you don't have the money to pay big company salaries.
[00:11:32]
You're a startup.
[00:11:33]
You got to make it a real awesome mission with great people and great technology to
[00:11:38]
attract the best folks.
[00:11:40]
The three big technical bets that I made when we started were Lambda, GraphQL, and Elm.
[00:11:49]
I can give you the logic on each of them.
[00:11:51]
It's real straightforward.
[00:11:53]
Elm was probably actually the riskiest and yet most obvious one to me, which is if we
[00:12:00]
have a human usable standard ML derivative or household cousin, but that mere mortals
[00:12:09]
can wield.
[00:12:10]
I have seen all the errors that happen on the front ends.
[00:12:15]
That has plagued my career with complexity and pain.
[00:12:19]
In fact, I even wrote an app that would later get acquired by Crashlytics, which got acquired
[00:12:23]
by Twitter, that helped people track JavaScript errors in their front end browser.
[00:12:27]
I'm intimately familiar by how much people on there and all the pressures to build more
[00:12:32]
and more sophisticated apps.
[00:12:34]
To be able to stand on a language that provides iron infrastructure and not mud was huge.
[00:12:41]
It didn't seem like conceptually it was the right choice.
[00:12:44]
The question was, are there enough libraries?
[00:12:46]
Are there enough skilled people?
[00:12:48]
I knew there were ports and things like that or Elm native back at the time because this
[00:12:52]
was 0.17, I think, when we got started.
[00:12:55]
It wasn't quite resolved yet, but I just knew that front ends are brittle, error prone,
[00:13:02]
and I was also going to be a one man shop early on.
[00:13:05]
That was a bet that made just a ton of sense to me.
[00:13:08]
That was the initial stack choice or was that a migration at some point from...
[00:13:13]
No, that was the very initial stack choice.
[00:13:15]
Start with Elm.
[00:13:16]
Cool.
[00:13:17]
Yeah.
[00:13:18]
Then just to round it out a little bit, GraphQL, because I've done a lot of API work over the
[00:13:21]
years, I got started with SOAP and WSDL and XSD and then went to the other end with REST
[00:13:26]
and JSON.
[00:13:28]
GraphQL similarly gives you iron infrastructure to stand on through a schema and the ability
[00:13:34]
to rapidly consume different types of payloads.
[00:13:39]
That was huge for me in terms of getting leverage both for myself and not having to create bespoke
[00:13:43]
endpoints for a team every time.
[00:13:46]
Then lastly, serverless Lambda, that was clearly the future to me in that when you get started
[00:13:51]
programming, you write one file programs.
[00:13:55]
Then at some point you're managing clusters of Docker containers and whatever, and it's
[00:14:00]
like, how did I get here?
[00:14:01]
Right.
[00:14:02]
I actually think that the future is heading to a world where the cloud carves up your
[00:14:05]
single file program for you into the infrastructure.
[00:14:09]
Serverless is that first step on that path back.
[00:14:12]
There are more aggressive things like Unison Web and things like that, but Lambda just
[00:14:16]
seemed obvious.
[00:14:17]
For what we were doing, parsing a ton of data really quickly, it was incredible because
[00:14:20]
I could burn down an entire organization's data in 60 seconds and show it to the user
[00:14:24]
streaming through their Elm browser over plain Wi Fi before Starlink and people's minds would
[00:14:29]
be blown.
[00:14:30]
The tech stack was super facile early on.
[00:14:33]
It was a huge joy.
[00:14:35]
Each portion of that was a gamble, but it was also chosen for 10 year applicability
[00:14:40]
and the ability to attract world class talent.
[00:14:43]
Fascinating.
[00:14:44]
Yeah, I love that idea that you have to pick something that is not at the tail end of its
[00:14:51]
prime.
[00:14:52]
You're really sort of peeking into the future a little bit as you make these decisions.
[00:14:56]
I'm also curious to hear more about what did that...
[00:15:00]
You said it was both the most obvious choice and the most uncertain one to pick Elm.
[00:15:08]
That was because the ecosystem and the...
[00:15:12]
Were there questions about boilerplate and these classic concerns?
[00:15:17]
I'd be really curious to look at what those questions were then and then compare them
[00:15:23]
in hindsight what has the experience been.
[00:15:26]
If you could talk to your past self and reassure your past self that this thing is actually
[00:15:32]
fine or warn your past self about something, I would be really curious what that would
[00:15:37]
look like.
[00:15:38]
Totally.
[00:15:39]
Okay, those are great.
[00:15:41]
Concerns that I had at the time, many of which proved true by the way.
[00:15:44]
It's not like 2017 is different than 2022.
[00:15:51]
One was let's just talk about ecosystem.
[00:15:54]
Are there enough libraries to build the application you want to build?
[00:15:58]
Back then, I would say the answer was not quite.
[00:16:02]
Elm charts wasn't really a thing yet.
[00:16:05]
I don't think that existed actually.
[00:16:08]
How am I going to do charting?
[00:16:10]
That's huge in business apps.
[00:16:11]
It just seems obvious.
[00:16:13]
Things like that, that's probably actually the biggest one for what it's worth.
[00:16:17]
What does the package ecosystem look like?
[00:16:20]
Is there enough?
[00:16:21]
That was a bit of a leap of faith that I thought, well, I'll either find a way around it or
[00:16:26]
it'll solve itself over time.
[00:16:28]
I'm not saying that was solid logical reasoning, but that was the leap of faith.
[00:16:35]
That one's really torn between going deeper and enumerating all the challenges.
[00:16:40]
Let me enumerate.
[00:16:42]
That was one.
[00:16:43]
The next one was what are the patterns to architect an Elm app?
[00:16:47]
There just wasn't enough corpus of open source or blog posts or discussions like this.
[00:16:54]
How do you organize it?
[00:16:56]
I knew the Elm update loop was conceptually the right thing.
[00:17:00]
I don't remember where React Redux was around that time, but it was just clear like, oh,
[00:17:05]
this makes sense.
[00:17:06]
I had done some functional reactive programming to build an iOS app in Swift about a year
[00:17:12]
prior.
[00:17:13]
Elm was still flirting with FRP as its foundational metaphor back then.
[00:17:18]
I'm glad it moved away from it because it's equivalent but simpler where we ended up.
[00:17:23]
That was just like, how do I architect this?
[00:17:25]
I don't know the answer to that, but we'll figure it out was my answer.
[00:17:28]
Then lastly, people.
[00:17:30]
How many people out there can code standard ML or Haskell, want to learn this cousin of
[00:17:36]
it, and then write for the front end?
[00:17:39]
If they don't exist, how many people are willing to jump in and learn this on their own?
[00:17:43]
How much of a burden would it be on the existing team who may know that to educate them on
[00:17:48]
that?
[00:17:49]
That was a major risk.
[00:17:50]
They're going back on each of those.
[00:17:52]
I can pause there.
[00:17:53]
I'm sure there are actually more risks that I've glossed over, but those are the three
[00:17:56]
that stuck out to me at the time.
[00:18:00]
The first one turned out to be such a nonissue ultimately that I'm so, so happy.
[00:18:06]
However, I still don't think it's widely publicized.
[00:18:09]
I feel like I've done the Elm community a disservice by not piping up and sharing what
[00:18:14]
we've done.
[00:18:15]
This is on, what's the library, the package ecosystem?
[00:18:18]
How much coverage truly is there?
[00:18:21]
People beat up Elm all the time unfairly for like, well, the language hasn't changed a
[00:18:24]
version number in a while.
[00:18:25]
The packages are stable.
[00:18:26]
I'm like, that's amazing.
[00:18:27]
Are you kidding me?
[00:18:28]
I have no idea.
[00:18:29]
That's a feature, not a bug in my book.
[00:18:33]
The thing that we would struggle with over the early years was ports were very complicated.
[00:18:40]
Let's say you want to make a little auto complete box, a type of head search that uses say a
[00:18:45]
service like Algolia to do your back indexing.
[00:18:48]
Well, you're going to want that little search box pairing real deep in your nested view
[00:18:52]
hierarchy.
[00:18:54]
To have that coordinate all the way up to the root of your app through ports created
[00:18:59]
such spaghetti code for us.
[00:19:01]
It just meant that every last little widget had to have this thread all the way back to
[00:19:06]
the root of the application and that just sucked.
[00:19:10]
We tried to get around that with Elm Native.
[00:19:12]
This was okay, well, we can use Elm Native to kind of like hand wave past that.
[00:19:17]
For those that don't know what Elm Native is, because I think it's gone the way of the
[00:19:20]
dodo and I'm happy about that.
[00:19:22]
This was you could mix safe Elm code with unsafe JavaScript code and basically just
[00:19:27]
kind of bust through the type safety anywhere you wanted.
[00:19:30]
That defeats the premise of the whole thing in the first place.
[00:19:33]
But I'm glad it existed at the time because there would have been no hope for us.
[00:19:37]
We started using Elm Native for like Elm chart, not Elm charts, to do charts in Elm.
[00:19:41]
We used it to do this Algolia esque thing.
[00:19:43]
Any of these things that would otherwise require massive architectural rewrites of the code
[00:19:48]
base to thread the needle on these variables, we would use Elm Native.
[00:19:52]
But actually very quickly became our number one slash only source of production issues
[00:19:59]
was the fact that if something went wrong in that JavaScript, the whole Elm app froze
[00:20:03]
and took down the entire experience and there was no way around it.
[00:20:07]
That was a nightmare, right?
[00:20:08]
That's like the whole point of this is to prevent yourself from doing that.
[00:20:11]
I don't remember who pioneered it, but when we found out how to use web components instead,
[00:20:18]
that was the aha moment.
[00:20:20]
If I could go back in time and tell my former self, look for this word web components and
[00:20:25]
when you see it, jump on it like your life depends on it, I would.
[00:20:30]
That simplified things so much and now we have the best of both worlds.
[00:20:34]
You cannot break our Elm app.
[00:20:36]
It's rock solid.
[00:20:37]
It's bonkers how good it is.
[00:20:38]
No one ever believes us.
[00:20:40]
It's true.
[00:20:41]
The rumors are true.
[00:20:43]
And yet if we need to get some cool calendar widget that we didn't build, we can just web
[00:20:47]
component to it and it all works out really well.
[00:20:49]
So that was huge.
[00:20:50]
That was unsolved.
[00:20:52]
We bled a lot trying to solve it ourselves and then when we saw that technique, it just
[00:20:57]
the skies parted, the clouds parted revealing the sunny sky and everything was great.
[00:21:02]
Thank God for that.
[00:21:03]
And I don't, did you guys remember who came up with that technique first?
[00:21:06]
Well, Luke Westby gave a really great talk at Elm Europe where he did a great job breaking
[00:21:12]
down an example of that and showing how he used an Ellie for the syntax highlighted editor.
[00:21:18]
I think Richard Feldman gave like a meetup talk early on showing how to use that with
[00:21:23]
Google Maps and so he might've sort of paved the path on that a little bit, but yeah, it's,
[00:21:29]
it is such a match made in heaven.
[00:21:30]
It's such an underused thing.
[00:21:31]
So it's really interesting to hear about your experience with that.
[00:21:34]
Like is that a core like leg of, of how you guys use Elm would you say?
[00:21:40]
Absolutely.
[00:21:41]
Yeah.
[00:21:42]
So massive props to Luke and Richard for that.
[00:21:43]
Thank you.
[00:21:44]
I owe you our company.
[00:21:47]
It is a massive leg because you know, now with a straight face, I can, when people,
[00:21:52]
you know, even now we hire people in, in engineering product design, whatever, they're like, Oh,
[00:21:56]
can Elm scale?
[00:21:57]
Can we do everything we need to do?
[00:21:58]
You know, they haven't built up the experience with it yet.
[00:22:02]
And I can say with a straight face, any web component, any component you see on the web
[00:22:05]
that we ever want to use, we can drop it in.
[00:22:07]
You want to embed a React app inside of our app?
[00:22:09]
No problem.
[00:22:10]
You want to embed our app and react?
[00:22:11]
No problem.
[00:22:12]
All of it is on the table.
[00:22:13]
I have no reservations.
[00:22:16]
So you know, withhold judgment on this and let's see how we go.
[00:22:19]
And you know, that's just very reassuring to be able to explain with a straight face
[00:22:23]
and then also to show people in the app, you know, Hey, this complicated thing, we didn't
[00:22:27]
have to build it.
[00:22:28]
We could leverage the best of the JavaScript ecosystem and yet do so in a way that makes
[00:22:31]
everything still kind of fit the bounds of safety and ease of use.
[00:22:35]
So yeah, that's huge.
[00:22:36]
I, we struggled a long time with that one.
[00:22:40]
And then that actually bridges to point number two, which is like, how do you architect a
[00:22:44]
big Elm app?
[00:22:45]
You know, this was before Elm SBA example.
[00:22:49]
Yes.
[00:22:50]
Yep.
[00:22:51]
Exactly.
[00:22:52]
Exactly.
[00:22:53]
And you know, props to Ryan Haskell Glatz for that and you know, a bunch of discussions
[00:22:57]
and he's on the team and does amazing work and we've learned a ton from him.
[00:23:01]
I think Jeroen was talking about Richard Elm SBA example, and then you're talking about
[00:23:05]
Elm SBA, which is also awesome.
[00:23:08]
And then there's, I don't remember what Ryan ended up calling it.
[00:23:11]
I think he was tempted to call it Elm SBA example example.
[00:23:15]
The repo where he converted that over.
[00:23:18]
But anyway, yeah.
[00:23:19]
Well, he is hilarious.
[00:23:20]
So that would not surprise me.
[00:23:22]
Yeah.
[00:23:23]
So, so sorry, thank you.
[00:23:25]
Yeah.
[00:23:26]
Well, so when we got started, we were just inventing things left and right.
[00:23:28]
You know, what's a, how do you write reusable bits of this or that?
[00:23:33]
And I think the big thing that we struggled with actually more than anything else was
[00:23:37]
this pressure from habit to create reusable components that published their interfaces
[00:23:45]
of the messages that they could handle and send out.
[00:23:48]
And so you'd have a lot of components embedded in views and you know, their respective model
[00:23:54]
update loops that you had to negotiate all this translation between the parent, you know,
[00:24:02]
message domain scape and the components.
[00:24:05]
And that was such a nightmare of boilerplate and dysfunction and just pain.
[00:24:12]
Nobody ever wanted to add a feature.
[00:24:13]
Nobody wanted to add a component because suddenly you had to just write like all of these different
[00:24:17]
translator message, translator things all over the place.
[00:24:21]
You're talking about for like adding a new page to the app that works.
[00:24:25]
Not just new pages.
[00:24:26]
I mean, I'm actually trying to remember there was a name for this technique.
[00:24:29]
Again, we're really, you know, delving into ancient history here a little bit.
[00:24:33]
Thanks for adding new pages, but let's say you want to make like a reusable dropdown
[00:24:36]
component.
[00:24:38]
We would, you know, rather than just sort of isolate the view logic for that and say
[00:24:42]
that's the component, we would try to do the whole model update loop.
[00:24:45]
So each component would have its own model and its own update.
[00:24:48]
And it wasn't like types.
[00:24:50]
They were like little mini T apps.
[00:24:51]
Yeah.
[00:24:52]
Okay.
[00:24:53]
You would be adding these mini, you know, the Elm architecture T apps within the context
[00:24:57]
of the larger one and thus forced to write all of these message translators.
[00:25:01]
And I could go find some of this old code someone published.
[00:25:04]
I mean, in fairness to them, it turned out to be the wrong technique, but a really helpful
[00:25:08]
tutorial on how to do this.
[00:25:11]
But it costs so many scalability issues for us.
[00:25:13]
We had no idea how to organize it.
[00:25:15]
So when we saw the Elm single page app example, that, you know, that was like, oh, I see.
[00:25:22]
We had our heads on backwards.
[00:25:24]
We were stuck in like, I don't call it react mentality because I've never coded react,
[00:25:28]
but that kind of like classic stateful OO component world, you know, we're just overly
[00:25:33]
fixated on that methodology.
[00:25:35]
And so our eyes started opening up and there were no watershed moments.
[00:25:40]
I mean, that was helpful.
[00:25:41]
What is a watershed moment?
[00:25:43]
Like a, like an eye opening, like an epiphany, these kind of like, you know, web components
[00:25:47]
were, it was a watershed realization for us, right?
[00:25:50]
Like, oh, that's, that's how you do that.
[00:25:53]
With the way we've architected our app over the years, it's lots of careful refinement
[00:25:58]
based on what we were trying to do that wasn't working.
[00:26:01]
And I feel like that might've been true of the entire Elm ecosystem.
[00:26:04]
We're all kind of trying to figure it out to a degree.
[00:26:06]
Maybe some people knew it, it just wasn't published, which is why I feel bad if we don't
[00:26:11]
publish our stuff.
[00:26:12]
But I feel like we got there and now I can point at our app and I can go point to example
[00:26:17]
repos on the web and say, yeah, that's the way to do it.
[00:26:20]
And it's, it's, it's good.
[00:26:21]
And if you feel the need to deviate, you know, just pay a little bit more attention because
[00:26:26]
you may deviate into somewhere quite painful like we did historically.
[00:26:30]
But there was no like a single aha moment.
[00:26:32]
That was like a bunch of accumulated learnings over the last, you know, five, six years that
[00:26:36]
helped us kind of see the light on, on how to pull it all together.
[00:26:40]
And now we're in a great spot.
[00:26:41]
You know, now we've got generators, code generators that will spit out fresh pages and, you know,
[00:26:47]
do things with queries and like, there's so much automation around our correct pattern
[00:26:51]
that a it's, you know, there's no boilerplate, you know, to be found at least in terms of
[00:26:56]
day to day authoring of code and be the patterns are no one's complained about the patterns
[00:27:02]
in like years, which is great.
[00:27:04]
It means that they're correct.
[00:27:05]
You know, they're not, they're not, there's no impedance to this match.
[00:27:08]
There's no cognitive, you know roadblocks.
[00:27:11]
There's no kind of functional shortcomings.
[00:27:14]
They just kind of work.
[00:27:15]
And so nobody even thinks about it.
[00:27:17]
But I remember how painful that was trying to figure out how to like organize our app.
[00:27:20]
So it is possible to write bad Elm code or at least it was possible.
[00:27:24]
Like that's, oh, it's still possible.
[00:27:28]
It's still possible.
[00:27:29]
I think if any, if you tried to write a self contained Elm component with that model, you
[00:27:33]
know, update.
[00:27:34]
Yeah.
[00:27:35]
I think that's called the actor framework or that that's at least one name that I've
[00:27:40]
seen or taco.
[00:27:41]
I think taco, we actually have a taco.
[00:27:44]
So no, I don't think taco is just like the single well for us it's the single like session
[00:27:49]
context that just threads through everything.
[00:27:51]
But yeah, I think it was the, maybe it's the actor model message translator.
[00:27:55]
If anybody's seen that, Google that message translator, like avoid that, you know, go
[00:27:59]
look at it and then don't do it.
[00:28:01]
Basically like the mini T mini Elm architecture for componentizing local state.
[00:28:06]
So that was, that was a pain point.
[00:28:08]
You guys thought that it was, and you were trying to like automate it.
[00:28:12]
It sounds like, and we weren't trying to automate that one.
[00:28:15]
We were just living with it.
[00:28:17]
You know, again, in the sort of every component should hold its state mentality.
[00:28:21]
That's the, that was the bad head space that we got into.
[00:28:24]
Right.
[00:28:25]
The other thing that was actually really helpful was Evan's, Lucky's table library that he
[00:28:30]
published.
[00:28:31]
Yeah.
[00:28:32]
Sortable table.
[00:28:33]
Elm sortable table.
[00:28:34]
Yeah, exactly.
[00:28:35]
That was a really great example of the evolution of complexity in terms of how to evolve up
[00:28:40]
a more complicated component and yet have it fit in seamlessly.
[00:28:43]
That one was extremely helpful to kind of clarify my own understanding as we were learning
[00:28:48]
over the years.
[00:28:49]
That's really interesting.
[00:28:51]
So, so you mentioned code generation and this is one of the things I've been most interested
[00:28:56]
to hear your thoughts on because I hear a lot about the, the code gen stuff that you
[00:29:02]
guys are doing at vendor.
[00:29:04]
Matt Griffith, we just released an episode about Elm code gen and which is a super cool
[00:29:10]
tool which I hear you guys are using a lot internally.
[00:29:13]
So like tell us about that.
[00:29:15]
Tell us about how that has been like part of your success using Elm and what pain points
[00:29:20]
it's alleviated and like, what are your, like, what are you using code gen for?
[00:29:25]
Oh, great.
[00:29:26]
Okay.
[00:29:27]
Well, now I want to back up and talk about why Scala is a failure to tell you why I love
[00:29:31]
code gen and that's, yeah, don't seem connected, but they are.
[00:29:35]
Okay.
[00:29:36]
We got, we got, we got time.
[00:29:37]
You can indulge.
[00:29:38]
Yeah.
[00:29:39]
Good.
[00:29:40]
I mentioned earlier that I like to choose something technically ambitious, both for
[00:29:43]
the future and to hire great talent.
[00:29:45]
In the ed tech company we did in 2010, again with my stick, you know, functional programming
[00:29:50]
with type systems is the, should be the norm, but it's going to be the future kind of disposition.
[00:29:56]
I chose Scala to write our, you know, our first ed tech startup.
[00:30:02]
And we raised a bunch of venture money and we did a ton of stuff.
[00:30:04]
So it wasn't like a kind of a fly by night thing, you know, we have like 15 million in
[00:30:08]
financing and team of 50 and you know, thousands of students were using us.
[00:30:12]
The problem with Scala, well, the reason I chose it was, you know, functional type system,
[00:30:17]
ecosystem of Java is available to you.
[00:30:20]
Seems like a winner.
[00:30:21]
However, the problem was twofold.
[00:30:23]
One, it attracted philosopher kings and queens to interview with us.
[00:30:28]
These are folks that like want to type about or talk about how monads relate to a billion
[00:30:35]
group.
[00:30:36]
I studied all this stuff and I can't even make fun of it properly, but like they will,
[00:30:40]
you know, there was a large group of people that wanted to geek out on PhD level type
[00:30:44]
system concepts.
[00:30:45]
Not to say that those two are, but like they wanted to geek out on PhD level type system,
[00:30:50]
you know, subject matter versus building an application.
[00:30:54]
So that was failure mode number one.
[00:30:56]
The failure mode number two was Scala is like a kitchen sink programming language.
[00:30:59]
Oh, sorry.
[00:31:00]
Yes.
[00:31:01]
So you attracted smart programmers, but two smart programmers.
[00:31:04]
I wouldn't call them programmers.
[00:31:06]
I attracted smart type system philosophers.
[00:31:08]
All right.
[00:31:09]
That's different.
[00:31:10]
They're mathematicians by nature, right?
[00:31:12]
They're logicians, you know, they're not app builders.
[00:31:16]
It's a fine line.
[00:31:17]
I would tell anybody, if you're exploring one of these like esoteric, you know, academic
[00:31:20]
languages to be careful because you really need to be on the lookout for that.
[00:31:24]
In fairness to those folks, they just wanted to do the thing they loved.
[00:31:28]
It's just that sort of incompatible with building an app for humans.
[00:31:31]
Yeah.
[00:31:32]
But now in vendor, you have a lot of tool builders.
[00:31:35]
You have Ryan with MSPA, you have Matthew with Elm Cogent and Elm UI and even more I'm
[00:31:42]
sure.
[00:31:43]
Beyond that, there's a bunch of other cool stuff that I'm excited to evangelize around.
[00:31:47]
So you just tapped into something, Jeroen, that was like very important life lesson for
[00:31:52]
me.
[00:31:53]
Hire people who have shipped product, preferably folks who have shipped it fully on their own.
[00:31:58]
If you've shipped a little app or a little open source library, I'm your number one fan
[00:32:02]
because it's really hard to build something from nothing and put it into the world because
[00:32:05]
nothing ever feels done, nothing ever feels good enough.
[00:32:08]
But that's a big deal to me.
[00:32:10]
So like our hiring process starts by trying to find those folks first, right?
[00:32:16]
People who shipped.
[00:32:17]
Yeah.
[00:32:18]
So we were attracting people that didn't ship and that was fatal.
[00:32:22]
That feels a bit weird to me because I feel like the more I am in this industry, the more
[00:32:27]
I feel like a tooling author and not someone who builds applications, which I probably
[00:32:31]
shouldn't tell to someone who I could probably...
[00:32:35]
But you're shipping tools.
[00:32:36]
Those are apps.
[00:32:37]
Yeah.
[00:32:38]
But I will still get hired to build products, which will not be tools.
[00:32:43]
So like my expertise will be in things that will not be in the direct interest of the
[00:32:49]
company.
[00:32:50]
I think you're being maybe a little bit too critical, but so I can come back.
[00:32:54]
I am very critical of myself.
[00:32:55]
We can do a therapy session on that one.
[00:32:58]
The important part to me is not, are you shipping an app that consumers use?
[00:33:03]
It's just, are you shipping something self contained that provides value to someone else?
[00:33:07]
Library account.
[00:33:08]
Yeah.
[00:33:09]
Library account deeply.
[00:33:10]
And if you're leveraging automation for things that help you build apps, right?
[00:33:16]
That's all the more so.
[00:33:17]
Like there's something that I've been really inspired by the whole Toyota production system
[00:33:23]
stuff, how Toyota introspects and adapts their processes and stuff, the whole lean stuff.
[00:33:30]
And there's a quote I heard once that Toyota is not a car manufacturing company.
[00:33:36]
It's a car manufacturing improvement company.
[00:33:39]
They're in the business of improving cars.
[00:33:41]
And as a result, they happen to have this side effect of producing quality vehicles,
[00:33:48]
but like they're in the business of improving the process of manufacturing vehicles.
[00:33:52]
So I feel like that's what tooling authors do too, right?
[00:33:55]
They're in the business of improving app development, even though it's not directly app development,
[00:34:01]
it has a helpful side effect of helping you produce great apps.
[00:34:05]
Yeah.
[00:34:06]
Do you still keep hearing the opposite?
[00:34:08]
At least at my company where we say, well, we are not tool builders, we're an application.
[00:34:13]
We're building an application and we do that by building tools for ourselves, but we should
[00:34:19]
not lose track of what is really important.
[00:34:22]
I think keeping your eye on the prize is correct, but again, just to, before we get to our therapy
[00:34:26]
session a little bit later, if you ship things of value into the world and you've gone through
[00:34:32]
that pain of birthing something and putting yourself out there, high five, you're above
[00:34:36]
95 plus percent of folks that otherwise can't do it fully on their own.
[00:34:42]
They can't do the zero to one thing, taking something from an idea to into the hands of
[00:34:46]
users.
[00:34:47]
That's huge.
[00:34:48]
Nobody can see me, I'm high fiving right now.
[00:34:53]
You're my people, I love it.
[00:34:56]
Back to my long winded, long winding thing back to CodeGen.
[00:35:00]
We were accidentally hiring philosopher kings and queens, big issue.
[00:35:04]
The second big issue was people, Scala has so much flexibility with the language, so
[00:35:09]
many deep powers and weird arcane invocations you can make that people would bike shed on
[00:35:16]
the simplest things because there were 25 different ways to do it.
[00:35:21]
Huge problem.
[00:35:23]
That was like, oh man, what have I done?
[00:35:25]
To wit, that company eventually pivoted straight into Ruby on Rails.
[00:35:29]
That was a failed technical choice on my part, which I'm proud to say I learned a lot and
[00:35:34]
avoided since then.
[00:35:36]
Can we go back to one thing that you mentioned at the beginning is like you bet on Elm because
[00:35:41]
you wanted to make cutting edge choices.
[00:35:46]
What would you have said if choosing Elm was a wrong decision?
[00:35:50]
If two years down the line, no one was using Elm anymore and everyone went pure script
[00:35:55]
or something else?
[00:35:56]
I'm guessing that's...
[00:35:57]
I think if it weren't serving us as a company, we would have moved off of it.
[00:36:00]
I have definitely moved off of technology that does not work for us.
[00:36:03]
We didn't get into the Lambda backend, but it didn't start as TypeScript, it didn't exist
[00:36:06]
back then.
[00:36:07]
We started as plain old JavaScript and then we layered in flow type and then we did a
[00:36:11]
painful migration over to TypeScript.
[00:36:13]
We will do the heavy lifting to evolve when we need to.
[00:36:18]
I am not afraid to say I screwed up, this was wrong.
[00:36:20]
I'm glad I took the bet.
[00:36:21]
The bet didn't turn out the way I might have hoped, but I learned a lot.
[00:36:28]
Scala, too many different ways to say the same thing cause a lot of lack of traction
[00:36:33]
where people are like, well, should we use this dot operator?
[00:36:37]
Should we do this functional chain thing?
[00:36:39]
Should this be a functor?
[00:36:40]
Should this be just a regular library?
[00:36:42]
Should it be a class?
[00:36:43]
God only knows.
[00:36:45]
One of the things with Elm that was so surprising was it removed a ton of deep power.
[00:36:51]
I think if you show up from Haskell and Elm, you're like, why can't I create functions
[00:36:56]
that produce libraries and all this sort of like my higher kind at XYZ?
[00:37:01]
You don't have all that.
[00:37:02]
It's very straightforward.
[00:37:03]
Elm code is so straightforward in terms of what it's capable of doing.
[00:37:06]
The downside is you might have to write a lot of boilerplate, but that's where CodeGen
[00:37:12]
comes in.
[00:37:13]
Who cares?
[00:37:14]
Who cares?
[00:37:15]
What you're looking for is a simple language that kind of makes the easy things easy and
[00:37:22]
the hard things clear.
[00:37:24]
Not necessarily short, but clear.
[00:37:25]
Clarity matters more.
[00:37:27]
We just leaned into CodeGen left and right, not just for like, hey, here's how we do a
[00:37:32]
page, but oh, do you have to generate some complicated encoder decoder?
[00:37:36]
Well, we can write a library that can spit out that code and you're never going to modify
[00:37:41]
that code by hand.
[00:37:42]
You can modify the upstream source code.
[00:37:44]
But the beauty is rather than complicate the language, you've kind of pushed it upstream
[00:37:49]
into your build process and on balance that works so well.
[00:37:53]
It works so, so well that we use CodeGen all over the place in the front end.
[00:37:58]
We use it all over the place in the back end.
[00:37:59]
And I prefer it to advanced language features because then you start getting into this hellscape
[00:38:03]
of, hey, I'm trying to instantiate a value of this type, but I barely even understand
[00:38:08]
what the type signature is, let alone what to do with it.
[00:38:12]
It just makes things really hard.
[00:38:14]
So one testament, I think, to Elm's simplicity here is we hire people that have never touched
[00:38:21]
Elm, never touched a language like Elm, have never done stateless programming, where it's
[00:38:25]
kind of all purely functional.
[00:38:27]
And they're like, I don't think I can do this.
[00:38:29]
I'm like, no, no, no, give it a try.
[00:38:31]
And then they go through it and then we haven't even talked about how good the compiler is
[00:38:34]
yet, but there's only so much the language can do.
[00:38:36]
It doesn't actually take that long to learn the basic things available to you.
[00:38:41]
The conceptualization might be hard, but the tool itself, it's just like, you got some
[00:38:46]
lets, you got some functions, you got function application, you got your data type definitions,
[00:38:51]
and you're off to the races.
[00:38:54]
It's fairly simple.
[00:38:55]
And that's not the case with Scala.
[00:38:57]
And so the trade off is, well, you might have a lot of boilerplate, but good news, if you
[00:39:00]
can express it in a higher order way, you can use CodeGen to bridge that gap.
[00:39:05]
And so back to the pain of Scala, this simplifies the language and gets me out of that mire.
[00:39:14]
And I mentioned the third thing was, the third risk was, could we hire people that can learn
[00:39:18]
Elm?
[00:39:19]
I have not run into philosopher kings and queens in Elm land.
[00:39:21]
I have run into application builders, tool builders, people who like shipping things
[00:39:27]
and appreciate the relative simplicity, because they're not here to geek out on isomorphism
[00:39:32]
XYZ, they're here to build things.
[00:39:35]
And so it's just struck such a hard to explain, but powerful balance for us.
[00:39:41]
How long does it take for you to, how long does it take for a new hire who doesn't know
[00:39:45]
Elm at all to be somewhat productive in your opinion, or in your experience?
[00:39:49]
That's a good question.
[00:39:50]
I have two schools of thought on that.
[00:39:52]
Three, two and a half.
[00:39:55]
One benefit of building in Elm is that there's so many people who are interested in doing
[00:39:58]
Elm full time, we have not had trouble hiring folks that want to do Elm and already know
[00:40:04]
it, which isn't to say that if you don't know Elm, we're not willing to teach you, we are.
[00:40:08]
But how lucky are we that there's so many smart builders out there who already know
[00:40:13]
this who would love to do it full time?
[00:40:16]
That's awesome.
[00:40:17]
That's a real strong selling point for us in terms of our front end.
[00:40:19]
So you kind of have the same hiring strategy as NoGrading.
[00:40:23]
You just say, we're using Elm and people flock.
[00:40:28]
They could flock more.
[00:40:29]
Hey folks who want to flock, listen in, we're hiring.
[00:40:33]
We are, we are hiring.
[00:40:35]
Yeah, it hasn't been a problem.
[00:40:38]
I can be in different Elm communities and see people doing cool stuff and reach out
[00:40:42]
and say, that's freaking awesome.
[00:40:44]
By the way, we're hiring or hey, we use that thing you did.
[00:40:47]
Thank you so much.
[00:40:48]
Oh, how are you using it?
[00:40:49]
Well, I have a team of 50 plus engineers.
[00:40:51]
Here's how it's all going down.
[00:40:52]
They're like, oh wow, can I talk to you?
[00:40:55]
Like, yeah, please.
[00:40:56]
That'd be great.
[00:40:57]
So it's a strong hiring advantage for sure.
[00:41:00]
Now, the world of Elm programmers is still relatively small compared to everything else.
[00:41:05]
So if there were 20 of us out there doing this, well, maybe it would start to get a
[00:41:10]
little bit more competitive.
[00:41:11]
That might just drive more people to learn Elm.
[00:41:13]
I don't know, but so far so good.
[00:41:14]
And in terms of teaching people, here we used to hire folks and teach them very one on one,
[00:41:22]
but we're growing so fast right now as a company that there's not a lot of time to invest in
[00:41:28]
kind of that hands on mentorship that I love so much.
[00:41:31]
And we do, I do as much as I can and the team tries to do it, but like it's just challenging.
[00:41:37]
The rate that we're growing is just such an insane pace that things are breaking everywhere.
[00:41:42]
You know, you got to really be careful with your time.
[00:41:44]
What's amazing about it is we, I let folks know that when you join vendor, we're going
[00:41:49]
to be hiring you either primarily for your backend skills, even if you're a full stack
[00:41:54]
developer or for your pure Elm front end skills, but you are welcome to cut through the stack,
[00:42:01]
however you like to get the job done.
[00:42:03]
So we'll have, you know, folks that ostensibly were hired to be a backend engineer who were
[00:42:07]
like, well, I want to make this feature real and there's no one else available in this
[00:42:10]
moment to help me with it.
[00:42:11]
Let me cut my teeth on it.
[00:42:13]
And there's a lot of nervousness followed by, I just kind of said what I wanted to have
[00:42:18]
happen and the compiler took care of the rest.
[00:42:22]
You know, I can point to like, you know, dozens of Slack messages that kind of back that point
[00:42:26]
up.
[00:42:27]
So I think there it's just, we take a learn by doing approach because it's hard to go
[00:42:32]
wrong, right?
[00:42:34]
I wouldn't do that same approach to the backend.
[00:42:35]
It's way too easy to, you know, create a security risk or to, you know, conflate customer data
[00:42:41]
if you do your SQL statements wrong or, you know, otherwise cause an error and blow stuff
[00:42:46]
up.
[00:42:47]
You know, on the Elm side, I think the worst outcome is you might have code that someone
[00:42:50]
else could have cleaned up a little bit better later.
[00:42:53]
And that's a real low risk.
[00:42:55]
You know, it's like if it falls in a forest kind of situation, like it's not that big
[00:42:59]
of a deal in practice.
[00:43:01]
So we've had, you know, fingers crossed, we've had really good luck with folks that felt
[00:43:05]
adventurous enough to come up the stack and try it out and kind of happy with what they
[00:43:10]
produced.
[00:43:11]
You know, we might quibble on the style of parts of it, but it's in the realm of quibbling.
[00:43:16]
It's not like, oh, you architecturally dorked this thing up.
[00:43:19]
That would be really hard to do.
[00:43:21]
Before we get too far away from it, I wanted to dive in to a little more detail on some
[00:43:25]
of the code generation things, if I could.
[00:43:28]
Like I think that a lot of people would find this interesting because I personally think
[00:43:35]
that code generation is probably underutilized.
[00:43:38]
And I think it's kind of an emerging space that people are really starting to explore
[00:43:42]
now in public at least.
[00:43:44]
So I'd be really curious how you guys have leveraged that internally and like, so what
[00:43:50]
do you use Cogen for?
[00:43:52]
So you use it for like, I believe you guys have either LMSPA or a similar tool.
[00:44:00]
What else?
[00:44:01]
And I don't want to steal any thunder from folks that have maybe not released things
[00:44:06]
that I could talk about.
[00:44:07]
Yes, I know.
[00:44:08]
I've got that on my mind too.
[00:44:10]
But to be fair, we do have an episode scheduled with the particular person I believe you're
[00:44:15]
talking about.
[00:44:16]
Okay, so I won't spill any beans then.
[00:44:17]
That's great.
[00:44:18]
We'll get into it and you can edit the section out if I've run afoul.
[00:44:21]
So we definitely use LMSPA ask Cogen for one, which is...
[00:44:30]
Now we existed before that did.
[00:44:32]
So we invented this on our own and we weren't using Matt's library because it wasn't out
[00:44:37]
yet, LmCogen.
[00:44:39]
So we used a tool called Plop.
[00:44:41]
If anybody's seen that, P L O P. Very simple handlebar templating tool set.
[00:44:47]
But what's great is, I shared how we struggled with architectural patterns, but we finally
[00:44:51]
figured out what those patterns are.
[00:44:53]
And so now when a developer wants to create a new page, you go yarn Plop new page and
[00:45:00]
it has created the routes to handle URL routing, the T model update view loop, all the scaffolding
[00:45:09]
code.
[00:45:10]
It will then launch your browser straight into that page and you'll see a hello world
[00:45:13]
right there.
[00:45:14]
So it is trivial for us to set up a new page in exactly the right way we want, complete
[00:45:18]
with analytics, everything, which is awesome.
[00:45:22]
We have a couple of fun internal phrases and I don't know if people are fans of the matrix,
[00:45:28]
but agent Smith taught me an important lesson, which is never send a human to do a machine's
[00:45:32]
job.
[00:45:34]
Writing boilerplate code is a machine's job.
[00:45:36]
So we put the boilerplate into this templating library and it spits it out and you don't
[00:45:40]
have to think about it and it just, it's up and running and you've got that kind of like
[00:45:44]
tight loop of thought and creation and seeing it live.
[00:45:47]
So that is freaking awesome.
[00:45:49]
So that's a big one.
[00:45:50]
The other big one, here I'll pause in case we need to edit it out.
[00:45:53]
The other big one is what we're doing with GraphQL now.
[00:45:57]
I mentioned that GraphQL was one of our earliest bets.
[00:45:59]
We're big fans of the interplay between GraphQL and Elm, which Dillon, I know you in particular
[00:46:04]
can appreciate deeply.
[00:46:05]
It is incredible to have a system where when we launch changes to our scheme on the backend,
[00:46:10]
we know a priori if it's going to break the live front end and we also never launched
[00:46:15]
front ends, which are incompatible with the backend.
[00:46:17]
We don't have those kinds of API errors.
[00:46:19]
It's pretty insane.
[00:46:20]
I mean, someone will have a browser that their laptop came out of sleep two months later
[00:46:25]
and it's like a Rip Van week and the world's different and you get a brief set of errors
[00:46:29]
before it auto updates.
[00:46:31]
But in general, it's pretty remarkable.
[00:46:34]
And there's so much room for automation with that because you've got schema published by
[00:46:39]
your GraphQL.
[00:46:40]
So, what we have now is you can specify a GraphQL query, which our backend team will
[00:46:46]
do for you, right?
[00:46:48]
Like, oh, here's the query to generate this kind of information that you'll need.
[00:46:52]
Feel free to modify it and you can use your GraphQL client library like Altair and Somi
[00:46:57]
or Postman where you happen to have to kind of make sure you're getting the right data
[00:47:00]
with your local server.
[00:47:02]
And then you drop that into a folder and it auto generates all the queries, decoder, encoder
[00:47:09]
stuff for those queries.
[00:47:10]
And then on top of that, it will generate this sort of like default set of records to
[00:47:16]
load that data into and then make it available to that page.
[00:47:19]
And so, you don't have to do anything except write in native GraphQL and suddenly you've
[00:47:23]
got a function that returns a well structured object that specifies perfectly the type model
[00:47:28]
for that query in the first place.
[00:47:30]
That is an amazing accelerant for us.
[00:47:33]
I think there were like proto versions of things like this, like JSON encoder and decoder
[00:47:36]
in Elmworld.
[00:47:37]
You give it a sample and it will do this, but a lot more powerful when you've got like
[00:47:40]
a fixed schema to work with.
[00:47:42]
And that gives us the benefit too of, you know, we can just go through our code base
[00:47:45]
and modify or introspect all those files if the API ever changes and make sweeping changes
[00:47:50]
to the application.
[00:47:52]
You also get dead code elimination, you know, really fun stuff.
[00:47:56]
Speaking of, you know, automation like that, we use Elm Review to create a, you know, a
[00:48:01]
Zamboni task every Sunday that goes and finds dead code and, you know, otherwise it juzzes
[00:48:05]
up the code base.
[00:48:06]
So, we lean into that stuff all over the place.
[00:48:09]
But that actually makes me sad, but...
[00:48:10]
It makes you sad, why?
[00:48:12]
Because you only use it once a week.
[00:48:14]
You should run it every time.
[00:48:16]
So, I think you have performance issues.
[00:48:19]
So, maybe let's talk at some point.
[00:48:21]
Yeah, let's talk.
[00:48:22]
Let's talk.
[00:48:23]
I'm not saying we don't run it every time.
[00:48:24]
We at least run it once a week automatically.
[00:48:27]
But anyway, so, you know, that code gen, you know, if you look at the kind of work that
[00:48:33]
we were doing before around anything related to encoding and decoding, it's very time consuming
[00:48:39]
and, you know, at the scale that we're at, right?
[00:48:43]
And I'm trying to walk away with a line here, Dillon, because I've used and loved your library
[00:48:46]
for years.
[00:48:47]
And I like, it was instrumental for me in understanding both GraphQL and Elm.
[00:48:53]
But that said, like, it's one of those things where we're trying to educate new people.
[00:48:58]
There's a lot that happens, and that's probably the most complicated sort of interplay of
[00:49:01]
types where you're translating from one type to the next.
[00:49:04]
So kind of just removing that, except for the cases where it matters, has been wonderful.
[00:49:09]
Where it matters is when you want to do something kind of more complicated, more nuanced.
[00:49:14]
You want to go straight into a particular type.
[00:49:16]
You know, you need to handle errors in certain ways.
[00:49:18]
But for most boilerplate pages, you're just kind of doing like a query and a write back
[00:49:23]
to screen.
[00:49:24]
That makes sense.
[00:49:25]
Or if it's just a mutation where maybe you don't even care about getting some data back
[00:49:29]
and you're just like, send this off.
[00:49:31]
Fire and forget.
[00:49:32]
And then we also use CodeGen for, I believe, Storybook.
[00:49:37]
So we'd like to have our component library available for ourselves, our designers, to
[00:49:43]
see what we have, see what it looks like.
[00:49:45]
We have a Storybook plugin that I don't know if we might have written it.
[00:49:50]
But is it a real Storybook or is it a Storybook like?
[00:49:54]
The real Storybook.
[00:49:55]
Okay.
[00:49:56]
Yeah.
[00:49:57]
So we've got type safe bridging between Elm and Storybook because of code generation.
[00:50:00]
It will generate all the sort of sample stuff for us, including some fuzzing, I think.
[00:50:05]
So like we can, it's actually, it's a lot of fun.
[00:50:07]
We use CodeGen and Lean into Automation for, we have a SaaS directory.
[00:50:13]
So we have this library of like 10,000 SaaS apps plus that we're tracking across the industry.
[00:50:18]
We have a little Elm app that will help us render these little directory pages.
[00:50:23]
And there we use a combination of GraphQL, CodeGen, static rendering to produce all these.
[00:50:28]
So yeah, there's a bunch of use cases for CodeGen.
[00:50:32]
But in general, I think if you're bemoaning the lack of like functors or higher ordered
[00:50:38]
kinds or something, like just let CodeGen pop into your head for a second.
[00:50:42]
You might find like a pragmatic solution for mere mortals.
[00:50:46]
Yeah.
[00:50:47]
I really like something that Matt's been talking about a lot recently.
[00:50:54]
He talked about it on our recent Elm CodeGen episode of instead of this idea that Elm is
[00:51:01]
verbose, like Elm is verbose, but it's sane, it's safe.
[00:51:08]
And he's talking about, well, what if we say because Elm is safe and because Elm is sane,
[00:51:14]
we can use that to make it really convenient, like leveraging that safety to give you convenience.
[00:51:21]
And then you get the best of both worlds.
[00:51:24]
And I'm really hearing a lot of that from what you're describing with the CodeGen workflow.
[00:51:31]
And I think there's like sometimes an extra step that's missing where you mentioned like
[00:51:35]
automatically generating JSON decoders and encoders.
[00:51:39]
I imagine a lot of people are going to websites for automatically getting a JSON encoder or
[00:51:45]
decoder, dropping in some JSON, which they fire off, however, through some REST client
[00:51:52]
or Insomni or something like that.
[00:51:55]
And then they copy paste that into some tool online and then they copy paste the JSON encoders,
[00:52:02]
decoders they get.
[00:52:03]
Yeah.
[00:52:04]
I think there's some automation missing in that process where they're copy pasting JSON,
[00:52:10]
they're pasting it into an online tool, they're copy pasting that generated Elm JSON decoder
[00:52:17]
into a module.
[00:52:18]
And when you take that little bit of glue and maybe you are using some tool to automatically
[00:52:25]
write a file with your JSON decoders and maybe it's automatically wiring it up for you somewhere.
[00:52:32]
The things you're talking about are making me think how much that last mile effect is
[00:52:37]
at play there.
[00:52:39]
And I think there's a real opportunity for people to lean into the CodeGen more there.
[00:52:44]
Yes.
[00:52:45]
Yeah.
[00:52:46]
Sorry.
[00:52:47]
I was like champing to the bit to interject.
[00:52:48]
Yeah.
[00:52:49]
Yeah.
[00:52:50]
No, I love this topic.
[00:52:51]
I think that...
[00:52:52]
You know what I've seen through the Elm community over the years, and I don't mean like the
[00:52:56]
kind of folks that are in it and kind of part of the Elm and Noddy.
[00:52:59]
I'm talking about the new entrance to the world.
[00:53:03]
It's hard for folks to do basic things out of the box.
[00:53:09]
And by basic things, I mean trigger an HTTP API call and decode the response.
[00:53:15]
And we've seen this over and over with beginners, decoding things in a type safe way is just
[00:53:21]
unnatural and challenging for folks that have learned from the Python or JavaScript or those
[00:53:28]
ecosystems that do the automatic object translation.
[00:53:31]
It's like, why do I have to do this?
[00:53:33]
This language sucks.
[00:53:34]
Why is it making me do this?
[00:53:36]
Because they haven't yet fully grok the power of type safety.
[00:53:40]
And they're being asked to serve this new type safe master by doing a bunch of what
[00:53:47]
feels like...
[00:53:48]
I wouldn't call it boilerplate.
[00:53:49]
I'd call it like, but why am I even doing this at all?
[00:53:52]
I don't get it.
[00:53:53]
Just do it for me.
[00:53:54]
And that's really unfortunate because I think anybody trying to build an Elmap of substance
[00:53:58]
is going to call an API call really, really in its life cycle.
[00:54:02]
And they're going to get burned by this conceptual mismatch.
[00:54:05]
But it doesn't have to be that way.
[00:54:08]
We could...
[00:54:09]
I would encourage folks even to ask this frankly in the Elm docs of getting started.
[00:54:15]
You could lead into a world where you take a TypeScript type definition, a swagger definition,
[00:54:20]
or even just a sample blob of JSON and have a tool that spits out a decoder for it that
[00:54:26]
will just work and say, don't worry, this piece may feel like magic.
[00:54:30]
It's not.
[00:54:31]
We're just saving you from writing this stuff by hand.
[00:54:33]
You may want to write it by hand later because parse don't validate is like the coolest concept
[00:54:37]
ever.
[00:54:38]
But just to get you going and make sure that you don't feel like there's any impedance
[00:54:42]
mismatch between I want to build an app and I heard this is a cool way to do it.
[00:54:46]
I find that's true with beginners up until they write their first JSON decoder.
[00:54:49]
And then they're like, screw this thing.
[00:54:51]
This sucks.
[00:54:52]
Why am I doing this?
[00:54:53]
And that's unfortunate because it gets better.
[00:54:56]
It gets so much better.
[00:54:57]
But I feel for folks that run into that.
[00:55:00]
That's a very like, yeah, I don't understand that.
[00:55:03]
And I don't have the context yet to get it.
[00:55:05]
And even if you did have the context, I don't want to spend my time writing decoders.
[00:55:10]
I want to make the app.
[00:55:11]
Right.
[00:55:12]
Yeah.
[00:55:13]
Nobody wants to spend time writing JSON decoders and non coders.
[00:55:17]
But Elm developers have chosen that they don't want to debug a no pointer error in the dark
[00:55:25]
recesses of their application logic because the contract was not what they expected either.
[00:55:30]
And so we've chosen that trade off in the Elm community.
[00:55:34]
But what if you didn't have to make a trade off?
[00:55:35]
What if you could have the convenience?
[00:55:37]
And like Evan has a gist where he describes his Elm interchange vision, I think is the
[00:55:46]
name of the document.
[00:55:47]
Yeah, for data.
[00:55:48]
Yeah.
[00:55:49]
Data interchange or something.
[00:55:52]
Data interchange vision.
[00:55:53]
Yeah.
[00:55:54]
So I think it's really cool to talk about automatic serialization, deserialization tools and languages
[00:55:58]
like Haskell where you can say serialize this type and it infers a JSON decoder essentially
[00:56:04]
for it.
[00:56:05]
And, you know, people can say, well, why don't we just do that in Elm?
[00:56:09]
But the fact is, then you're introducing magic.
[00:56:13]
You're introducing an extra layer of abstraction to understand how the language works.
[00:56:19]
And if something goes wrong, what do you do?
[00:56:22]
Well, now my and now your types are coupled to your logic of, you know, the serialization
[00:56:28]
format and deserialization format, which is a weird coupling that eventually you're going
[00:56:34]
to want to get around somehow.
[00:56:35]
And then you have to build in hacks for that.
[00:56:37]
And so like decoders are great.
[00:56:40]
They're just inconvenient.
[00:56:41]
But what if they were great and convenient?
[00:56:45]
Now there's no problem.
[00:56:46]
Right.
[00:56:47]
So if you go at it from that angle, code generation can like alleviate a lot of things we don't
[00:56:52]
like while giving you the things we like, explicitness, debug ability, traceability,
[00:56:57]
simpler mental model.
[00:56:58]
Violent, violent agreement.
[00:56:59]
Emphatic agreement.
[00:57:00]
Yes.
[00:57:01]
Yes, for sure.
[00:57:02]
And and I'm so fearful of additions to the language that would take it back to what I've
[00:57:09]
seen go wrong.
[00:57:10]
And, you know, Scala and those other sort of air quotes, more powerful systems.
[00:57:14]
We want simple and we want clear.
[00:57:17]
And you know, if you can remove the friction via things like this, that's great.
[00:57:21]
I would love to see a lot more code gen.
[00:57:23]
There's probably some norming we'll have to do as an ecosystem around it.
[00:57:25]
Like do we have, you know, code gen directories or code gen file, you know, dot code gen dot
[00:57:30]
elm, whatever.
[00:57:31]
But some, you know, let's start establishing some of these patterns so that people, when
[00:57:35]
they see code gen don't, you know, run in fear, they know how to operate it and and
[00:57:39]
can benefit from that kind of friction reduction because it's it's it's big.
[00:57:43]
It's great.
[00:57:44]
And it keeps the core language simple.
[00:57:47]
And that's so maybe it's not underrated, so valuable to me at least that that, you know,
[00:57:51]
I wouldn't ever want to pervert that.
[00:57:53]
I'm I'm curious, Aaron, do you have thoughts on you've talked about betting on elm at
[00:58:00]
BlizzFly at vendor and how it panned out has turned out to be it sounds like an important
[00:58:07]
tool in the toolkit for success.
[00:58:09]
Is that something that the types of problems you're solving make it uniquely well suited
[00:58:15]
for?
[00:58:16]
Are there like spaces that it might not be suited for?
[00:58:19]
Do you have any opinions on that?
[00:58:21]
You know, I I'm going to run run the risk of being like, you know, too much of a bombastic
[00:58:27]
fanboy, but I've got the weight of a business behind me that maybe can help cover.
[00:58:34]
Use it, use it, use it.
[00:58:36]
Here's, you know, my fundamental belief, right?
[00:58:39]
Like you should need to make impossible states impossible.
[00:58:41]
Thank you, Richard.
[00:58:42]
We want to stand on steel girders, not, you know, mud foundations.
[00:58:46]
And so, you know, or the more constraints you can build into your, you know, your fundamental
[00:58:52]
tools, the faster you can go.
[00:58:55]
And I'll say in startups, I have a quote, startups, I'm borrowing and modifying injuries
[00:59:01]
in Horowitz here.
[00:59:02]
Startups are eating the world, but startups eat, but software is eating the world, but
[00:59:05]
software eats other software first.
[00:59:07]
And the reason I believe that is because, you know, everything is going to become a
[00:59:10]
software business to some degree.
[00:59:12]
It's really easy to clone software that you've seen out in the wild because someone's done
[00:59:15]
the hard work of finding a business model that software can help with and then kind
[00:59:19]
of encoding the domain and providing the value.
[00:59:22]
And so, you know, speed matters a ton and nothing kills speed like retreading, you know,
[00:59:28]
where you've been historically, right?
[00:59:30]
So if you're always fixing bugs, if you're always kind of slowing down to, you know,
[00:59:35]
do things that a computer could otherwise do for you, you're losing the, you're losing
[00:59:38]
the war, which is determined by speed.
[00:59:41]
And so Elm has given us such incredible speed of development.
[00:59:45]
And it feels weird to say, and I think, you know, the, when folks hear the number of like
[00:59:50]
front end developers to back end developers here that we have, I don't know, call it like
[00:59:55]
a, it's like a one to 10 ratio.
[00:59:57]
Wait, one front end for 10 back end?
[00:59:59]
Yeah, that's about where we're at.
[01:00:01]
Now that seems insane.
[01:00:02]
It seems like what I hear internally is, oh my God, your back end must be really complicated.
[01:00:06]
Well, it's not as simple as I'd like it to be.
[01:00:09]
That's true for everything because, you know, I have, I'm never satisfied and have high,
[01:00:14]
high hopes and dreams for everything.
[01:00:16]
But it's actually because our front end engineers are so freaking productive that they can do
[01:00:21]
so much on their own.
[01:00:24]
I don't need, you know, a lot of pods typically are like 50 50 front end and back end because
[01:00:28]
you're just that hard to write quality front end apps.
[01:00:30]
That's not the case for us.
[01:00:32]
It's actually like we get by with very few folks on the front end, which is amazing.
[01:00:37]
And we've started raising our ambitions.
[01:00:39]
What we're coming out with in, it's an alpha now, you know, being beta soon and GA, you
[01:00:44]
know, before end of year, we have this beautiful, beautiful workflow builder.
[01:00:50]
It's like two products smashed up into one.
[01:00:52]
It's like type form for, you know, designing forms in the fly.
[01:00:55]
We love our types in a type safe way.
[01:00:57]
So all the data, we know the types and from a customer perspective and obviously the infrastructure.
[01:01:02]
So that's part one and then part two is this like drag and drop, you know, pan zoom, re
[01:01:07]
layout reflow diagram build, you know, on par with the best.
[01:01:13]
And it's all built in Elm and it's incredibly fluid and highly animated and running at like
[01:01:18]
60 frames per second.
[01:01:19]
And it's just bonkers.
[01:01:21]
So like on the one hand between code gen for pages, code gen for queries and our graphical
[01:01:26]
API, we could spit out, you know, boring business pages in the app left and right, like nobody's
[01:01:32]
business and maintain them really, really easily because when something would break,
[01:01:36]
we know everywhere it breaks.
[01:01:37]
We don't need like, you know, tests harness everywhere and humans manually traipsing through
[01:01:42]
pages, you know, every bill, there's something terrible like that, which in a lot of companies
[01:01:46]
devolve into.
[01:01:47]
And we get to have these like highly interactive, really satisfying, almost video game quality
[01:01:52]
ask experience in terms of, you know, what it feels like to build the thing is just super
[01:01:56]
fluid.
[01:01:57]
So it's like, yeah, what is Elm good for?
[01:01:59]
I'm like, well, I just, it feels like both right now.
[01:02:01]
You know, like I can spit out business pages and experiments really rapidly.
[01:02:07]
We can build incredible consumer S quality experiences.
[01:02:11]
I feel really great about it, you know, and we do it with very few engineers relative
[01:02:15]
to, I think the normal ratio that other companies have with zero errors in production.
[01:02:19]
Like how could I not be been, you know, bombastic about that?
[01:02:23]
Like it's hard to contain my excitement for where we're at and what it means for us over
[01:02:27]
the next couple of years.
[01:02:28]
Like I'm just thrilled by the setup that we've found.
[01:02:31]
And again, it may not have ended up that way in a different universe, but in this one it's
[01:02:35]
working, you know, amazing.
[01:02:36]
I think I'll let my enthusiasm derail me from answering your original question.
[01:02:42]
So.
[01:02:43]
Oh no, I mean, I think you answered, I was just asking, you know, I mean, to be fair,
[01:02:48]
what other response could I expect?
[01:02:50]
I mean, I was genuinely interested to know if there's something particularly about vendor
[01:02:57]
that makes Elm a good fit or if, you know, I mean, I'm sure there are certain types of
[01:03:02]
use cases, but for, it does seem like building, I don't know, maybe if you just are pulling
[01:03:09]
a bunch of off the shelf libraries and that's all you need and you don't have a lot of business
[01:03:14]
logic, that's like the classic thing that I think about for maybe Elm's not the right
[01:03:18]
fit for that.
[01:03:19]
Yep.
[01:03:20]
You know, it's tough for me to say, I'll tell you what we have not done yet that would be
[01:03:25]
a little bit less clear to me.
[01:03:26]
Like we, well actually a few more things, you know, some people are like, well, server
[01:03:30]
side rendering Elm doesn't do that yet.
[01:03:32]
And in fact there was talk of like 0.20 doing server side rendering, if I recall.
[01:03:37]
Not a problem for us actually, because the only time as a business we care about that
[01:03:41]
is for SEO purposes.
[01:03:42]
And there what we do is we have Lambdas render the Elm, thunk the API, serialize the Dom
[01:03:49]
and then send that to S3, you know, for like cloud caching at the edges.
[01:03:54]
And that's exactly what Google wants to see.
[01:03:57]
So there's no loss there for us.
[01:03:59]
You know, we do a lot of that and that's great.
[01:04:00]
And then maybe you'd think, oh, like streaming interfaces, you know, highly like real time
[01:04:06]
web sockety things.
[01:04:07]
Fair.
[01:04:08]
That we have not explored yet.
[01:04:09]
You know, I don't know what it would be like to build a Figma in Elm.
[01:04:14]
You know, if it renders a billion bucks, we just saw a Figma exit for 20 billion.
[01:04:17]
So maybe real time matters, you know, we're going to figure that out.
[01:04:20]
I actually don't have enough experience to say, oh, Elm would be great for that.
[01:04:25]
I do believe there's plenty of experimentation making video games in Elm.
[01:04:29]
And I think those folks are kind of answering de facto whether that's doable or not and
[01:04:33]
how that scales from a code standpoint.
[01:04:35]
I'll defer to them because we don't have a need for it presently.
[01:04:38]
But you know, I built EdTech, I've built consumer, I've built B2B and there's nothing about
[01:04:46]
we're doing that doesn't presently feel like it'd be appropriate for all of them.
[01:04:49]
I guess mobile, you know, you can put me in a corner, I'd say mobile.
[01:04:52]
Like if you're going to do it native, go native and maybe React Native is better than what
[01:04:57]
you'd get from Elm until someone has built Elm native.
[01:05:00]
And you know, maybe that exists already.
[01:05:01]
I don't know.
[01:05:02]
I have no experience on that.
[01:05:03]
So I couldn't say.
[01:05:05]
But yeah, otherwise it feels pretty versatile.
[01:05:08]
So something that we've seen asked quite a lot in the Elm community is how do I convince
[01:05:13]
my CTO that we should move to Elm?
[01:05:16]
Right.
[01:05:17]
And there's probably no one asked you because you already chose Elm from the get start.
[01:05:21]
But yeah, do you have any advice on that?
[01:05:23]
Like how should one talk to their CTO or how would you even talk to another CTO about recommending
[01:05:31]
Elm?
[01:05:32]
Boy, do I share this person's pain.
[01:05:34]
And by this person, I mean the dozens and dozens of folks that I've seen ask that in
[01:05:38]
the forums.
[01:05:39]
Yeah, it's a lot easier for me.
[01:05:41]
I didn't have to convince anybody but myself.
[01:05:43]
And I already had the background in programming language theory and type systems that allowed
[01:05:48]
me to appreciate what those mean.
[01:05:50]
I think in a lot of ways, the reason or one of the ways I think people struggle to convince
[01:05:54]
their teammates or their boss to use Elm is because Elm feels a little bit like shooting
[01:06:00]
the moon.
[01:06:01]
Like if you go all in on it, you won't get errors.
[01:06:02]
But that's not a very gradual slope.
[01:06:06]
And so if you've never experienced the literal magic of no errors and insanely robust, and
[01:06:14]
that undersells it, perfectly robust refactoring, you do not have the mental model to appreciate
[01:06:20]
what the language can bring.
[01:06:22]
And so trying to convince someone that's never used one of those languages that this thing
[01:06:27]
is that powerful sounds like crazy sauce.
[01:06:30]
Like it's just such a giant bridge.
[01:06:35]
So I'm really sympathetic there because I'm in CTO groups.
[01:06:39]
I talk to my peers about, here's what we're doing.
[01:06:42]
Here's how we get away with so few folks that are so powerful and so productive.
[01:06:46]
We don't have these kind of errors you're talking about.
[01:06:48]
Like it just never happens.
[01:06:50]
And I honestly think that even though I would like to believe my fellow peers in those groups
[01:06:57]
respect me and would default, give me the benefit of the doubt, it's not like I'm going
[01:07:02]
to follow it up in any way.
[01:07:03]
Like, hey, I'm actually thinking that might be right.
[01:07:06]
Like can we talk more about it?
[01:07:08]
It's just, it's too out there.
[01:07:10]
So that is a really hard one to solve.
[01:07:13]
I think there's a couple of ways to solve it over the medium to long term though, which
[01:07:17]
is more conversations like this, more companies saying they've had success like this, which
[01:07:21]
means more projects start with this kind of tech stack in the first place and skip that
[01:07:25]
whole who do I need to convince.
[01:07:27]
I think the other ways to approach it are, it's cool that you can embed Elm inside other
[01:07:31]
apps.
[01:07:32]
You can embed a little Elm experience inside an existing webpage or a react app.
[01:07:37]
That's awesome.
[01:07:38]
Yeah.
[01:07:39]
Using web components again.
[01:07:40]
Using web components, right?
[01:07:41]
That's really cool.
[01:07:43]
But I think the challenge still remains, which is any amount of Elm in a code base means
[01:07:47]
that someone has to understand this mental model.
[01:07:49]
People have to be comfortable learning how to work in a functional system.
[01:07:52]
That's just a far bridge for folks.
[01:07:55]
So this gets to the same pain I had with like, why isn't the world using standard ML in like
[01:08:00]
the 2000 era where I'm like, no, this is obvious.
[01:08:03]
Well, it wasn't obvious.
[01:08:04]
It's still not obvious.
[01:08:06]
I think the tides are shifting though.
[01:08:08]
I think between TypeScript, Rust, like these very popular languages now that have type
[01:08:14]
systems in them and people are moving away from the pile of mud that was JavaScript or
[01:08:21]
the security hellscape that is writing kind of native C code.
[01:08:26]
These languages are educating a whole new generation of folks on why data modeling is
[01:08:31]
so important and how to do it in a really sound way.
[01:08:34]
Rust more than TypeScript, obviously.
[01:08:36]
That I am hopeful that folks will show up with the right default perspective in the
[01:08:40]
future to go kind of all in on these things.
[01:08:43]
Maybe that's wishful thinking, but the trend seems to be finally pointed in the right direction.
[01:08:48]
Yeah.
[01:08:49]
So a lot of companies are starting to use TypeScript now and I'm guessing that they
[01:08:54]
want the same guarantees that the Elm gives you or at least that's the direction that
[01:08:58]
it wants to go to.
[01:09:00]
But TypeScript and Elm are not equivalent.
[01:09:03]
You have experience with both.
[01:09:06]
How would you tell a CTO, no, TypeScript and Elm are not the same?
[01:09:10]
Yeah.
[01:09:11]
Again, this is so true and so frustrating.
[01:09:14]
It's like that shooting the moon.
[01:09:15]
Like, well, we have TypeScript and we still have errors.
[01:09:17]
I'm like, oh my God.
[01:09:18]
You are TypeScript.
[01:09:20]
I love that we have it because we have a JavaScript backend.
[01:09:22]
So like, thank God for TypeScript relative to the alternative.
[01:09:26]
But you can still drop to any.
[01:09:29]
You can still have mismatches with your types and your libraries.
[01:09:33]
Things can go weirdly wrong all over the place.
[01:09:36]
It is nowhere near as rock solid sound as Elm.
[01:09:40]
And unless you've played with a language from the Elm universe of languages, you really
[01:09:45]
have no hope of appreciating it.
[01:09:47]
That's the thing that burns me.
[01:09:48]
It's like you have to get someone to play with it and see before they'll have that aha
[01:09:52]
moment because otherwise you'll have these false equivalences.
[01:09:57]
You can write anything in any programming language.
[01:10:00]
Types aren't all they're cracked up to be.
[01:10:01]
They don't solve everything.
[01:10:02]
It's like, well, what type system did you use?
[01:10:05]
Like Java with nullability and class casting and all this factory pattern nonsense that
[01:10:11]
seems really painful.
[01:10:12]
Yeah, I can see why you think that.
[01:10:14]
Or TypeScript, which is also really freaking complicated and not bulletproof.
[01:10:18]
I can see why you think that.
[01:10:20]
Dear world, please, and this audience is deaf ears because you're already there, but please
[01:10:24]
try Elm.
[01:10:26]
Try a Haskell, try an ML.
[01:10:28]
I'm not saying you would use those other ones in production in quite the same way, though
[01:10:31]
some folks do.
[01:10:33]
But it is a world of difference.
[01:10:35]
I don't have a good way to help bridge that gap.
[01:10:37]
I can see it really clearly because we live with both, but you have to experience it to
[01:10:44]
believe it.
[01:10:47]
You crack that.
[01:10:48]
You figure out how to communicate that to folks without them having to experience it
[01:10:52]
and the floodgates will open.
[01:10:55]
But I have not in my 20 year types crusade figured out how to do that because the nuances
[01:11:02]
matter a ton and Scala, Java, TypeScript are not the same, nor is Haskell.
[01:11:10]
So there's a real Goldilocks thing going on here.
[01:11:14]
It requires a lot of ecosystem experience, I think, to appreciate.
[01:11:18]
I wish I had a better answer on this, honestly.
[01:11:20]
I really do.
[01:11:21]
If you're CTO, I won't use Elm.
[01:11:23]
Email Aaron.White at V and the R.com and we'll solve it.
[01:11:28]
But I would like more folks to use it.
[01:11:31]
I think it would create a better world for sure.
[01:11:33]
And it would be much more satisfying and robust.
[01:11:36]
But I haven't found the magic turn of phrase yet to skip people into that aha moment.
[01:11:43]
I mean, they will try Elm and then they will be stumped by JSON decoders.
[01:11:47]
So then it's game over.
[01:11:49]
So I think as a community, we can start solving the onboarding problem here and showing some
[01:11:54]
of that power sooner and not getting people caught up in things that they take for granted
[01:11:59]
from the simplicity of other languages today.
[01:12:02]
Well, the reason it's so easy in JavaScript is because all bets are off.
[01:12:06]
But you don't know that because you've been living in that world and you've got Stockholm
[01:12:09]
syndrome and you think that null references must be a part of life.
[01:12:12]
And they don't need to be.
[01:12:14]
That's the deep secret.
[01:12:15]
They don't need to be.
[01:12:16]
You're just you've been abused for so long.
[01:12:18]
You didn't know any better.
[01:12:19]
But there's a better way.
[01:12:20]
On that topic, what do you think that the Elm community needs to do to grow?
[01:12:25]
Because it's not like we've seen the Elm community explode in numbers.
[01:12:29]
I think in part due to the fact that COVID happened, there were a lot of conferences
[01:12:35]
that were canceled and I'm sure other reasons.
[01:12:39]
So what do you think it needs to do to grow?
[01:12:41]
And what would you like to see happen in the Elm community?
[01:12:45]
I think there's three things that I'd like to see, one of which I'm responsible for.
[01:12:49]
So maybe I'll start there, which is I think folks that are using Elm need to just publish
[01:12:54]
more, whether that's libraries or blog posts or technical analyses, whatever it is, publish
[01:13:02]
more.
[01:13:04]
If you hear that vendors a billion dollar company and it's on a tear and all this great
[01:13:09]
stuff is happening and you see our reports from Sentry that show you exactly how few
[01:13:13]
front end errors we have and how it was grammarly until we fixed that one weird thing.
[01:13:20]
Is it public?
[01:13:21]
Not yet, but I'm putting the onus on me right now.
[01:13:23]
I'm saying we need to be doing this.
[01:13:25]
Anybody who's using Elm needs to be publishing more.
[01:13:27]
And credit to the folks that are, like No Red Inks of the World, et cetera, published
[01:13:31]
left and right.
[01:13:33]
Richard has in this way as well.
[01:13:35]
So that's valuable.
[01:13:37]
We need a lot more of that.
[01:13:39]
Number two, and the COVID thing really bums me out because we were starting to host Elm
[01:13:42]
meetups and it's just awesome to talk with folks and it's hard to replicate that kind
[01:13:48]
of, oh, this is real.
[01:13:49]
This isn't some weird forum online.
[01:13:53]
So COVID really is a bit of a downer in that regard.
[01:13:56]
But I think more examples made easier to access.
[01:14:02]
So I would love if the Elm page leaned into marketing a little bit more than it does.
[01:14:07]
I'm talking about like elm.lang.org.
[01:14:12]
None of us can change that one exactly, but we've got some maybe social sway here.
[01:14:16]
I think that matters.
[01:14:17]
I think it's one thing to keep a page simple and say, here's what we do and here are the
[01:14:21]
library docs.
[01:14:22]
But to link out to a well structured gallery of all the cool apps that have been built,
[01:14:30]
the techniques, things like that, I think shows the actual momentum of the community
[01:14:35]
in a way that you can't find in your first contact.
[01:14:39]
That's rough.
[01:14:40]
You go to a lot of pages and they'll be like Facebook, Google, da, da, da, da, da, and
[01:14:46]
it's like there's social proof.
[01:14:49]
We have some social proof.
[01:14:50]
It's not quite the same, but it's only going to get better.
[01:14:54]
So leaning into that or galleries, but otherwise just investing in that, sharing what's already
[01:15:00]
been accomplished.
[01:15:01]
It's not even making stuff up.
[01:15:03]
It's not being mobastic.
[01:15:04]
It's like, let's just put it out there and that doesn't need to be corporate logos because
[01:15:06]
I know that some folks will hear me saying that.
[01:15:08]
I think that I want my logo plastered all over a bunch of pages.
[01:15:11]
It literally could be galleries of apps, links to blog posts, but spend more time on that
[01:15:16]
social proof.
[01:15:17]
Then I think this one takes a long time, but I think some bootcamp needs to start with
[01:15:22]
Elm.
[01:15:23]
We need to get Elm injected into the education of coders earlier.
[01:15:28]
I think one big problem that languages like Elm have is by the time people get exposed
[01:15:32]
to them, they've already been mutilated by having done some work in some other lesser
[01:15:37]
language.
[01:15:41]
Every bootcamp is teaching everyone how to do React.
[01:15:44]
Fine.
[01:15:45]
But React is super complicated at scale.
[01:15:48]
It's real weird.
[01:15:49]
A lot of problems with it.
[01:15:51]
It's not a panacea.
[01:15:53]
But once you've learned procedural code, once you've learned object orientation, once you've
[01:15:56]
learned this framework, you have a fixed set of assumptions about how the world could
[01:16:02]
or should work that are harder to undo later.
[01:16:05]
But if you get in earlier, you can make folks lives easier.
[01:16:09]
I would say this is the thing that always got me.
[01:16:12]
There's, backing up to my Comp Sci background, there's Turing machine based languages, the
[01:16:17]
procedural languages, and there's Lambda calculus based languages, the functional languages.
[01:16:22]
If you have coded at all in both of these, you are a superhero because you can see through
[01:16:27]
the matrix of how this stuff all works.
[01:16:30]
But most folks only ever get exposure to procedural languages.
[01:16:32]
And they do their long term cognitive ability, a massive disservice by not giving themselves
[01:16:38]
this alternative model, which I actually think is easier to reason about.
[01:16:42]
That's the other crazy part.
[01:16:43]
It only seems so hard because the world discovered it and kept promoting it through the lens
[01:16:48]
of math programs and computer science, the philosophy logic arm, not the computer engineering
[01:16:53]
arm.
[01:16:54]
And so it's like it leans way too heavily into theory when in practice it's actually
[01:16:59]
way simpler to reason about.
[01:17:00]
Your function is inputs and outputs.
[01:17:02]
That's it.
[01:17:03]
There's no outside world except those two things.
[01:17:04]
Cool.
[01:17:05]
I can write that.
[01:17:06]
So I think getting folks educated earlier in their careers in this stuff is its own
[01:17:11]
form of opportunity.
[01:17:12]
One, it's a 20 year horizon, but you could serve the broader realm community through
[01:17:17]
that better.
[01:17:18]
But two, I actually think it would make for better coders because I think you start to
[01:17:21]
learn about constraints and functions and reasoning at a kind of a pure level versus
[01:17:27]
a hack the machine to make it work by doing weird little copy paste incantations.
[01:17:31]
Yeah.
[01:17:32]
It's somewhat unfortunate that the biggest selling point of Elm is look at how nice it
[01:17:38]
is to work with existing code.
[01:17:41]
And when you're being introduced to something new, that's not the first thing you do.
[01:17:46]
So you don't get to experience that, let alone a larger scale, more complex real world situation.
[01:17:52]
So you don't get that sensation.
[01:17:54]
And what's more, one of the pain points that we've been talking about is the boilerplate,
[01:18:01]
the multiple sources of truth for wiring up a single page app and wiring up JSON decoders
[01:18:10]
and things like that, just getting all those things in order.
[01:18:14]
But hopefully, so that can be people's first experiences.
[01:18:16]
Oh, I have to write a JSON decoder to do this.
[01:18:18]
Oh, I have to wire up all these things.
[01:18:20]
But then you get things like Elm SPA making that more mainstream, a more normal way to
[01:18:27]
do things.
[01:18:28]
And suddenly, that initial experience of playing around with Elm hopefully becomes more frictionless.
[01:18:34]
And so I hope that our future has more of this type of thing.
[01:18:38]
Yeah, I would hope so too.
[01:18:39]
And I think at the end of the day, with the refactoring ability of Elm is something you
[01:18:43]
only appreciate when you've done large scale refactors and failed frequently.
[01:18:48]
Suddenly, it becomes a lot more attractive, but if you're just starting out with it, you
[01:18:52]
have no basis to appreciate the difference because you've never experienced it.
[01:18:56]
And you're not going to get there right away either.
[01:18:58]
It's going to take your own corpus of work to then see the power of it.
[01:19:03]
That's tough.
[01:19:04]
Yeah, that's tough.
[01:19:05]
I think I mentioned this on a different episode, but I think that if someone starts learning
[01:19:10]
Elm and then they discover JavaScript, they'll be like, oh, this is so much simpler to do,
[01:19:17]
like JSON.parse or mutating something.
[01:19:20]
This is a lot less code to write to do the same thing, without understanding that there'll
[01:19:25]
be trade offs like crashes and stuff like that.
[01:19:30]
I'm not entirely sold on the fact of learning Elm first, because I think people will be
[01:19:36]
jealous of easier solutions or seemingly simpler solution that will seem simpler than Elm.
[01:19:43]
Yeah, I wonder a little bit on that.
[01:19:46]
Nobody played Delos Advocate, which is you're probably already a good JavaScript coder,
[01:19:50]
so you don't remember the pain of learning JavaScript or your first procedural language
[01:19:55]
as much anymore.
[01:19:56]
But I learned on C, so it's burned like PTSD scar tissue for me because things would just
[01:20:03]
like crash, segfault, like no feedback, no idea why that happened.
[01:20:08]
And having to manually reconstruct the whole program I had every time to find out that
[01:20:12]
I abused a pointer somewhere, to literally reload all that context because I had no steel
[01:20:17]
girders to stand on was brutal.
[01:20:22]
This is why I think my professor said that thing once upon a time, which is like, the
[01:20:26]
only thing you can do is write programs that don't make sense.
[01:20:28]
Well, yeah, because all I'm doing is I have a mental model of how the code should work,
[01:20:31]
and I'm looking for where my keys hit the keyboard, and it mismatched my preferred understanding.
[01:20:37]
There's this segfault pain loop in the middle to get me there.
[01:20:42]
Why can't I just tell the computer this stuff?
[01:20:43]
So I think a lot of folks learn JavaScript the first time, run into null reference exceptions,
[01:20:48]
undefined is not an object, things like that, and are just left like, just, what the hell
[01:20:54]
happened?
[01:20:55]
And it takes a while to get through that.
[01:20:57]
Once you're past it, yeah, JSON.parse does seem easier.
[01:21:00]
But you have to feel the pain, right?
[01:21:04]
Yeah, you got to feel the pain first, and that's the part that I think senior coders
[01:21:08]
have forgotten, is just how awful that was.
[01:21:13]
Versus when I show people an Elm compiler error, they're like, oh, I wish I had this
[01:21:17]
when I was learning to program.
[01:21:18]
That's usually the first response.
[01:21:21]
I wish I had it too.
[01:21:22]
It's like a buddy telling you, oh, I think you mistyped this.
[01:21:24]
Did you mean this thing?
[01:21:25]
Like, oh, thanks, friend.
[01:21:26]
Yes, I did mean that.
[01:21:28]
Let's keep going.
[01:21:29]
And comparing a trust alter to Haskell or ML, the culture of even those, and I'll speak
[01:21:37]
more to ML, was like, function f goes from alpha to beta to gamma to whatever.
[01:21:43]
It's like you're not even talking in terms of type variables that have human names.
[01:21:46]
The culture is just throwing a mathematical blah bar.
[01:21:51]
And then it's no surprise nobody bothered to invest in compiler errors that were readable
[01:21:54]
by humans because the types were inscrutable anyway.
[01:21:57]
So saying you can't unify this to this didn't matter because it was some strange Greek symbol
[01:22:03]
to some other strange Greek symbol.
[01:22:05]
The world's evolved a lot since then.
[01:22:07]
The compilers can do more and they can be helpful copilots in a way that no one ever
[01:22:13]
thought they would be previously.
[01:22:15]
They were theorem provers.
[01:22:17]
That's very different.
[01:22:18]
So I think that the value of that as a pedagogical tool is massively underrated, mostly because
[01:22:25]
most people that, again, I think you've just internalized the pain too much.
[01:22:29]
We're all here with abuse and Stockholm syndrome and it's hard to see past it.
[01:22:35]
That's my theory anyway.
[01:22:36]
Well, Aaron, thank you so much for this conversation and for all the open source stuff that's coming
[01:22:43]
out of Vendor, for sharing your story, for being social proof of a company that's using
[01:22:51]
Elm as part of the core of their success for a very successful large business.
[01:22:56]
Thank you so much.
[01:22:57]
This has been a pleasure.
[01:22:58]
Thank you.
[01:22:59]
Thank you both for having me.
[01:23:00]
I really appreciate the chance to stand in that soapbox for a little bit because I could
[01:23:04]
do this all day.
[01:23:05]
This is a lot of fun.
[01:23:08]
We are fortunate to be playing with some really awesome tech to do really cool things and
[01:23:13]
it just feels great to share it.
[01:23:15]
It feels like a great time for Elm.
[01:23:18]
What should we leave people with?
[01:23:19]
Is there anything you want to share before we say goodbye?
[01:23:24]
Life advice, self serving requests to the community.
[01:23:27]
Number one, I think this is a good kick in the pants for me to make sure that we publish
[01:23:32]
what we're doing to help other folks that would do the same or seek to convince their
[01:23:37]
peers or their bosses that this stuff could work.
[01:23:41]
I feel your pain.
[01:23:42]
Maybe I can arm you with a little bit more ammo than I'm doing today, which is not nearly
[01:23:45]
enough.
[01:23:46]
So that's my takeaway.
[01:23:48]
The easy one is we're hiring.
[01:23:50]
But I think the thing that I love though is just how much better a coder Elm has made
[01:23:56]
myself and others in terms of just I have a newfound appreciation for the quality of
[01:24:03]
your domain modeling influences the quality of your code and the quality of your product.
[01:24:06]
And Elm really brings the domain model to the forefront as opposed to an unarticulated
[01:24:12]
abstraction in your head while you're coding.
[01:24:15]
And that's huge.
[01:24:16]
And so if you're not yet thinking in that way, domain model first, types first, I would
[01:24:21]
encourage folks to try it because that's the beginning of that switch over from I'm just
[01:24:25]
kind of like throwing things together to like making truly scalable systems that are pleasant
[01:24:31]
to use.
[01:24:32]
So best of luck.
[01:24:34]
Amazing stuff.
[01:24:35]
Thanks again, Aaron.
[01:24:36]
And Jeroen.
[01:24:37]
Until next time.
[01:24:38]
Thanks for your time.