What's Working for Elm

What's Working for Elm

We look at what we can learn by understanding what's working well for Elm and the Elm ecosystem.

PublishedJanuary 3, 2022

Episode#47

Woody Zuill on Turn Up the Good
Mob Programming

Where Could We Turn Up the Good?

Pure FP

Elm 0.19 removing side effects
Purity is what makes elm-review interesting
Jeroen's post Safe dead code removal in a pure functional language
No runtime exceptions

Useful Error Messages

Useful error messages

Evan's 2017 Deconstructconf talk Evan Czaplicki On Storytelling
Evan's talk What is Success?

Having a single language flavor

Isomorphic code
Meta frameworks (elm-pages, Lamdera, elm-spa)

Decoupled tools

The community can iterate quickly and experiment with new changes
elm-optimize-level-2 and elm-format are great examples
elm-optimize-level-2 can make their way upstream and don't break Elm's guarantees or assumptions
Robin Hansen's blog post series Successes, and failures, in optimizing Elm’s runtime performance
Extensible Web Manifesto
Platform should provide building blocks, not solve every specific use case

Stable Core

Stable data layer, architecture allows ecosystem to evolve around it with less churn

Community Members Working on What They're Passionate About

People passionate about a problem working on it in the ecosystem

Performance

Leveraging Elm's unique characteristics for performance (immutability, static language, known types, etc.)
Elm compiler performance - compiler speed matters

Content and Conferences

Elm community content and conferences
Elm Online meetdown

The Elm Philosophy

Evan's Elm philosophy tweet
Philosophy has influenced package design in the ecosystem
Elm Slack #api-design channel

Transcript

So today, I wanted to talk about something a little bit different, talk about something

maybe like a little bit of a different format than usual.

So there's a concept that I'm very fond of.

It's this idea of turn up the good.

I think the idea is originally from Kent Beck and his XP book and Woody Zool has taken this

idea and really leaned into it quite a bit.

So the idea of turn up the good is if you imagine you've got a bunch of knobs and they're

the things that are sort of working well in an organization, in the way you build software,

in the tooling around software, in the language, you turn all those knobs up and you turn them

up to 11 and you see what happens.

That's turn up the good.

I think I've seen you talk about that when talking about incremental steps.

Yeah, to me, it's really baked into my mindset.

You sort of over time build up these pillars that form your thinking about a topic.

And yeah, to me, it's just inseparable from how I think about writing software and changing

process over time, whether it's personal process, organizational process, whatever it might

Like an interesting story, Woody Zool who worked on this team where they sort of came

up with this idea of mob or ensemble programming, which is like pair programming, but with more

people and it's a really interesting technique.

But the basic idea is the team that sort of came up with this mode of working said that

we didn't really come up with mob programming because we were looking for something like

We came up with it because we were paying attention to what worked and we were turning

it up, turning up the good.

So they thought that pair programming was working well for them.

So they added more people and then more people.

The entire team.

And also they noticed what was working.

So they noticed that when they would sit down and try to solve a problem, they would sit

down and they'd sort of have a meeting and they'd say, all right, we really need to solve

And everybody would sit down in a room together and they'd hash it out and they were like,

huh, that worked well.

Well, what if we did more of that?

Like what if that one part that seemed to work really well where we all kind of sat

down and figured it out, what if we just did that a little bit more and a little bit more?

And now all they're doing is meetings.

Well, that sounds wrong when I resume it that way.

Well, I think they would distinguish, they would say that meetings is when you talk about

doing work and collaborating is when you do work.

So in fact, they would say that they do no meetings because they never talk about doing

They're just constantly working together and they have context on everything.

So now the point being for our conversation today, because we could talk a lot about mob

programming, it's a very interesting topic.

But the thing that was really interesting in that story is that they weren't looking

at everything that was happening and saying, all right, let's solve these problems.

We've got this problem, we've got that problem.

What are we going to do about those problems?

Instead they were saying what's working and how do we do more of that?

And then suddenly all these problems start to go away because they're making the good

I think now I'm not saying that you can solve every problem by turning up the good.

I'm not saying that you can't solve problems by thinking about what problems are and trying

to fix those problems.

And they're both valuable, but that's what I want to focus on today is looking at what

is working for Elm and the Elm community and thinking about what would it look like to

do more of those things.

That sounds good.

What is working well for Elm?

What do we need to turn up to 11 or what has already turned to 11?

Really, I think there are so many things.

So where to start?

Well, I mean, first of all, I think I can't think about this question without immediately

thinking about the core of Elm, which to me is pure functional programming.

And I mean, we don't like to do too much jargon, but we all sort of know what we're talking

So this is like maybe the simplest way to communicate this thing that we all know and

love, which is not having to think about where side effects are coming from or mutations

or global state and environment and things like that.

And you put a value in, you get a value out.

And really there are a few languages that exist in production contexts that have this

It's very unique.

And it is, in my opinion, it is really working and we should double down on that.

And in fact, Elm 19 did double down on that.

Some people weren't happy about that, but I honestly, I think that's working for Elm.

And I think that you can't imagine if a package could do side effects, Elm review would become

much less interesting.

I was thinking about that.

I made a post about removing dead code in a very safe manner.

And suddenly assumes that nothing has side effects except performance issues maybe.

And if there is anything that can create side effects or can have an impact outside of what

is just returning a value, then all of the promises that Elm review unused gives you,

which I've turned to 11 in a way, it's just entirely destroyed.

So I'm very happy that Elm went the way it did.

I think you would agree that if I can make a bold statement that the most interesting

thing about Elm review is Elm.

The most interesting thing about it is like if you were to take the concepts from Elm

review and try to do it in any other language, suddenly the most important thing about it

wouldn't be there anymore and it would no longer be interesting or important.

I mean, Elm review is just supportive of what I did with ESLint with some ideas changed

and the experience for me as an author and as a user are vastly different and in the

And the ability to create high quality rules and high quality fixes from community members

is just night and day.

When you look at how easy it is to write a reliable fix and do reliable static analysis

by writing your own Elm review rule compared to writing an ESLint rule.

I mean, how many like, I don't know, from your experience, like using ESLint rules,

is it common to find unreliable rules and fixes?

Maybe they're just less ambitious.

They can be unreliable.

The fixes not so much.

Let me rephrase that.

So yes, I have heard of a few rules that created changes in behavior because they didn't know

JavaScript well enough and in some cases it was really hard to predict.

The language is so big that it's a bit hard to know what the effect is of a change.

But also one of the most common cases of issues was the fact that the rules crashed the ESLint

because they were written in JavaScript and JavaScript crashes.

So that is, I think, the most common thing where you expect the AST to have a property

to be always there.

For instance, if you have a try catch in JavaScript, you always expect there to be a catch, for

I'm not even sure if that's the case anymore, but I remember myself learning about some

optional syntax or syntax that was actually optional, which I thought was required.

And I don't remember if it was a try catch example or another one, but something similar

There's always a catch.

There's always a catch, except...

With very exceptions, there's always a catch.

But at least you got to try and write those rules, right?

Finally, finally.

Oh, man, that was bad.

No, that was good.

We should stick to elm puns maybe, but it's just so much easier with JavaScript.

So many more keywords.

Now, that brings up another point of something that I think is pretty clearly working for

elm, which is no exceptions, asterisk, right?

Of course, unless we're solving the halting problem, we're not going to have no exceptions

because you can always do an infinite recursion.

And in some cases, it will be infinite.

And in some cases, it will crash the stack.

It could be a conceptually infinite recursion, which in practice is going to mean a finite

recursion that's just going to crash the stack.

Which one is better depends on your use case, I guess.

I think someone crashed the stack there in your background.

Too many parties over here.

So this no exception thing is really working.

And of course, there are cases that can make exceptions.

And I think this is something to double down on as well.

I know that this comparing two functions with double equals is one thing that can currently

crash the runtime, which I know that Evan is thinking about ways to solve that problem

through the type system potentially.

So that's another thing to potentially double down on that's working for Elm.

Also the error messages.

I mean, that is one of Elm's biggest features is that the error messages are so nice.

And ever since they were introduced in 2015, I think, they have been improved and improved

There are still some cases where they can be improved.

But oh, my God, there's just so good.

I mean, it's pretty clear that that's been wildly successful.

Just if you trace the influence to other tools and communities and how it's had an effect

So I guess Elm does have side effects.

Elm does have side effects.

Were they intentional or not?

So I think this is another interesting point about the sort of meta process of Elm.

I think Evan has talked about how the error messages were not, first of all, it wasn't

something people were complaining about.

People weren't like, hey, these error messages suck.

People didn't have a problem with them.

And it was something that Evan started exploring.

And I think that this is something that, I mean, people complain about this.

But this is how Evan works and brilliant things come from that way of working.

And I'll take them.

I will take these brilliant ideas that emerge from this process of exploring.

Exploring things that aren't necessarily the obvious path of things that people are actively

complaining about.

I mean, no one was complaining about the error messages because they are bad in pretty much

every other language, right?

I don't know any languages that have good error messages apart from Elm and languages

that have been inspired by Elm, like Rust.

It's like if you ask people what they want, they'd say they want a faster horse kind of

But sometimes the faster horse doesn't bring you closer to your goal, right?

I think that many of the most beloved parts of Elm have come from that process.

And I don't know, I just want to, I guess, take a moment to recognize that.

At least that's my personal feeling because I think that sometimes we can get caught up

in saying how we think things should work and we forget to say what successes have come

from the approach.

And a lot of great things have come from Evan's approach of really, and he's given some really

great talks about this topic.

He gave a really good talk, I was there in person at Deconstruct Conf, he was talking

about this approach and he's given a few other talks about the meta process of batching things

and looking at the bigger picture, doing an exploratory approach where he's not necessarily

doing the obvious things, but he's sort of thinking.

You know, Richard often talks about let's do the ambitious approach.

And I mean, Elm is a bold language.

It's a bold concept to do something with pure functional paradigms.

And yeah, and we sort of get stuck with this like, okay, well, here we are now, but we

forget how we got there, you know?

And we got there through these like bold explorations.

I haven't followed Elm's evolution because I was kind of late to the game.

I think I was there for when 0.16 was there.

And then I had a moment where I wasn't there and I started when 0.19 was released.

So I didn't go through the early stages.

But I really like how Elm turned out to be with the great error messages, the promises

of no runtime errors, which is almost true, but true enough that I have never seen it

crash in practice, which is something.

And also the way that every tool is designed, every building block of Elm is designed where

tooling can have so much information about how the program works and what it needs, what

the dependencies are that makes a tooling author's job so much easier.

I mean, when I was working with the ESLint, I had very little information about what the

code I was looking at was doing.

There were values, there were function calls, that's it.

And every file you were looking at was split on its own.

You couldn't see what was happening in one file and correlate it with what is happening

in another file and find issues when combining the information from both.

But the Elm language makes that so easy, gives you the information about what is in your

dependencies, gives you access to the dependencies source code, if you want to look at that, has

an explicit import system, has an explicit Elm JSON file with all the dependencies and

And that makes things a lot easier.

And also the fact that there are no flavors of Elm, no different flavors, only a single

flavor, makes it really easy to support everything.

Are you talking about JSX versus TSX versus some custom Babel language extension?

Yeah, or even just different versions of Elm or of the language of JavaScript, of ECMAScript.

Like a Node.js runtime versus Dino versus...

I mean, I've worked on the Node slash NPM ecosystem for a few years and making all those

tools work together, making every tool support, every new flavor of JavaScript, it's a pain.

I mean, all of them are amazing, really.

All these tools, they're really good.

But to make them work together, that is just very hard for both tooling authors and for

And it's just because there are so many flavors that you need to support and so many people

you need to please, users you need to please, that it's really hard to do the right thing.

Yeah, I totally agree.

I think Dino is actually trying to solve this problem to a certain extent where they're

saying like, listen, we've got this fetch thing in the browser and then we've got this

other way of making requests in this sort of server side code and it's really hard to

do code sharing and we have to sort of check for different environments and let's just

double down on using standards.

So Dino is trying to use web standards.

So they're trying to implement as many of these APIs following web standards as possible

to sort of try to tackle this problem.

When it comes to Elm, like when I'm working on Elm pages, similar to what we were saying

about Elm review where the most interesting thing about Elm review is Elm, I see it the

same way with Elm pages.

To me, the most interesting thing about Elm pages is Elm.

It's not the pages and it's trying to bring out these uniquely interesting qualities in

For example, I'm trying to remember the word that's used.

It's not idempotence.

This idea of having something running in different environments the same way, you can have issues

where if you run it in Node or if you run it in the browser, there are different APIs

So if you try to call fetch in some backend code, then you have to patch it to make sure

you expose an equivalent API.

So these sort of frameworks like Next.js and this sort of thing have this issue where people

will install an NPM package.

They'll try to run something.

It depends on the FS package to do file system stuff.

And that doesn't exist in the front end, but you've installed some NPM package and it tries

calling that and it crashes.

Because it's not a package, it is module.

The core modules from Node, yes.

It's a core, exactly.

It's just one that just exists in Node and then Webpack 4 would automatically patch those

to use these stubs for things like FS.

So you could depend on the FS module and other built in Node modules.

Through ponyfills and ponyfills.

And I mean, it's really, you can imagine like one build tool like Webpack, like you said,

they're doing extremely complex, impressive things.

The fact that there's so much complexity is going to cause a lot of pain and a lot of,

you know, you use one tool, it works.

You use another tool, it doesn't work.

You go from Webpack 4 to Webpack 5 where they stopped doing those polyfills or those stubs

Suddenly all these things start to break.

You go from required to ESM and all these things start to break.

So there are all these things that are so easy because of this, just everything is just

pure functions and types in Elm.

And so with Elm pages, if you're running certain things that are running actually in a Node

environment on like server side code at the build step, it doesn't matter.

You just write Elm code and you don't have to worry about was this Elm code that was

targeting Node JS or was this Elm code that was targeting the browser.

Like with Elm pages, there's this idea of a data source and you know, just like a command,

like you can create a command somewhere, but it's not going to do anything unless you return

it to a place that's expecting a command, namely the init and update functions.

And similarly in Elm pages, there's this data source type.

And if you give that to the right place in Elm pages to, you know, to a page module,

then it can do something with that.

But those types enforce those constraints.

So you don't just like, and that's just Elm working, this Elm pure function thing where

like things don't just perform side effects, they're data.

And you can build these meta platforms around that idea, but you can't unwind it from this

totally open arena of JavaScript where side effects can come from anywhere.

You can't then put constraints on that and start getting these guarantees and predictability

that you get in Elm.

So that's working.

In a way you can see Elm pages as a flavor of Elm, of regular Elm code.

But even with that in mind, but even if you see things that way, for instance Elm review

doesn't have any specific logic to work with Elm pages.

So Elm pages is just another regular Elm project from this tools point of view and same thing

for IDs and for Elm formats.

So because you have just built upon the standards of the language and extended it in a way that

is not, that does not break anything, any assumption that tooling might have, there's

no additional work tools have to do, which I think is not the case in the JavaScript

ecosystem where new tools create new assumptions, new problems actually to solve.

There is actually one other flavor of Elm which we have talked about on the show and

that is LameDera.

And I do support that with Elm review.

The only thing that I had to do was to have the Elm review unused package, know that there's

a specific main function, which is called app.

I think that was about it.

So it really wasn't much effort to support it.

That's the way I like it.

Yeah, yeah, absolutely.

Once you open up the Pandora's box of side effects anywhere, eval, dynamically creating

options, things like that, you can't close it.

But if you keep that box closed, there's a lot you can do with that.

I mean, it's very attractive to have all those things because it would make Elm much more

But by doing that, you would turn the knob from 11 to 9, 8, 3, I don't know.

Anything that you would have gained from that would be lost, most things at least.

I think Richard Thelman described it this way.

If you have a bucket of water and you put one drop of urine in it, then you have a bucket

of watery piss or urine water.

You get the point.

Yeah, I mean, a 99% guarantee is not really a guarantee.

You can take pure functions and decide to perform side effects from specific parts of

those pure functions, which is exactly what Elm is.

That's what managed effects are.

You return something from update and then you do something.

But everything else is still pure functions.

But you can add more things like that, which is essentially what Elm pages and Elm review

They take certain points.

You return a data source in a specific place and it can say, oh, okay, I'm going to go

read some files and I'm going to go do a glob and find all the matching files and return

I'm going to do a glob watcher and every time the files change, I'm going to do a live reload

in your dev server.

Similarly, like Elm review, you do these things and it's going to run a fix and modify this

part of the code and run Elm format on it.

Those aren't pure things, but you do it by returning a specific data type in this specific

So you can always add effects from pure functions, but you can't take away, you know, you can't

add purity to a completely dynamic environment.

You can't put the Pandora's box back and you can never close it.

To kind of step back from the purity and everything, I think a bigger point we're getting at here

is that another thing that's really working for Elm and the Elm ecosystem is there's this

purity which now we're seeing all these meta frameworks emerging that are building on top

To me, this is something that's really working like Elm SPA, Lamdera.

I find these tools very exciting and I would love to see us doubling down on this in the

I think that they're hugely valuable.

And I think these things that leverage these benefits we're talking about that come from

Elm, being able to run it in multiple environments and not worry about implicit things that we're

depending on, like depending on the file system modules in Node and things like that.

Those things just aren't problems in Elm and there are so many ways you can take advantage

of those by building these sort of meta frameworks around Elm.

So I'm excited to see what emerges next.

I would love to see us doubling down on that.

So another thing that I think is really working for Elm and the Elm ecosystem is, you know,

we've talked about this before, but Elm Optimize Level 2.

To me this approach is very sustainable of essentially having these experiments that

we can iterate on quickly and we don't need any changes to Elm and the Elm compiler's

output or anything like that.

We don't need to ask Evan to change his process, which we've talked about, you know, batching,

doing explorations, exploring bold changes, all these things that really have brought

a lot of the things that we most love about Elm.

We don't have to ask him to stop doing that to go and work on these optimizations for

performance to the compiler output because, you know, Matt came up with this idea of,

hey, let's have a post processing step to apply these optimizations to the compiler

And he created a platform where anybody can go and plug into that and benchmark it and

iterate on it quickly.

And we're seeing a lot of people do that.

We're seeing you adding some pull requests there.

And Robin and all these people can pitch in there and it doesn't require us to get in

a change to the Elm compiler.

So to me, that is really working and I'd love to turn that up to 11.

Yeah, also something that is very cool with that project is that from what I can see,

everyone is of the same mind in that we're trying to find optimizations that can apply

to all Elm code and not using it as a way to have native modules again.

Which it totally could, which you could totally do in your own project just by manipulating

the compiler JavaScript code.

But everyone that works on this project, as far as I can see, is of the mind, we're trying

some things and if they work out, we want to backport them to the compiler or make it

possible for the compiler to backport them, to use them.

That's a great point.

This is sort of like a philosophical idea that you make these changes in a way that's

not breaking the guarantees about Elm.

It's like esbuild versus Babel in a way I think encapsulates this idea that Babel, I

think, went perhaps a little bit overboard in these custom extensions.

Because if you're doing custom language extensions, then you can't fit together one project's

custom language extensions with another because it doesn't work.

The syntax highlighting tooling and the ESLint rules and all these things suddenly don't

know what to do with something.

I remember for instance that a lot of people used Babel or Webpack to add a way to change

their imports to other modules.

Like instead of doing required open string dot dot slash dot dot slash dot dot my file

dot JS, they wanted to do my file dot JS on its own, which is not standard, which usually

means this is a module or this is the name of a package and maybe a file inside of the

And a lot of tools would have to support that.

And I remember that that was a pain.

For instance, I worked on ESLint.

For instance, I worked on ESLint plugin import.

And well, obviously we needed to support multiple ways of importing things because people added

custom things and mostly because they thought that having all those dot dots were a bit

ugly or were painful for maintenance, but it was more painful for tooling authors, arguably,

from my point of view.

And now Babel needs to support that.

And now IDEs need to support that.

And if you're doing something custom, well, maybe you do it in a slightly different way

than another project, than another tool, and that makes things just painful.

And this is not a JavaScript language design thing.

This is a sort of an ecosystem philosophy thing.

And so yeah, sorry if I bash JavaScript too much.

I'm just pointing out that people could do this in Elm, but they're not.

And I hope that continues to be the case because I think that's working.

I think that in the Elm world, we really value explicitness, predictability, sort of having

one way to do it, having simple ways to express things and not going and having these custom

language extensions and things like that because it becomes unsustainable and it really breaks

all these things in the ecosystem.

So I mean, if Elm review started having to handle custom syntax extensions or custom

semantics and things, that would really start to break a lot of assumptions in tooling.

So anyway, esbuild has more of this philosophy of, in contrast to Babel's ability to write

these custom plugins, esbuild is starting to rein that in and say, hmm, let's not have

it be customizable.

Let's only support sort of future syntax.

So I can transpile es2022, 2023 stuff into es2015 syntax, but it's standard syntax that

everybody can sort of get behind these same standards.

So I like that philosophy and I'm glad we're seeing more of that in Elm.

And so yeah, back to that point about Elm optimize level two, like you were saying,

it can go back upstream.

So we can do all these experiments, we can iterate and find the best way to tune in that

performance of the JavaScript output of the Elm compiler.

And then once that's really matured and stabilized and we've found, you know, Robin did a great

series of posts about some experiments he's been doing there.

Those experiments don't need to happen in the Elm compiler itself.

They can happen in this external thing with very rapid iteration.

And then once we've sort of sorted that out and it's matured and stabilized, then they

can make their way back into the Elm compiler.

So to me, that's really working and I would love to see more things taking that approach.

And I think that having these external tools that don't make, you know, changes to the

Elm compiler bottleneck is something that really works for Elm.

For example, from the early days, Elm format has been that way.

It's been an independently managed tool.

And I think, you know, Evan has done a really great job of, you know, sort of giving his

insights to tooling authors, connecting with them and, you know, he'll do calls with people

and share his thoughts and give ideas.

And he's got a really great vision to sort of help people think through these things.

So I think that really works.

And I think that's a recipe for success in the Elm community.

So I'd love to see more of that.

So being disconnected from the compiler outputs, right?

Decoupled architectures.

If we go back to the JavaScript ecosystem again, that's also very true in the sense

that most open source projects over there, they don't rely on the browser, what features

the browser supports or how it works.

Nobody creates a tool like Webpack and expects the Chrome team to implement a new feature.

They expect them to support the standards, the web standards, but that's it.

I've sort of, I've shared my thoughts quite a bit on this topic, but I think it's relevant

here too about the Extensible Web Manifesto and this idea that, you know, these sort of

browser standards teams learned this lesson from shipping this app cache API that was

trying too hard to solve every problem and be custom tailored for specific use cases.

And then they realized, you know what?

We're failing to solve every use case, but we're not going to be able to solve every

use case as the platform team.

And in fact, that's not what a platform should be doing.

A platform should be providing robust building blocks that people can use to solve their

So people shouldn't be stuck in a dead end where they can't solve their problem for their

use case because the platform doesn't provide the right building blocks.

And those building blocks should be robust and work well and should consider the core

security concerns and the core problems that could occur.

For example, an app cache getting into a state where you can never bust the cache and users

are stuck seeing the same page.

That should never be able to happen.

That sounds lovely.

The platform should have those guarantees baked in.

And then the application code can take those building blocks and safely build things with

So I see that as a really great like philosophy.

And I think that I see that as a recipe for success that the platform shouldn't be trying

to solve every single use case.

They should be providing simple, powerful, robust building blocks.

So I think Elm should stay focused on that as well.

I mean, Elm doesn't give you the building blocks for everything when it comes to web

But it at least gives you the escape hatch that you need to use those building blocks.

So ports and web components.

Yeah, I think web components are probably underused.

Like I'd like to see more of that.

And I'd like to see more like people encapsulating shareable web components that can be used

nicely in Elm code.

For example, like web components can have custom events that they can emit.

And we could see sort of shareable like web component definitions and Elm handlers for

decoding those custom events that they emit, for example, right?

I would love to see us kind of doubling down on that.

So another thing I think that's really like working for Elm is Elm has this architecture,

the Elm architecture.

This is how Elm works.

And like in the React ecosystem, there seems to be so much churn around these different

like data layers, which has its pros and cons.

But I think a lot of people find it very frustrating that they're like, okay, now, Redux is the

And then suddenly everybody's like, now we're done with Redux.

That's not the way to do it anymore.

And then everything is using hooks and everything is going to these different React query or

different data layers.

Even when you use Redux, you have the choice to use Redux Thunk, Redux Sega, and other

things to do asynchronous events or actions, I guess.

And just that choice changed your entire application structure.

And then certain things don't fit together.

And you have to think about what fits together and the ecosystem has to like these core building

blocks churn and then everything around it has to churn.

And so anyway, I'm just very happy that that's baked into Elm.

And it's like a very thoughtfully designed approach that works really well with all of

Elm's language guarantees and purity and stuff.

The Redux had limitations with this pattern being applied in JavaScript because things

like pure functions and managed effects don't really work that well in that context.

But in Elm, it works.

Everything works together cohesively and we don't have to churn and experiment around

We can experiment around other things.

And similarly, I think that just the simplicity of Elm and having one way to do things and

leveraging the same tools to do more things is really working for Elm.

So that's something I'd like to continue to see.

I think we really benefit a lot from that.

One aspect that I think is very important is that a lot of innovation is brought by

people that are passionate about a topic.

So for instance, I was passionate about static analysis through my work with the East End

before I joined the Elm community.

So I was well suited to add Elm review and a tool like that to the ecosystem.

There was Elm analyze, which helped me a lot as an inspiration, but which had different

I had all the tools necessary.

I had all the building blocks necessary and all the data that I needed to create an amazing

And I think that is true for all the tools that we mentioned already and some that we

And I think that having people explore and experiment with something that they're passionate

about is very important.

So we mentioned the error messages.

That was Evan being interested, curious about good error messages and spending some time

And that just happened to be Evan who worked on the compiler, but it could have been someone

else who might have done a fork of Elm for a while in his own backyard and then suggested

I don't know how that one would have worked.

The same thing happens for Elm test.

Someone was passionate about having a good test framework for Elm and worked on that.

And with fuzzing baked in, which is not, you don't see that that often that a testing framework

has fuzzing built in and a very thoughtful fuzzing API.

I know a lot of people put a lot of thought into that API.

And then we have other tools like Elm JSON, which someone felt like the Elm compiler was

lacking as to the commands that it provided to install packages.

And now we have Elm JSON, which is amazing.

And hopefully there will be backboard to the Elm compiler at some point for sure.

And for people who aren't aware, we should say this, if you do npm install dash G global

Elm dash JSON, this is not like Elm dot JSON files.

This is an npm installable tool.

I think it's built in Rust, of course, as one does, called Elm JSON.

And it helps you install Elm dependencies, upgrade Elm dependencies, resolve Elm dependencies.

So someone felt that pain and aimed to solve it.

It didn't require evidence work, evidence participation.

And now we have it.

We're unblocked on that matter.

I totally agree.

To me, I sometimes think of this as like the Apple approach of like, let people innovate.

And then once something is very obviously a good idea, then you steal it.

Of course, with Apple, they're stealing things from developers who are getting paid for these

tools and then suddenly they take it over and destroy their business maybe.

And maybe that's not great.

But for something like Elm optimize level two compiler optimizations and Elm JSON and

tooling like that, if it gets sucked up by the Elm compiler, then it's a win for everybody.

Nobody's getting their businesses lost by that.

But that said, Apple does this thing where they'll let people build these external display

tools where they find a way where you can plug in an iPad and display an external display

And then Apple kind of sits back and sees the innovation happening.

And then they say, hmm, it seems like people really like this.

All right, this is going to be part of the next OS release.

And then they release sidecar.

But anyway, I mean, I think that's actually not a bad recipe for a large open source project,

like a programming language.

But also all of those changes that may be stolen in a way, they all need to make sense.

So they need to fit the Elm philosophy culture maybe as well.

And they need to be compatible upstream and not be doing syntax extensions or things like

Or maybe as a proposal and then see how it goes.

I really like this general approach of just build something that's independently useful

but also could be useful if it's pulled in upstream to an official thing or the Elm compiler

And I mean, for example, Elm format.

I think Go and Elixir and a lot of other languages have these things built into the core and

the core executable for these tools handles that.

And that might work for those ecosystems.

But for Elm, it just works so well to have an independently maintained Elm format tool.

I just think that that's the right approach for Elm and for making the most of Evan's

approach, which he's been very thoughtful about.

And I think people spend so much energy thinking about how it could be different rather than

saying how do we make the most of it and work with what we've got.

So I'd like to see more of these tools that work in a decoupled way because in my view,

they really just are better suited to the way the Elm works.

And why sort of imagine that things are going to work a different way when we can sort of

see things that are working and do more of those things.

So let's say we had a different flavor of Elm popping up.

How do you think that that would work out?

My point of view is that it could be better in some ways, and I hope it would be otherwise.

Why would you even start it?

But a lot of the things that we have in the Elm community and mostly tooling would probably

And that would be a giant waste.

So if you added a different flavor of Elm with new syntax or a different way of how

it operates, then maybe Elm review would not be compatible with it.

Maybe Elm GraphQL would not work with it.

Elm formats, Elm tests.

And as I mentioned in the JavaScript ecosystem, every time a new tool comes up or a new custom

extension to the language, well, now everything needs to support it.

And that is a pain for everyone.

I totally agree.

And just to be clear, you're talking about if there were like a fork of Elm with a different

name, but something that forked Elm.

And yeah, I totally agree if it were to sort of change any semantics or syntax guarantees,

change anything regarding native code.

I mean, suddenly, if there are changes in native code and things like that, Elm review

doesn't work anymore because things that are safe changes are no longer safe.

Things that are unused might be used perhaps, or who knows, you just can't analyze things

So yeah, I think in my opinion, I wouldn't find that interesting.

I wouldn't find that to be a useful project if something forked Elm and diverged in a

way that was irreconcilable with the core Elm semantics and syntax we have now.

I wouldn't find that interesting personally.

If someone else finds that interesting, good for them.

That's just my personal opinion.

But to me, it would not be something that I would be interested in.

If there were a fork of Elm that used the same semantics and syntax as Elm, I would

be concerned about splitting the community and creating confusion there.

That would be my biggest concern.

I'd be concerned about...

Do you mean the user space or the tooling author space or both?

Yeah, where are packages published and are people confused about publishing things in

different places?

Are people confused about whether to use this one or that one?

Sometimes you need to look at the Elm documentation.

Sometimes you need to look at the fork documentation.

And here's the thing.

I think that forking...

What do we mean by forking?

There was a post, I'll try to dig up the link and find it, but there was a post recently

that was talking about this of like, what do you mean by forking?

Do you mean creating a snapshot in time where you make a couple of changes?

Or do you mean actively maintaining a large scale project and community around it?

Those are two very different things.

The post that was talking about this was talking about it in the context of Electron and like,

all right, you want to fork Electron?

Well, let's talk about what that would actually look like to maintain an active fork of Electron.

And then let's talk about if that's what you want to do.

But anyway, I think it's quite ambitious and I think it's a lot easier said than done.

So I would be very skeptical of that being something that's actively maintained and that's

going to be done in a way where it doesn't create confusion around where to find things

and that sort of thing.

So that said, people can do what they want to do, but those would be my concerns.

But what I see as the blueprint for success are again, let's look to the successes we've

had in the community so far and how can we use those things that we've seen be very successful?

In my opinion, Elm format has been wildly successful.

Now it's just the status quo.

But if you take it away, I would be very sad.

If it disappeared from my life, then I just would be useless.

I'd have to go build it before I could work in Elm.

It's just like part of how I write Elm these days.

So it's been wildly successful.

I think other projects can be similarly wildly successful.

I think that we can, how can we create a decoupled approach to improving Elm?

I'd love to double down on that because I see a lot of success from that approach.

As I mentioned earlier, if there is a big fork of Elm in the sense that it's an entirely

new project with a new community, with new ways of working, you were saying you were

concerned about splitting the community and tooling would be one part of that because

yeah, you wouldn't have Elm format, you wouldn't have Elm review, you wouldn't have Elm Graph

QL, you wouldn't have Elm test.

And all those authors would have to, well, sometimes be brought back from the dead because

Elm tools are just working, don't have a maintainer anymore, I guess.

Not the ones that I've just mentioned, but, and they would all have to be convinced to

be moved or copied to the other fork.

And that's a lot of work, one, to convince them and then to actually do the work.

And we don't have that much time in the sense that I don't think there's many projects in

the Elm community that have more than two or three maintainers.

And even those are the exception rather than the rule.

I think most of them have one main maintainer and then a few people who help here and there

I mean, I think it could potentially be done in a way where it doesn't depend on people

like republishing packages or something like that, but it's something to be aware of.

And anyway, I mean, I think if somebody is taking on a project like that, I guess I have

a very skeptical eye about this idea of that solving a lot of problems.

To me, my concern would be that it would introduce more problems than it would solve.

And so that's why if somebody were to do it, I think, I hope they would consider the points

we're talking about of being cohesive with the upstream Elm and that sort of thing, and

not creating a divergence where it's changing semantics and things in ways that are irreconcilable.

I mean, for instance, ElmJSON copies the same behavior as Elm in a way and acts as a replacement

when you want to install packages, but it doesn't create an entirely different fork

of the language.

Which Lamdera does too, actually.

And Lamdera actually happens to be a fork of the Elm compiler.

We don't think of it as such because it is essentially like a swappable Elm.

It attempts to preserve all of our expectations about Elm, but it does do certain things that

Elm doesn't, in particular, running certain things in the backend and maintaining these

server side things and that sort of thing.

So yeah, I think that that's been successful for that particular approach.

But if somebody is purely just trying to patch some things about the way that Elm works,

I would be skeptical of that being the best way to solve those particular problems.

And I would look more to the types of things that we've been discussing that have been

success stories that we can look to as a blueprint.

Because Elm is all in all pretty much a language that we just love.

It is just so good on so many aspects that it doesn't require much changing or much evolution

And it's a simple language.

There's just and I love that about it.

There's just there aren't that many ways to express things with alternate syntax and things

But the innovation happens around that simple core.

Another thing that is working very well for Elm that again, I think we sort of forget

because we get used to things just like we get used to Elm format being baked into our

But the Elm 19.1 compiler performance is insane.

And that is really working well.

I mean, I hear a lot of people like going to build things in Haskell or Rust or these

other tools with a lot of these language features that us Elm folks really appreciate.

But then they're like, but the compiler feedback loop is so much faster in Elm.

And it makes such a difference to that iteration cycle.

I mean, it doesn't.

It even allows us to do some things that we otherwise would not probably.

For instance, Elm review compiles the configuration.

I think Elm pages also does something like that.

It actually compiles in the dev server.

If you like change a file or add a file that is depended on by a data source, it recompiles

and executes that data source and sends the data back to the dev server and hot reloads

in that data, as well as also recompiling the Elm code and shipping that back with a

So, yeah, if it wasn't fast, that wouldn't be possible.

So you wouldn't want to use Elm review if it wasn't that fast.

If it took like a whole minute just to compile your configuration, then that would be an

entirely different experience.

People would maybe still use it, but it wouldn't be the same thing.

And if the compilation process was more complex, for instance, every time I hear people talking

about Haskell and choosing stack or cabal or whatever, that is just very painful to

set up from what I understand and from what I have tried.

Whereas with the Elm compiler, you just run Elm make, you already have an Elm JSON file,

and things happen in a sound way and in a fast way, and that makes everything much,

So we wouldn't have Elm review and Elm pages the way that they are today if the Elm compiler

was not fast and did not behave the way it does, is basically what I'm trying to say.

And another thing that I actually have on my list here of things that are working are

I think that leveraging these qualities of Elm for performance.

So for example, the fact that Elm has been really competitive in these sort of, you know,

really competitive in these sort of frontend framework performance metrics and benchmarks.

When it's doing these things that you would think of as not performant, like immutability

and not to mention targeting JavaScript, which is this very tricky thing to optimize for

because it's got all these just in time optimizations and things.

But even without, you know, like there have been so many optimizations that, you know,

you and Robin in the past couple of months have been finding these like big performance

gains that have been making their way into Elm optimized level two.

But even without those, Elm is so competitive and it seems like we're just scratching the

surface of what performance could be for Elm.

So leveraging this purity for making performance optimizations, I think is very interesting

because Elm is a limited, you know, runtime.

The sort of update cycle, you know, if it compiled to WASM at some point, imagine how

we could double down on performance there by taking these sort of assumptions that we

know about how Elm uses data and allocating memory in a way that's tailored for that and

that sort of thing.

There's so much we can do by taking advantage of these qualities that Elm has for performance.

And we already see a lot of them and we could double down on that.

And you know, like HTML lazy, I love how that is something that you can drop in.

And the most dangerous foot gun that it has is not that you'll have incorrect information

where you're telling it something has not changed, but it actually has changed and become

Dale, which you can do with a lot of these other front end framework optimizations.

The biggest foot gun is that you accidentally pass in a new type of data rather than something

that is referentially going to be equal and the optimization doesn't kick in.

That's the worst that can happen.

Which is basically just comparing two JavaScript arrays extra.

That is the entire penalty.

It's not getting the optimization you expected, that's the worst thing that can happen.

So anyway, I think that these things are really cool, taking advantage of Elm's purity and

the language itself for performance.

So another thing, kind of stepping back a little bit more to the community, because

you and I think a lot about this.

I think that, well, what's working for Elm?

I've got to say, there's a certain podcast that I think is working very well for Elm,

if I do say so myself.

I wonder which one you mean.

I've certainly been enjoying that.

But I would love to see more content in the Elm ecosystem.

We've been seeing some cool stuff coming out lately, but I would love to see people sharing

So the Elm conferences have been such high, I've been so impressed with the quality of

talks at Elm conferences and the organization of Elm conferences.

I am going to include conferences under things that are working for Elm and the Elm ecosystem

in my list, even though there is of course a caveat, which is now, I think that global

pandemics are not working so great.

If we could turn that knob down.

Turn that knob down.

That's the one knob I'm going to...

We're focusing on turning knobs up, but that is one knob that I think we can agree would

be nice to turn down.

But conferences have been working so well, and I hope that they will reemerge when things

sort of settle down in the global landscape here.

But it has been cool to see Elm online as a consistent global virtual platform for Elm

talks popping up.

That's been really great.

And also just some people are making videos on YouTube regularly.

That is a nice source of content if you are looking for some.

So let's talk about that for a second.

So if people want to be the change they want to see in the Elm ecosystem, what do you think

that looks like?

Like what are some things that...

Because I think that it's...

I think we should be careful when turning things up to 11.

There's a difference between telling someone to turn something up to 11 versus you realizing

that you can help to turn that knob up to 11.

So what are some things you think that people have in their power to turn up to 11?

I think people should go for what they're passionate about.

If you're passionate about static analysis tools, then build one, then contribute to

one, explore things that are new, explore things that are old.

Just work on it and then share it and ask people for feedback, which is not always very

easy because we are a pretty small community.

But I think we have a community that is pretty excited in the sense that if we see new cool

things, then we get excited as well.

Sometimes getting that excitedness across is a bit hard, but yeah, work on something

that you feel passionate about.

Share it on discourse, on Twitter, on Reddit, on Hacker News if you are bold and brave,

and then see how people reply to it.

I would really urge to try and follow the Elm philosophy about making tools that work

well across the whole community, that have the same ideas of having greater user experience,

greater error messages, being helpful, being delightful.

If you try to incorporate all of those, which you don't have to do to begin with, then I

think you will get somewhere that will help people and you will find other people to help

Yeah, I think that's a great message.

I want to add to that that to contribute, let's say we're talking about a tool or a

package, you don't need to be the author or lead maintainer of a tool or package to be

Actually this is part of this Elm philosophy tweet that Evan wrote, which we'll link to

in the show notes.

Well, let me just read a few of these points because I think they're very relevant to this

point of how people can contribute.

It starts with be kind.

That's one thing to keep in mind.

Learn from everyone, collaboration requires communication.

Not every problem should be solved with code.

Communication is contribution.

Understand the problem.

Explore all possible solutions.

Pick one solution.

Don't try to be every solution.

Simplicity is not just for beginners.

It's better to do it right than to do it right now.

It's not done until the docs are great.

Take responsibility for user experiences.

Make impossible states impossible and there are worse things than be explicit.

I just love all those points.

We've talked about them at length, but always good to have a refresher.

By the way, those things are really working for Elm and those philosophical ideas, you

really do see them all the way running through all of the Elm ecosystem, I think.

If somebody wants to contribute, you can write an Elm review rule.

You can contribute to an Elm review rule.

You can see something.

I've been seeing a lot of people making some great contributions to projects that I maintain

recently and I really appreciate it.

I try as much as possible to trust people to take ownership when there's something that

they're passionate about.

I'll try to be there to help them understand how it can fit into a project and that sort

I try as much as possible to just trust them to solve the problem and use their creativity

I really appreciate it when people do that.

You don't need to be a lead maintainer or create a new project to contribute in some

There are a lot of ways to contribute.

In fact, even just sharing your feedback is a form of contribution.

Also just writing a blog post or talking about Elm at a conference, and maybe even more so

at non Elm conferences to get the language out there even more than it is today.

Those are helpful.

Even if you just blog about your favorite tool which might or might not be Elm review,

it makes us feel good and it will be helpful for other people, I'm sure.

Those things make a difference.

You never know what impact it's going to have, but it's actually people writing blog posts,

just sharing their experiences or sharing how to do something that they wish they'd

known how to do when they started.

Those things can go such a long way.

If you do want to write a blog post or you want to contribute to a project, be sure to

turn that knob to 11.

Write plenty of blog posts and plenty of contributions.

Only if you see that it works.

I think that people have more power at their fingertips than they realize.

I think that's one message I'd like to give to people that every little thing counts.

Even if you're not turning a knob all the way up to 11 by yourself, even if you're just

nudging that knob a little bit, it makes a difference.

It's not like you and I were granted godly permissions from the Elm core team to do something.

No, we did stuff because we felt passionate about them and they worked out well.

They may not work well, but in our case, they did.

I'll say for as far as specifically open source projects go, man, when I look back, it's kind

of fun looking back at early open source projects.

But I've been dabbling in open source for a long time.

Even as early as when I was at my first job after college around 2013, I was creating

open source like, did anyone use them?

I used them a little bit, kind of.

I made a simple little Ruby command line tool to help do some high level git things.

Probably the most interesting thing about it was the name of the project, which was

legit, which is a play on words.

It's probably the most impressive thing about the project, which is saying a lot.

Is it a play on words?

Please explain it to us.

As we know, jokes are at their best when they're fully explained.

Did you just explain my joke?

It takes practice to get good at finding things that will be useful for other people.

But hey, if it's useful for you, then at least you know it's useful for one person.

Parts of my contributions were always to scratch my own edges.

My own edges and then the ones from my teammates.

And then sometimes they turn out to be useful for other people.

This is just my personal value system, I guess.

But I really like trying to fit into the existing way of things working as much as possible,

rather than trying to say everything should be different about this, that everything needs

I really like to say, what is working about the way things are being done and how can

I contribute given the way things are working?

For example, you look at TypeScript and TypeScript is saying, all right, we've got this JavaScript

This is kind of here to stay.

This is how JavaScript works.

Are there a few semantics and things that could be cleaned up to make it easier to build

a type system around?

And people have created type systems that are simpler and require less work to architect.

But we want to take JavaScript and help people who have JavaScript code.

And so let's build an incremental thing that fits into your JavaScript code bases and helps

And so how can we do things that fit into the way that Elm works, the way the Elm ecosystem

works, the way people are using Elm?

And we see all these great examples of that, that really add right now.

And could they become some official part of Elm tooling at some point?

Maybe they need to be.

I mean, in a lot of cases, a project being valuable doesn't depend on that.

Maybe Elm optimized level two will never make its way upstream into Elm.

And that wouldn't be the worst thing in the world.

What might we get instead?

What will the next better error messages of Elm be?

And what would you rather have, the next better error messages of Elm or the Elm optimized

level two changes making their way upstream?

You know, maybe we'll get some WASM stuff instead of that or something that wasn't even

And we were asking for a faster horse and we get a car.

So anyway, like I just I think that I'm a believer in not expecting people to change

the way things are being done, but instead saying, given the way things are right now,

how can I be of help?

How can I contribute to this thing that I want to improve?

We need like a the more you know, public service announcement message now.

This entire episode was a public announcement message.

I mean, I hope that I hope that it comes through that Jeroen and I are genuine in our thoughts

that we're sharing here.

People might not see things the same way as we do here, but we're trying our best to share

our perspectives here and sometimes, sometimes conversations can have a lot of voices.

And we wanted to add our voices to this conversation about the state of Elm for the record.

So we could kind of put in a different perspective.

And since you listener cannot have a conversation with us through this podcast format, you can

reply to us through discourse or Twitter, where we can continue this conversation if

Yes, we always love hearing from people and having a conversation.

And also, if anybody wants to, you know, inspire it at all to be the change they want to see

in the Elm ecosystem, Jeroen and I, I think it's fair to say are always very happy to

help out any way we can talk things through, point you to the right place.

If you want to bounce an idea, there are places to do that, too.

There's a great API design channel in the Elm Slack, but we're here to help how we can

Have we shared all of our thoughts?

And I will just say for the record, every time before Jeroen and I record, every time

he says, I don't think we'll have that much to say.

That means it's going to be a long episode.

That's how you know.

Well maybe I'll just end up saying it every time just so that we have longer episodes.

Which by the way, let us know if you like shorter or longer episodes.

Feedback is always welcome.

So we can turn that knob all the way up to 11.

If you want longer episodes, we'll turn it to 11.

11 hours of content per episode.

Well, I look forward to seeing what 2022 brings with turning up those knobs to 11 and Jeroen.

Until next time.

Until next time.