Hello, Dillon.

And, well, today we're talking about something that we haven't directly talked about, which

is Elm itself.

And we're very happy to have on the show with us today, Evan Ciplicki.

Evan, thank you so much for joining us.

No problem.

Thanks for setting us up.

Our pleasure.

Well, yeah, so I was hoping to, like, one thing I've been wanting to talk about a lot

is the funding stuff.

So that was, I actually had a conference talk scheduled for, I think it was like March or

April of 2020.

And I like ran a version of it in December 2019 around where I live for some compiler

students.

I don't know if it went over well because they're just learning about like how to generate

assembly and I'm like, well, Google has all these ads.

Yeah.

But yeah, that's something that I think feeds into a lot of the conversations around open

source.

And like, I think I've been like pretty naive about it for many of the years I worked on

the project.

So it's something that I think I'd be excited to talk about.

I don't know if you guys had thoughts.

I know you saw the recent panel discussion with Elixir and Julia perspectives.

So yeah, I was curious like how that hit your ears and what you thought of that.

I mean, it was awesome to hear about it.

I thought that that PL talk panel with Jose and Jeff.

Yeah, it was super interesting in particular.

I thought it was really cool to hear you talk, Evan, about the pros and cons of the patronage

model.

And just like one of the points you brought up that I was really interested in was how

you've wanted to support other people contributing to Elm more regularly.

And you're just kind of like with the patronage model, you were saying it's sort of a limitation

that you're like, sorry, I'd love to pay you to contribute, but it's already hard to make

a business case for somebody to pay me a full time salary, let alone to pay more people.

Yeah.

So that's one of the things that's been a I've sort of understood the contours of the

bargain better.

So like, from my perspective, personally, it's a very easy setup where it's like, it's

an under market thing, but I get to work on it full time and everything's under an open

source license.

So it's can't be like claimed by some company if it gets bought or whatever in the future.

So I'm like, wow, that's great.

And I mean, 22 year old me was like, wow, that's amazing.

But as contributors who have made really cool stuff have followed, you know, the classic

arc of open source, which is you start on something on your own, it's very exciting,

you get to implement it, there's no deep considerations besides like what you're excited about.

And then when a couple people get interested, it's really exciting, because, interestingly,

it's like it's similar with YouTubers, it's like the that first content you're making,

the people who show up are really there because they want that.

And then it gets to a certain point where a broader set of people know about it.

And it's not necessarily for everybody.

And the sort of conversation online changes.

And then it's like harder for the creator, whether it's a, you know, technical or entertainment

content, it's like harder for them to participate in those conversations.

In the same way, and then that can start taking a toll on their mental health or physical

health or relationships outside of it that, you know, they don't necessarily talk about

on the internet.

And it's like, everyone I talked to who has been an open source, like some number of years

can talk about this story to some level, I don't know what how you guys relate to it

exactly.

So I'm currently in the happy phase, where a lot of people are very interested, not enough

to give me a lot of contributors, though.

But I'm still in the happy phase.

But I've noticed I've been in the later phases in other smaller projects.

Yeah.

And I mean, the volume is also like a part of it, where it's like when you're getting

like one interaction a month or two or three, you're like, Oh, cool, you know, I got a little

blue notification dot in my GitHub.

Oh, someone found a bug.

Okay, let's let's fix it.

Let's take the day for that.

Yeah, that's and at the end of the day, it's done.

Right.

I'm still in that happy phase for me.

Is it the same for you, Dillon?

I mean, I know it's everyone has their own.

I've gotten both.

I've gotten both sides.

But I've definitely gotten I've seen a lot of people express appreciation, which always

makes me really happy.

I've also had days where I get pulled down by some comment that's like, I expect this

thing or like, why isn't it this way? or why did you make this decision?

And it really drags you down.

I can imagine with like, supporting something is broadly used as a language because like

with tools like Elm GraphQL, like the scope is kind of narrow enough that I can say like,

this is what this project does for you.

And this is like, these are the the goals of the project.

And if things are outside of it, I can say like, okay, great, maybe another thing can

do that.

And you can almost say that it's done at some point.

Exactly.

Yeah.

Whereas with a programming language, you can never get to that point.

And I think it's also like being able to draw those boundaries with a language is like,

should this feature be in the language?

It's like, it's hard to like have a predefined answer to that, right?

It's like, I mean, for things you've seen before, it's like, you kind of know the landscape

there and know what the problems are.

But it can be really complicated to like convey that.

So I think another component to the like, arc of open source is like time component.

So that's the kind of thing where at a certain point where the kind of thing you're talking

about where like, you can really get down for like a day based on, you know, someone

who wants something and is like, excited about the project, but like, it was read in a way

that was like hard to take in in a positive way.

Right, right, right.

It takes a toll, right?

So it does.

I've noticed my threshold for those kinds of interactions is like, it's more painful.

Yeah.

Over time, like it's not Yeah, I always hoped I did get stronger with it.

And it's like, it's not always that way.

Yeah, one of the things that I've noticed, I'd be I'd be curious to hear your experience

with this, Evan, is like, the things that get me down, probably, probably most often

are just like, sometimes people frame things, and I really appreciate it in a way where

they're like, hey, these things are awesome.

I'm not sure if you've thought about this thing, there are probably challenges.

But you know, here's some things to think about if you haven't, do you think you might

ever consider supporting something like this, yada, yada, yada.

And I'm like, super appreciative when people strike that tone.

And sometimes the tone is like, why doesn't it do this thing?

Or why does it do this thing this way? or and sometimes the thing about that is just

the tone, it can feel like it's, it's not acknowledging all the things that are there

that are good about it.

And sometimes when you've poured your heart and soul into making these things awesome,

they're like, Oh, the docs don't really talk about this thing.

Do they?

And it's like, yeah, like, it's just I just added this feature.

I've been like working for three months on my weekends to build this thing, which I thought

was super exciting and all you have to say about it is like, Oh, the docs don't tell

me how to do this.

Yeah, it feels it takes the wind out of your sails, you know?

I know the exact thing.

And it's like, in my mind, I have to do the like, it is, you know, technically, it's a

constructive comment, and it is a thing that can be better, you know, and it's like, you

know, being in a certain kind of position, it's like, I can't, if I'm feeling frustrated,

like I need to be really careful about how I'm communicating.

Because like, ultimately, my, my goal is to make a cool thing that people like, and they

have as good as possible and experience with it.

And so like, I don't want to be because I'm feeling bad, or I'm feeling hungry, or, you

know, something, you know, my mom's feeling sad about something that like, someone's experiencing

that, and they're just trying to make a cool program.

But I think one of the things that happens when in the unpaid one, oh, oh, yeah.

I think the root of it is like, at least for me, I've become come to think of it more as

like, knowing what kinds of sacrifices or choices, not, not sorry, but like choices

I've made to work on the language and do the things I'm excited about.

So it's like, in my case, walking away from the Google job, I wanted to do that.

But it's like, that is a choice that costs a lot of money, if you if that's how you look

at the world.

And so it's like, okay, like, that's a price I want to pay to pursue this.

And that's like, being on the patronage model, you have this sort of like uncertainty, even

more so than if you were on your own doing a consultancy or something, because it's like,

I don't really have agency over my salary, you're relying on someone else's like good

will, and hopefully it fitting into their business model somewhat.

Yeah, or like whatever they imagine I do, you know, whatever it is.

So like, being in a case where it's like, okay, like, hey, like, you know, I want to

have kids with my wife, it's like, when does it make sense to do that such that the Elm

work can continue as we want as well.

So it's like, that's the kind of conversation I might be having about something not necessarily

on an online forum.

And so I think when it's like, hey, why isn't there this?

Why isn't there more?

I can't, you know, have seen that conversation.

It's like, you know, there's, there's like physical limits, there's mental limits.

And like, it may, it's uncomfortable to talk about that in like a GitHub issue about right,

right.

Yeah, yeah.

String encoding details.

Right.

Like, like you said, you can have a technically constructive comment that's giving useful

information about something, but it can feel there's like this whole emotional context

that gets missed.

So it can feel like it's shooting down all the other things that are going on.

Yeah, and so, I mean, it's been interesting to see how that's played out over like the

pandemic where I think tech, Twitter, at least what I saw got a little kinder or less active

maybe.

And like, since, you know, beginning of this year, it's gotten a little bit more active.

So I don't know, I think that all like changed a lot of the dynamics.

But in terms of like getting back to the patronage model, which is how we started this, it puts

me in this lucky position where it's like, if I'm struggling emotionally with something,

it's like, okay, well, I can take a rest and I can come back and it's my job, you know,

I need to come back.

But for people who aren't in that situation, they say, hey, it's my Saturday, and my spouse

would like to see me this weekend.

And it's like, what am I gonna do?

Or kids, you know, people with kids, that's a tough call to...

Yeah, so I think that's another component.

So to go back to that point of like, seeing other people struggle with this and not knowing

how to help is like, I see other people in open source goes through this.

And having to come to a point where they say, hey, I have a kid on the way, like I need

to have different interactions with people online.

And you know, I hear that and I say, that's great, like that someone's choosing their

kids, that someone choosing their family, or their physical health or mental health

as the top priority, like, I can only be happy for that.

And in a patronage model, you say, hey, like, this was a conversation I had explicitly,

it's like, people are getting to limits, you know, and, you know, people who work at the

company too, but have open source stuff, what do we do?

And it was just like, well, that wasn't how they looked at the support of how they thought

of the patronage model.

And it's like, you know, that's just one of the things that you have to be aware of.

So like, if I could give myself advice, whatever, nine years ago, I think I would have been

a lot more aware of trying to do some kind of consulting outside of it, or being much

more aware that having full support from the engineering organization isn't good enough,

because like, that's not where the decision stops, right?

Like everyone in the whole org can be like, this is a mistake, this or that choice.

But it's a classic case of the tragedy of the commons, which for anyone who doesn't

know what that is, it's just this idea that, sorry, there's a teapot over here.

It's all good.

You have like, these fields that cattle can openly graze in a community in a village,

and you're supposed to limit how much grazing you do to make it sustainable for the whole

community, but there's nothing preventing one person from overgrazing, and then actually

causing the pastures to go dry and become useless.

And since there's nothing preventing, like any person can go and, you know, it doesn't

benefit the community, but there's nothing incentivizing you to behave in a way that's

going to benefit the long term longevity of the community.

And similarly, like with open source work, there's so much value that's being created

by it, and if it can be supported even more, there's a clear monetary benefit.

But who pays that and what causes you to be incentivized to pay for that?

Yeah.

And what's interesting is like, depending on the specific project, like the norms about

what are acceptable models varies very widely.

So like, I have the sense that in programming languages, there's some price to pay for having

a consulting firm.

I think people are somewhat skeptical of that in a way that they aren't with operating systems,

right?

It's like Red Hat can be this massive business, and it's like, oh, well, that's an operating

system.

But when languages do it, it's like the conversation is not quite the same.

And then like with databases, it's like, hey, we have this hosting thing, and we have all

this open source stuff, and that's fine.

And with scientific computing, some of them just have straight up licenses where it's

like different universities pay for access to Mathematica or Stata or whatever.

And then with like individual packages, it's like, I don't know the extent of people who

have figured that one out.

So the thing of the patronage model is that like your bounds or whatever are set around

you.

So I think personally, like one of the things, you know, it was my like December 2019, I

was thinking a lot about this topic.

And my big thing was like, I want to move away from patronage and explore what other

things can work.

And this question of like, how do you connect yourself to a system that's going to like

be healthy?

So like, the ones that the ideas that I had were like, you can have the donations, which

I'm very skeptical of, you can have consulting, you can do some kind of like, something kind

of like Netlify, where it's just like, hey, really easily get your ELM app online.

And each of these has different sort of trade offs and time costs.

So it was actually interesting to do the PL talk panel, because like, I hadn't talked

to someone who was doing a language that had explored some of these models so explicitly.

But one of the things I found interesting was that neither of those two folks from Elixir

or Julia were doing donations for engineering work.

And that was one thing I noticed is that like, it's very, I don't know of a language that

does that.

It's common for languages to have like a nonprofit to run the conference.

I think that's a somewhat defensible use of nonprofit status.

But I would feel really weird like being a software engineer, and like running that through

a charity, but the people who benefit from the charity are like, often like companies

with the money.

It's like, it feels weird.

I don't know.

I mean, some countries don't do nonprofits in the same way as us.

But it's something I personally have like ethical reservations about.

It's like, we don't have to get into that.

Yeah, it's tricky because with open source, like language or tool or whatever, being open

source makes it better.

So who would use a language that's not open source?

It would feel like very risky.

You know, Microsoft learned that lesson at one point and open sourced everything because

it created a lot of ill will.

And it wasn't working.

Like if there's like, you know, you can't look at the code and see what's going on and

stuff.

But then, you know, it makes it really challenging to have funding models to sustain it, which

everybody wants.

Everybody wants to be able to sustain this thing.

So it's a weird situation.

Yeah.

So at least for what I'm trying is, so my wife happens to be a very skilled programmer.

So we're trying a little family business and the sort of like the ranking of things we're

interested in is like trying to do like some sort of easy hosting where like, instead of

the Elm Try page, it's like, hey, you can press a button and it's on the internet.

Cool.

GatsbyJS sort of has that funding model as one of their core things, it seems like.

Yeah.

And next to that might be some level of consulting where like, I have my particular skills, which

like, I don't know if there is broadly useful, you know, it's like, but talking to Jose from

the, from Elixir, it was really interesting to hear how their like developer subscription

mod thing works, where you have like a direct line to some small set of like people who

are working on the compiler and core libraries and stuff.

And what's interesting about that is like you then in spreading the information that

it's good to spread to the community, it's like that's also supporting the work on the

language.

I definitely know there's different, I don't know if I'm like the ideal consultant dispositionally,

I think I'd need to do a lot of personal work.

Just a specific skill set for sure, like the coaching tool chain and yeah.

Yeah.

So, but I think those two are kind of what we're, we think there's some thing that can

work there and it's like, you know, we're not here to make a bunch of money.

Like if that was the case, I wouldn't have done any of this, right?

This is not a lucrative path for someone who works on compilers, but like hopefully we'll

be able to figure something out there.

And like, I think this comes back to like, no, like the sacrifices you make and not like

choices you make to do the things you want to do is like, Hey, I'm, I have savings to

make it happen.

Right.

And like, I'm confident in our technical skills and our, that we can make that work.

But that's like, all this is kind of like a hard conversation to have in a text format,

you know?

Right.

Cause it's like, there's so much personal stuff and it's like, I don't necessarily feel

comfortable having that conversation with someone who thinks of Elm as like a technical

artifact that you submit issues to and they come out completed in some.

Right.

Right.

Right.

So for somebody who's listening to this and wants to support your, you know, your experiments

that you're doing with different funding, like, you know, let's say I'm, you know, at

an Elm company and I like, who would you want to hear from or how could they support you?

Like if that, would it be helpful if they reach out to you with like, Hey, if you're

looking to do some consulting stuff, here's something, whatever, like maybe we're doing

a parser, maybe we're building like an Elm parser thing and like, can you consult with

us on that?

Would you want to hear from someone like that or like, what do you, what do you envision

for that?

I mean, I think with the exploratory work I'm doing personally, it's still just too

early.

Mm hmm.

Mm hmm.

And then my wife is doing the hosting experiment and also it's, it's, it's too early.

Like I think she'll in her own way, reach out to people and find that when it, when

it's ready.

I actually, I actually have done a little like consulting on compiler stuff and it's

very fun.

I'm happy to do that kind of thing.

So I think with these kinds of things, it definitely makes sense to reach out directly.

If you have a idea or something you're interested in.

And I know like with Prezi and Norit Inc and the other company I did a little, little bit

of consulting with, it's always been that way of reach out, Hey, I was thinking about

this.

And I think with a, with compiler work in particular, it's like having that kind of

focused conversation is really good because you can have more shared context and have

a more focused conversation.

But yeah, I would encourage people to like DM about stuff if they're serious about that

kind of thing.

And also like there's no need for people to worry.

Like I, I can take care of myself, you know, and if I need help, I'll ask.

So I think part of why, part of why I'm hesitant to talk about these things is like, you know,

with a feeling of gratitude, I know that people will be interested to want to help, but sometimes

it's like, it's too early to be at that phase yet.

Does that make sense?

Totally.

I don't know if you guys have had that experience with like stuff you're designing where like

the thing you have just like isn't good.

It's like not worth showing to someone yet.

And you'd have a whole discussion about how it's going to be and how this thing is gonna

work and right.

And yeah, when you're in the exploratory phase and to be clear, you're not talking about

Elm as we know it right now.

You're talking about some experiments.

So, but yeah, I totally can relate to that.

Yeah.

I want to be clear.

Like part of why I'm doing this exploratory work is like, I feel like Elm for browsers

is like, I like it.

I think it's great.

Yeah.

I don't really have a lot of cool ideas, right?

You know, it's like, I don't want to break it.

I want, I like it.

The core pieces are mostly in place.

Yeah.

So I kind of, at least yeah, beginning of this year, I was trying to, I was doing a

lot of exploration of like, what's something that is really special that I could do uniquely.

And I'd spent, you know, like two straight years doing like cleanup or not cleanup, but

like solidifying, you know, like making the parse very fast.

Which had amazing results, but probably was tedious for you.

It's not necessarily that it's tedious.

It's that it's like, I think there's something so exciting about, you know, coming to functional

programming for the first time, seeing that and being so excited about it.

And I felt like my projects were less and less connected to that feeling.

And so, yeah, so I wanted to do something where it's like, Oh, the magic of more side

effects, you know?

And so, you know, I was exploring, like I mentioned in the little roadmap doc, like

the integrating testing or integrating the formatting stuff or fixing the equality thing.

I think for my passion for the project, and I know this happens with other open source

authors, it's like, I need to prioritize the passionate work in balance with this other

kind of work that exists out there.

So that's kind of where I was coming from.

And so I forget if I said earlier, but like just thinking about how do we communicate

with, how does Elm, how do the borders of Elm fit together nicely with a server or database

in a way that like, it would be no change to Elm, but it could be really valuable to

someone using Elm that, Hey, things got a lot easier over there.

So, and I have that feeling of excitement again, but I don't know, it's still so early

where it's like, you know, Oh, like if I do this inlining thing and I'm generating,

nah, nah, nah, it's like, the question is like, does that work?

Right?

Regardless of what designs it may produce at some point.

So it's still very speculative.

Yeah, where does it fall apart if you pull on the thread or does everything come together

elegantly?

You have to sort of go for a while before you.

Yeah.

And I guess I can say like, you know, I'm like, one of the things I'm exploring is like

very aggressive inlining because there are contexts where that can be helpful.

And so I've been following the WebGL work and I'll chat with the people who are pushing

that and sometimes it'll be like, Oh, like that kind of inlining could be really interesting

in the context of like GLSL, like the shader language for 3D stuff.

So like, that's not what I'm working on, but it's like this sort of exploratory compiler

work at this stage, the only thing it can produce is like these possibilities.

So I think it sort of, you know, I've seen open source projects that like, well, I don't

want to, I never want to be talking really big about what I can do later.

I want to have done it before I.

Before you share the results.

Yeah.

Yeah.

And I know not everyone open source feels the same way, but right.

You don't want to make promises that may not be kept.

Yeah.

And I mean, this ties into like funding stuff as well, where like, if you want to be like

crowdfunded, I mean, people who have been in like programming language circles long

enough can probably think of examples where they saw like a crowdfunding thing and they

had really cool demos and then it turns out those demos are not like possible to implement,

but the money went there and you know, that to me is a situation I would never want to

be in the center of.

So like, that's part of why I think like having a nonprofit for like conferences makes sense,

but like tying people's labor, like development work to it.

And that's, you know, I've asked around people like, Hey, if we could do like a year contract

through crowdfunded stuff, would you be interested?

And a surprising number of people will be like, definitely not.

Yeah.

If you don't have anything to showcase or to promise, then like, what are you selling?

Yeah, exactly.

So I think it's like, and because I have sort of personally struggled with taking it really

hard, not meeting people's expectations, even if those expectations aren't my goals for

the language, tying that to my livelihood seems like it for me would be not a viable

model.

Right.

Yeah.

I mean, it seems like a key part of like the secret sauce of Elm from my outsider's perspective

is like you explore big ideas, which I've got to imagine some of those explorations

we haven't heard about because they didn't work out.

I mean, just based on the kind of crazy, really like radical in some ways, features of Elm

that we now think of as the norm and it's our baseline.

I've got to imagine that there were some crazy ideas that didn't pan out too in that process.

Yeah.

I mean, I have an easier time talking about the ones from before because it's clear I'm

not promising that.

Also with the commands and subscriptions, that was one where no one was doing it that

way.

I don't know.

I think there's a story around this I don't tend to tell publicly.

I'll keep it that way, but it's just like people were curious about how to do that,

generally speaking.

And I was thinking like, there's a way to design it where it's much more like type heavy.

So the designs I had, it was like you have to have open union types and you can express

with each kind of effect, it'll show up in the type.

So you can give permissions to particular parts of your code to say you have permission

to use the HTTP effect and you have the permission to use the logging effects or whatever.

And that would be clearly documented.

We go through how to do that in the type system and I'm looking into, I guess they call them

polymorphic variants in OCaml, but there was a discussion about it in Elm recently, like

open custom types where you can just arbitrarily add more variants.

And we sort of went to the limit of that.

And then we were like, what if we didn't do any of that?

And then we were like, oh yeah, that's nice.

So I think that's one of the things of like, I know with, I want to say like larger languages,

we'll have these discussions more publicly.

But I think part of that is because when you're on like a corporate funding model, there are

benefits to like, so many of the considerations shift in subtle ways.

So like if I'm a VP of engineering at Google and I'm putting some of my budget towards

open source project, I'm asking like, well, why am I not putting that towards features

on the products in my org?

So if they're not getting a certain level of usership, it's like, well, we really should

phase this out.

What I'm saying is like, the goal is like, you want it to be big.

You want it to be as big as possible in those kinds of environments.

Like part of why like Apple has their Objective C and Swift is like, they want everyone to

be using their stuff and not someone else's app ecosystem.

And the reason Google is putting all this money in their JavaScript is they want people

to use the web and not apps.

And so when you have the full set of people programming online, there's certain avenues

that make sense, especially if you have billions of dollars to spend.

And so like you can hire the dev rel person to be social media person, to handle the GitHub

issues.

They can like organize all the issues and add the nice labels and organize, Hey, this

would be a patch, but this would be minor and this would be major.

And then bring all that information into a meeting with the core developers and try to

hash out like what can fit in the capacity.

And then the dev rel person goes and has those conversations.

And so it's like, you have a more traditional like corporate product kind of structure where

it's like, there's a support team, there's developers, there's a CEO who is like the

VP.

You know, it's like, you don't call them that, we don't think of it that way.

And so I think...

There's a direct line through the incentives.

I've heard you talk about that, how like there are billions of dollars at stake for Google

being the default search engine in different browsers and that sort of thing.

So they can sort of justify large budgets for ensuring that they're good stewards of

the web.

The support team, if you want to look at it that way, can be big.

So like Chrome, I think is like 60 in Mountain View last I heard.

I don't know the actual number.

It's been years since I've been in that world.

But I think that's one thing that like on a patronage model, it's like super hard to

argue for those kinds of roles.

It's like not only you're not writing software, you're just talking online.

Like what?

And so, yeah.

So I always viewed patronage as a very nice model, as like the nice spot to be in.

And that's kind of what I aimed for previously.

So even at this company, they knew I was working on Elm Review and they may have thought they

would help me out working on it.

But in practice, I don't get the time to do it.

So I feel like I'm getting patronage, but I'm not getting anything or much out of it.

And I'm not even working, designed to work on it full time where I would have other limitations,

I'm sure.

So on that PL talk, there was a Jose Valim.

Yeah.

That with his Alexa support subscription.

subscription.

Yeah.

Yeah.

That sounded amazing.

Like he gets a lot of feedback from the community and he helps them.

And that just sounds awesome for all parties.

Yeah.

Well, I talked with him a bit more.

And one of the things I noticed is like there's personal disposition that fits into that as

well.

Yeah.

So like he's an inbox zero person.

I think that's like that it makes sense that that goes with that kind of relationship or

running things in that way.

And like I have a harder time with that personally, just because like in a deep way, like I surprises

me very deeply troubled.

I am with you on that page.

And Jose, he's consulted to start with, right?

Yeah.

So I think he I mean, he says, I think like Dillon mentioned earlier, it's like it's a

skill that you learn, which I believe, but I also do want to, you know, say like the

way both of you guys communicated.

I was like, I could hear more than skill.

Like it's like you have some like wisdom about that, that I don't I don't see in myself necessarily.

But yeah, I'd be happy to talk to you about it more in depth at some point.

But my background is in coaching and consulting.

And I mean, they're learnable skills.

Well, I think this connects to one of the things Jeff was mentioning, which was like,

with Julia, they had four people who all had like different, different ways of behaving

and different strengths.

And so that's something that like, for people who are interested in pursuing some kind of

goal with Elm, seeing how those can fit together, right.

So like, one thing that was really powerful for Elm reaching more people was like, Richard's

enthusiasm.

Yeah, definitely.

Getting that to in a practical way, like in a way that I can't, I am not deeply in

the culture of like, front end development, to be able to do the kinds of things he was

able to do.

And so that was his, you know, special ability.

And so I think that's something even though we don't have as formally as like formal relationships

as the Julia people had early on is like, that's kind of how I see it.

Richard clearly played a role as a sort of, yeah, and it was not a public face.

But it wasn't like I said, you've been selected, Richard, you are the one.

Right.

Like, he just totally to the point where at one of the Elm conferences, me and Richard

were sitting at a table like outside the conference venue.

And someone walked up and was like, Oh, Richard Feldman.

Wow, I've seen all your talks on Elm.

And then I was like, Oh, yeah, it's awesome.

Really good ones.

Yeah.

That's amazing.

So I think like, and we see that with like, people doing these ambitious tooling projects,

the WebGL stuff that's happening, where Ian's really like finding a way to make it progress.

And like, I don't, you know, I don't, I don't know how much he talks about in public, but

you know, making choices to make that kind of stuff happen.

Yeah.

So that's what I'm hopeful about.

And like, thing that I, I sort of, I don't know, I want to share is just like, in working

in this way for almost a decade now, I've sort of learned my personal limits through

like people being disappointed and me wanting to do more and doing more, but then paying

the price somewhere else in my life.

And sort of like learning how all those things are related.

Right.

And I think if I get into this debate today, I'm not going to be good when I sit down at

dinner.

You know, I don't want to bring that energy into, into these other places.

And so like, I have to be careful about these things.

And so I'm hopeful that in talking about that and like talking about the difficulties in

funding, maybe that's helpful to other people in the community who are facing similar issues

or I don't know.

I wanted to follow up on what you're saying about having the patronage time, but not actually

having the time.

That's a super common story in open source.

I've heard from many people is like, even with 20% time, the, you know, if you're doing

static analysis kind of stuff, it's like to load that in to your head.

It's like, okay, that was my day.

Yeah.

Totally.

So, and I know with a lot of problems, it can be that way.

So it's like certain kinds of work you can do in that way, but I know people struggle

to find the balance.

And so it's something where I think you have to have really clear boundaries and like expectations

with the person supporting the work.

But yeah, so I don't know, like, I wonder if having a more like distributed network

of people doing consulting setups creates more space for that kind of stuff.

I honestly don't know.

I think the Julia person was saying, it's like, we all need a Verall.

I think, you know, yeah.

Yeah.

I mean, it's a, it's a challenge to tie the incentives back to the thing itself because

ultimately at some point there's a natural push towards doing more of the thing that's

incentivized by the business and the business model and all those things.

And if, if that thing is like, you're getting paid to ship this product, then even if they

say your 20% time work on this open source stuff, that's great.

If that's actually not helping with that business goal, then eventually it's, it gets squeezed.

That's just the, the, the natural dynamic that's set up there.

And it's the same with the patronage model.

So like some, I like, I feel like the goal is somehow if you can like relate the value

that you're creating and be paid for that, then there's a natural incentive where it's

like, Oh, that thing that you're doing, that's creating value for us, do more of that.

And like have more money.

That's the, that's the dream, right?

If you can tie those things more directly together.

And so that's, I think why me and my wife are exploring the particular stuff we're exploring.

And I think part of the like culture clash is that so many languages are on the like

big company model and in that one, like growth and market share, no one necessarily like

says it explicitly, but like those are huge factors for people making choices about headcount

where it's like, if you are bringing 70% of people, right?

So a concrete example, like if the developer tools in Chrome are so much nicer that it

drives developers to Chrome, well then the websites work better on Chrome and that will

drive users to Chrome and the developers will tell their friends and family to use Chrome

cause it's nicer.

And Hey, that's default search.

That's something that you can look at like the financial filings of Google, how much

they spend per order.

It's incredible.

And it's like, how are there so many ads making, they can spend that just to give to Apple,

you know, and that like Apple makes about the same amount of money on default search,

selling default search as they do from like app store, the 30% they take on app purchases.

It's crazy.

So like the quantities we're talking about, but like, so when you have your mindset of

like, well, in the context of JavaScript, they would do this.

It's like, well, this whole structure that they fit within like 5% market share, 1% market

share, all these things are like numbers that when you go to negotiate your traffic acquisition

costs like matter millions of dollars.

So I think that's part of where there's like a culture clash between, and I do also think

like because there's so much more money, if you're willing to do things that way, like

I personally have come to feel that like marketing is a big deal.

If you want market dominance or growth or that kind of thing.

And I don't know if you can have market dominance in programming languages without also having

comparable funding.

So that's something that like when I started on Elm, I didn't believe that, you know, I

had this image that like, if I make a really nice thing and it solves problems, well, people

will see that and they'll like, and I never wanted to everyone to use it necessarily.

I just, my thing was like, I want people to know about the option, make a more informed

choice to use it or not.

But the more I've worked on it is like, if you really are doing like a, I don't know,

there's just these like nonlinear returns to marketing, especially if it's tied to a

money machine, like it is it, Microsoft or Facebook or that kind of stuff.

So I don't know, that's a question that I don't have an answer on, but it's something

that I'm like more persuaded by over time.

Yeah.

I also wonder if there's inherently like certain design choices in Elm that are not going to

be as, you know, popular.

Like if you're saying like, we're constraining what you're doing, a lot of people are going

to say like, oh, that sucks.

Like why won't you let me do that?

People don't want to hear that, but a certain set of people are like, oh my God, that's

amazing.

You mean I can't do this thing in that context?

That's brilliant.

Like then I won't get shot in the foot there.

But do you think that that's inherently a quality of the like language design that it

won't appeal to certain people?

Yeah.

I think like the more I thought about like if I was designing for growth and market dominance,

this the limiting features is a loser strategy.

So like the great thing about you can sort of pejoratively say kitchen sink, but in a

more friendly way, say like, you know, languages that are eager to add features over time.

It means that you can have all these different sub communities of different preferences and

dispositions and you see that where like a lot of different companies have their own

style guide.

So they say, we use these 10 features and we explicitly don't use these 20 features.

So that exists in like the C and C++ world where it's like, yeah, we don't check in any

code that does this kind of template stuff and we don't do any kind of code that uses

like prototype stuff.

And so it's a strategy that creates a space for every disposition.

But the price is that for any given disposition, you're actively asking questions about where

are those boundaries for you and where should they be for people in the company and new

people are coming into the company.

So I think at least from my perspective and the things I'm interested in, like I like

types, I like no side effects.

It's like my preferences can't really be well represented in the like super, you know, choose

your own adventure way of interacting with a language.

So I do think that's like, I mean, could a language exist someday that was statically

typed and had managed effects?

I mean, I imagine if like Facebook or Microsoft, I mean, Microsoft tried with F sharp, but

well in which F sharp you can interact with object oriented and imperative code.

And you know, like it's more additive than like creating a sound sandbox where all the

types are sound and you don't have, you know, side effects and that sort of thing.

I mean, that's a bold position for a language and which is what we love about it.

But then in terms of making a popular choice, like TypeScript is the perfect formula for

a super popular growth trajectory because you're like, Hey, take this thing, you know,

change the extension to dot TS or actually you don't even have to do that.

And now it's TypeScript and you've got better intelligence and people are like, Whoa, that's

cool.

Which it is.

TypeScript is brilliantly designed for its goals.

And interestingly, I saw this talk from Bjarne Stroustrup, I think I'm saying right, who

did C plus plus in the eighties and he was saying like every C program was a C plus plus

program like, and you know, that's a massively successful language if you're, if what you

consider success is market share and growth, right?

And so it's, it's just like, it's a winner of a strategy for those kinds of goals.

And so I think that's one of the things that's like when people come in with, you know, everyone,

when they're sort of new to programming languages, they have an idea of what languages should

be.

And so when they come and they see a language that's not doing those kinds of things, it's

like, what are you doing?

You're totally blowing it over here.

It's obvious this would work better.

And so I think that's one of the interesting things I've noticed as I've like learned more

languages and talk to more language designers is like, once you know what their goals are,

the languages always make more sense.

And it's like, so I have come to this place where it's like, I want to have respect for

every language.

And if they want to do it, you know, I have my own opinions, but like, Hey, people have

their opinions about what my stuff too.

And it's like, it's going to find its audience or it's not, or it's going to fulfill the

goals of that person or it's not.

So I don't know.

So my, my exciting one was like when I became a PHP defender, I was like, you know, people

are really not appreciating how easy it was to build what you wanted, you know, and it's

like, you can make all these language criticisms and that's fine and true, but like you can't

in getting caught up in that.

It's like, essentially, I think it's a mistake as a language designer to let your personal

preferences blind you to what people find exciting in other languages, right?

Like it was a, it's a cool lesson to look at PHP and see the power of ease of getting

started.

Right.

Right.

Are you not blinded by your love for static types?

I don't think so.

I mean, like, I look at like Julia, like if you say, Hey, we're going to do a language

for scientific computing.

I would say, all right, one of the key issues is like, we want addition to work nicely with

floats and in on all these different platforms.

And we're, we have scientists who say, Hey, I care about whether not about, you know,

Turing, what Turing had to say about anything.

So like, and you look at the history of that thing.

So it's like, I look at it and I say, is there a way to do like matrix math in a type functional

way that's like really feels amazing.

And it's like, I don't know, I don't know.

So I think when you look at the different domains and you see the choices they make,

it's like the way that I find like valuable and enlightening is to see what everyone else

is seeing in it, you know, cause it's the same with like, I can appreciate a lisp, you

know, and it's all the things that people say about it.

Like it's so, it's so concise and you have this beautiful syntax that's rebindable in

these cool ways.

And it's like, I see that.

It's not my preference, but I can enjoy as like an aesthetic point in the design space

that coheres.

Does that make sense?

I don't know.

I think it makes sense.

Like any, any language or tool or whatever it might be should have a, there's no right

or wrong answer, but there are compelling stories or not so compelling stories and a

compelling story could look completely different than a different compelling story.

They could both be compelling.

I honestly, now that I think of it, I have the most trouble with languages that are really

focused on lots of ways to say something.

I know people really love that.

It's hard for me to like fully step into those shoes in the way that I can sort of step into

the mind of like someone who just wants to do their weather simulation or run their like

employment statistics graph.

But yeah, I mean, same like with the dependently type stuff, like those languages are really

cool.

I personally struggle with them sometimes, but like I can see the beauty there.

So I don't know.

Yeah.

We went to a bit off of funding there.

I mean, that was a great, that was a really good conversation.

Maybe we can change gears.

Maybe this will be our last topic unless there's anything else you want to cover, Evan.

So I know that, you know, Yaron and I, as people who are very passionate about tooling

are very interested in sort of the Elm tooling ecosystem and you know, I think you made a

point about this in a talk, Evan, that like use Elm to do cool things.

Like Elm is this language that has these design features that make for really interesting

use with tooling.

Yeah, for sure.

So like maybe let's talk a little bit about like the tooling landscape and how Elm fits

into that and what's going on in the ecosystem.

For example, you know, we've got some really cool stuff in the IntelliJ plugin for Elm

now.

We've got the Elm language server doing a lot, you know, adding a lot of features.

We've got, you know, Yaron is doing a lot of cool stuff with Elm review these days with

static analysis.

With great tweets as well.

Great work on that.

Yours are better apparently.

No, no, no.

It's like you know the tricks, right?

You got to get that GIF, you know, immediate comprehension.

His marketing team is on top of it.

There's a lot of like cool stuff going on there and like I'm sure the people who are

working on those tools appreciate the like joy of having a typed language without side

effects.

I certainly do.

Yeah.

So like, like no, no question here.

Yes.

And I think like as a compiler person, it's like I very deeply know like the price of

some something that looks little in terms of like all the optimizations you can never

do because of it.

So yeah, so I think it's been really interesting to see that develop and especially in cases

where like I think a while back we had this question of like, well, the compiler has this

information like can the compiler expose it?

And my challenge was like, I don't, I'm not a IDE person.

I don't necessarily know what people are looking for and what they want from that.

So like I couldn't, I just didn't have an intuition of what, how that would work.

And like, you know, I have questions like I want your CI compile times to be as fast

as possible.

How does that match with the goals of an IDE that wants type information in this or that

location?

So I think there was a point, I don't know what happened, but people sort of decided

like we're going to pursue this in the like editor tooling space and have been making

really cool progress with type inference and the features that can come from that stuff.

And you know, I think I ha it sounds like I have bad intuitions for ID stuff basically,

because I'm like, why do we need to keep anything in Ram?

Why can't we, you know, and I think for like for compiler stuff, it makes sense to view

it that way.

Cause it's like, well, I need to save everything to disk between runs no matter what.

So if like, if I can make that so fast that it's not an issue to get things under your

cursor, Hey, that's cool.

But maybe that causes all sorts of problems that I don't appreciate.

And so I think over time we sort of found that like that's something that I don't know

how to do and they do.

And I think that in general has been a cool way for things to work.

So like, I know there's little explorations of like, what would it look like to run Elm

on what's it called?

Electron.

Um, and it creates all these questions of like, well, you need to write to files, but

files don't work in browsers.

And so in the package ecosystem, you'd have to have a way to market, not just as an application,

but as like a browser application versus electron application.

So before you even start on the project, you're, you're asking these really intense design

questions that would have an impact on every person using Elm in the whole ecosystem.

And so with those kinds of things, it's sort of, in some ways it makes sense to say, Hey,

like try and experiment, call it pine and run it as like a super set that has this.

And then once that's like born out in reality, then talk about how to bring it back in and,

and in doing, in doing that project, you can start to build a relationship with the people

who you'd need to coordinate at some point in the future and say, Hey, you know, like

people can see your work, they know what your, what your style is in terms of what you're

doing.

So what, instead of having that discussion on day one, you have it much later on.

And at that point, you yourself might find, Hey, I don't, I do want this to be a separate

thing.

So that, that, like that kind of mirrors my own story with Elm where I wanted typed functional

programming in the browser.

And I was like, well, should I make a Haskell compiler?

Should I make a OCaml compiler?

Yeah.

And as I thought about the problems and what my goals are and what was interesting to me,

I ultimately was like, well, I do want to make a separate thing, you know, like, and,

and it'd be so hard to meet the needs of everyone in Haskell and what I'm looking for and the

people who I'm interested in having some sort of interaction with through this work.

I have to admit it's a bit embarrassing to think back on this now, but I built a project

called Elm TypeScript Interop a few years back.

And you know, I mean, it's, you know, it's a handy project.

You know, you point it at your Elm code base and it statically analyzes all the ports and

it generates a TypeScript declaration file that gives you IntelliSense and types around

registering your Elm ports, you know?

And I remember thinking like, wow, like that the goal was like, wow, this would be cool

if this was integrated into the compiler.

And fortunately I never, I never suggested that or, or requested that.

But in retrospect, I'm really glad that I just went off and I was building it as an

independent thing and got to the point where I realized that wasn't actually my goal before

going forward with that.

Because in retrospect, it, it, well, it was an experiment that actually now I'm deprecating

in favor of a new library that I'm building for, for typed, interrupt with TypeScript that

I think is like a far better approach, which hopefully will be announced by the time people

hear this episode.

Normally this, this, that would have been the previous episode.

Yes, that's right.

Our previous episode, hopefully we'll, if you listen to our last episode, you'll know

what I'm talking about.

Yeah.

But my point being that that worked really well to really have an experiment that, I

mean, I didn't have to get permission for that experiment.

I, I just, I built it, people used it.

Some people thought it was useful.

Some people thought it didn't quite work for their project.

And then I later realized that there, there's a way that I think is far better to, to accomplish

that goal.

And fortunately it wasn't built into the Elm compiler output that it also gives you a TypeScript

declaration file, which at the time I thought would have been a good idea, but seems silly

in retrospect.

Yeah.

I think one of the things that's been like a challenge for me conceptually is like, I

want everything to fit together just right.

And so I think that like suggests that integration is the optimal path in more cases than it

necessarily is.

It seems like that's something that like, especially in tooling, we're starting to like

be aware of the like, Oh, like I'm glad this is separate.

Right.

It's like that, you know, you don't have to worry about 19.2 verse 0 20 and like what

that means to, and it's like, look, I just want to do this patch.

Like it's not so serious.

So yeah, I think that's something that like we're, we're learning more about like collectively

how that balances and fits together.

Yeah.

Yeah.

And it is really interesting, like the fault tolerant parsing and hyper fast parsing are

two different goals between the Elm compiler and you know, the Elm language server and

all the tooling.

I do see for sure that there is like a lot of reinventing the wheel happening when I

see people like Yerun and Kolya and Keith and all these people like, and Aaron Vonderhaar

with Elm format, like figuring out compilers and getting this stuff, but that doesn't necessarily

mean that Elm needs to do it.

But I know that I believe Aaron Vonderhaar is working on some format that gives you a

JSON format of the Elm syntax tree, which is another great example of sort of, you know,

like filling in the gaps in the community in a way where we can rapidly iterate and

figure things out without being blocked on core features.

But I do think that like there's, there definitely seems to be a need to create some shared things

in the tooling ecosystem to prevent reinventing the wheel.

But I think that's happening in that group of like people who are passionate about tooling,

like, you know, Yerun and Aaron Vonderhaar and these people.

Yeah, which isn't to say like, I want to not be a part of it.

It's just like, I don't, I'm like, it's always interesting to like sit in the meeting, but

not like I can't lead them usually.

Yeah.

Like with, cause it's like, I'll have a little insights about, you know, oh, like laying

out your binary files in this way is going to be slow for this particular kind of user

who lays out their pack, like their files in this way.

As I know that, but like, I don't have the feeling of what the features need to be.

Totally, totally.

For instance, like you don't know much about WebGL, so you can't lead it, but you can help

people who are actively working on it.

You can sit in the same room and follow.

Yeah.

So that's something I'm very excited to see what happens there as a person sitting in

and some of it borders on compiler stuff, like with, you know, it's a, it's a shaders.

It's like, wouldn't it be cool if they type checked as well as, it would be very cool,

you know, and that's something that's like, oh, you're telling me I can write a type checker,

but for a different language that works in a cool different way.

So you know, I have to restrain myself with some of them where I do have enough overlap,

but yeah, but some it's like, if you want like rendering to a texture and then using

the texture back in another, you know, I don't know.

I don't know how to, I made a cube, you know, there's limits to what I know.

Well this has been an amazing conversation.

I've enjoyed it a lot.

Yeah.

Thank you for saying this.

Thank you so much for coming on and chatting with us, Evan.

We really appreciate it.

Are there any sort of closing thoughts on, I mean, so, so we, we kind of talked a lot

about the role that the community can play in sort of furthering Elm without needing

to wait for anybody.

So like, do you have any, any thoughts on, on what you think people could do to pitch

in and further the Elm community in some way?

Yeah, sure.

I'm, I'm always hesitant to suggest people do stuff because I can, I know, I can, I know

it can have a personal price.

So I want to be upfront about that.

But if you know that and you say, okay, I think like pursuing the thing that you're

really passionate about is just the path is like to be able to sustain these kinds of

projects on weekends and evenings.

It's like, you have to, you have to care.

And so like, if you're deeply excited about like sharing how fun it is for you, it's like,

is there a way you can share some demos, right?

Like tweet, like tweeting about demos and doing a video of it can be really cool and

inspiring for people or like demo applications.

Or if you're, you have a consulting firm and you want more of your clients to be using

Elm.

My personal feeling is like, if your client doesn't want to use it, then like just end

it there.

Like just don't do it.

Like, I, like, I don't know.

I mean, maybe that would be my approach, but if you're working on making a case so that

more of your particular clients are interested, like I think a really cool thing that I would

love to see is like, here's the expenses we have on our react projects and here's the

expenses we have on Elm projects.

And this is the time we spend on bug fixes.

And this is the time we spend on, you know, after the project is over revisiting for subsequent

fix up.

So you can like put it in dollar amounts that a client could really say, Oh, like, I don't

know what Hinley Milner type inferences, but like, I would like to the lower price.

Yeah.

Right.

And even just sharing like case studies and success stories can be compelling for people

to see.

And then from a technical perspective, like, I mean, two of the talks, I was going to do

these two talks at Elm Japan and Oslo Elm Day.

One was about data visualization.

Like the talk was going to be called Elm for science.

So it's like, I know if there's someone out there who's like loves statistics or loves

data visualization or loves communicating in a visual way, they can do something really

special with data visualization.

And I looked into that project for a decent amount of time and ultimately kept hitting

this barrier.

They're like, I don't love statistics.

I tolerate statistics.

And that was like a fundamental barrier for like the level of passion I'd need to sustain

that kind of project and be the person making decisions.

Like if someone comes to me and say, Hey, I need this diagram for my like, you know,

genome protein production analysis.

It's like, I need to be able to have a conversation with that person about key values or whatever.

You know, obviously I don't know this stuff.

So like finding those passions and finding that niche where the things you're excited

about match the things that you are good at or the things you want to be good at and the

things you want to be pursuing in your free time.

So that'd be kind of my advice there.

And like, you know, know that the people who are doing it are doing because they want to

do it, you know, like so.

Right.

Right.

Yeah.

And I think it's, it feels really nice when people go a little bit out of their way to

show a little appreciation when they're reporting something that could be improved.

Yeah.

So, but yeah, hopefully that's somewhat helpful.

That's great, great stuff.

And it was a, it was a pleasure just having you on the show and catching up with you.

So thank you so much for coming on.

Yeah.

Thank you so much for organizing everything.

Our pleasure.

And yeah.

All right.

Well, until next time you're in, talk to you later.

Until next time.