spotifyovercastrssapple-podcasts

What's Working for Elm

We look at what we can learn by understanding what's working well for Elm and the Elm ecosystem.
January 3, 2022
#47

Where Could We Turn Up the Good?

Pure FP

Useful Error Messages

Useful error messages

Having a single language flavor

Decoupled tools

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

[00:00:00]
Hello, Jeroen.
[00:00:02]
Hello, Dillon.
[00:00:03]
So today, I wanted to talk about something a little bit different, talk about something
[00:00:10]
maybe like a little bit of a different format than usual.
[00:00:13]
So there's a concept that I'm very fond of.
[00:00:15]
It's this idea of turn up the good.
[00:00:17]
I think the idea is originally from Kent Beck and his XP book and Woody Zool has taken this
[00:00:26]
idea and really leaned into it quite a bit.
[00:00:29]
So the idea of turn up the good is if you imagine you've got a bunch of knobs and they're
[00:00:36]
the things that are sort of working well in an organization, in the way you build software,
[00:00:43]
in the tooling around software, in the language, you turn all those knobs up and you turn them
[00:00:49]
up to 11 and you see what happens.
[00:00:51]
That's turn up the good.
[00:00:53]
I think I've seen you talk about that when talking about incremental steps.
[00:00:58]
Yes, exactly.
[00:00:59]
Exactly.
[00:01:00]
Yeah, to me, it's really baked into my mindset.
[00:01:04]
You sort of over time build up these pillars that form your thinking about a topic.
[00:01:10]
And yeah, to me, it's just inseparable from how I think about writing software and changing
[00:01:17]
process over time, whether it's personal process, organizational process, whatever it might
[00:01:22]
be.
[00:01:23]
Like an interesting story, Woody Zool who worked on this team where they sort of came
[00:01:29]
up with this idea of mob or ensemble programming, which is like pair programming, but with more
[00:01:36]
people and it's a really interesting technique.
[00:01:39]
But the basic idea is the team that sort of came up with this mode of working said that
[00:01:47]
we didn't really come up with mob programming because we were looking for something like
[00:01:52]
that.
[00:01:53]
We came up with it because we were paying attention to what worked and we were turning
[00:01:57]
it up, turning up the good.
[00:01:59]
So they thought that pair programming was working well for them.
[00:02:01]
So they added more people and then more people.
[00:02:04]
Yes.
[00:02:05]
The entire team.
[00:02:07]
And also they noticed what was working.
[00:02:10]
So they noticed that when they would sit down and try to solve a problem, they would sit
[00:02:16]
down and they'd sort of have a meeting and they'd say, all right, we really need to solve
[00:02:19]
this problem.
[00:02:20]
And everybody would sit down in a room together and they'd hash it out and they were like,
[00:02:24]
huh, that worked well.
[00:02:25]
Well, what if we did more of that?
[00:02:27]
Like what if that one part that seemed to work really well where we all kind of sat
[00:02:31]
down and figured it out, what if we just did that a little bit more and a little bit more?
[00:02:36]
And now all they're doing is meetings.
[00:02:40]
Well, that sounds wrong when I resume it that way.
[00:02:46]
Well, I think they would distinguish, they would say that meetings is when you talk about
[00:02:51]
doing work and collaborating is when you do work.
[00:02:54]
So in fact, they would say that they do no meetings because they never talk about doing
[00:02:59]
work.
[00:03:00]
They're just constantly working together and they have context on everything.
[00:03:03]
So now the point being for our conversation today, because we could talk a lot about mob
[00:03:11]
programming, it's a very interesting topic.
[00:03:13]
But the thing that was really interesting in that story is that they weren't looking
[00:03:19]
at everything that was happening and saying, all right, let's solve these problems.
[00:03:23]
We've got this problem, we've got that problem.
[00:03:25]
What are we going to do about those problems?
[00:03:27]
Instead they were saying what's working and how do we do more of that?
[00:03:31]
And then suddenly all these problems start to go away because they're making the good
[00:03:38]
things better.
[00:03:39]
I think now I'm not saying that you can solve every problem by turning up the good.
[00:03:45]
I'm not saying that you can't solve problems by thinking about what problems are and trying
[00:03:50]
to fix those problems.
[00:03:52]
And they're both valuable, but that's what I want to focus on today is looking at what
[00:03:58]
is working for Elm and the Elm community and thinking about what would it look like to
[00:04:04]
do more of those things.
[00:04:05]
All right.
[00:04:06]
That sounds good.
[00:04:08]
So Dillon.
[00:04:10]
Yes.
[00:04:11]
What is working well for Elm?
[00:04:14]
What do we need to turn up to 11 or what has already turned to 11?
[00:04:18]
Exactly.
[00:04:19]
Yes.
[00:04:20]
Really, I think there are so many things.
[00:04:22]
So where to start?
[00:04:23]
Well, I mean, first of all, I think I can't think about this question without immediately
[00:04:31]
thinking about the core of Elm, which to me is pure functional programming.
[00:04:36]
And I mean, we don't like to do too much jargon, but we all sort of know what we're talking
[00:04:42]
about.
[00:04:43]
So this is like maybe the simplest way to communicate this thing that we all know and
[00:04:46]
love, which is not having to think about where side effects are coming from or mutations
[00:04:51]
or global state and environment and things like that.
[00:04:55]
And you put a value in, you get a value out.
[00:04:58]
And really there are a few languages that exist in production contexts that have this
[00:05:07]
property.
[00:05:08]
It's very unique.
[00:05:09]
And it is, in my opinion, it is really working and we should double down on that.
[00:05:14]
And in fact, Elm 19 did double down on that.
[00:05:17]
Some people weren't happy about that, but I honestly, I think that's working for Elm.
[00:05:25]
And I think that you can't imagine if a package could do side effects, Elm review would become
[00:05:36]
much less interesting.
[00:05:38]
I was thinking about that.
[00:05:40]
I made a post about removing dead code in a very safe manner.
[00:05:47]
And suddenly assumes that nothing has side effects except performance issues maybe.
[00:05:53]
And if there is anything that can create side effects or can have an impact outside of what
[00:06:00]
is just returning a value, then all of the promises that Elm review unused gives you,
[00:06:07]
which I've turned to 11 in a way, it's just entirely destroyed.
[00:06:12]
So I'm very happy that Elm went the way it did.
[00:06:17]
Yeah.
[00:06:18]
I think you would agree that if I can make a bold statement that the most interesting
[00:06:23]
thing about Elm review is Elm.
[00:06:29]
The most interesting thing about it is like if you were to take the concepts from Elm
[00:06:36]
review and try to do it in any other language, suddenly the most important thing about it
[00:06:41]
wouldn't be there anymore and it would no longer be interesting or important.
[00:06:45]
Exactly.
[00:06:46]
I mean, Elm review is just supportive of what I did with ESLint with some ideas changed
[00:06:52]
and the experience for me as an author and as a user are vastly different and in the
[00:06:58]
good sense.
[00:06:59]
Right.
[00:07:00]
Right.
[00:07:01]
And the ability to create high quality rules and high quality fixes from community members
[00:07:08]
is just night and day.
[00:07:10]
When you look at how easy it is to write a reliable fix and do reliable static analysis
[00:07:17]
by writing your own Elm review rule compared to writing an ESLint rule.
[00:07:21]
I mean, how many like, I don't know, from your experience, like using ESLint rules,
[00:07:27]
is it common to find unreliable rules and fixes?
[00:07:34]
Maybe not.
[00:07:35]
Maybe they're just less ambitious.
[00:07:39]
They can be unreliable.
[00:07:41]
The fixes not so much.
[00:07:43]
Okay.
[00:07:44]
Let me rephrase that.
[00:07:46]
So yes, I have heard of a few rules that created changes in behavior because they didn't know
[00:07:54]
JavaScript well enough and in some cases it was really hard to predict.
[00:07:59]
The language is so big that it's a bit hard to know what the effect is of a change.
[00:08:05]
But also one of the most common cases of issues was the fact that the rules crashed the ESLint
[00:08:13]
because they were written in JavaScript and JavaScript crashes.
[00:08:17]
So that is, I think, the most common thing where you expect the AST to have a property
[00:08:23]
to be always there.
[00:08:25]
For instance, if you have a try catch in JavaScript, you always expect there to be a catch, for
[00:08:32]
instance.
[00:08:33]
I'm not even sure if that's the case anymore, but I remember myself learning about some
[00:08:40]
optional syntax or syntax that was actually optional, which I thought was required.
[00:08:44]
And I don't remember if it was a try catch example or another one, but something similar
[00:08:48]
to that.
[00:08:50]
There's always a catch.
[00:08:51]
There's always a catch, except...
[00:08:56]
With very exceptions, there's always a catch.
[00:09:00]
Beautiful.
[00:09:01]
But at least you got to try and write those rules, right?
[00:09:07]
Exactly.
[00:09:08]
Finally, finally.
[00:09:09]
Oh, man, that was bad.
[00:09:13]
No, that was good.
[00:09:16]
We should stick to elm puns maybe, but it's just so much easier with JavaScript.
[00:09:20]
So many more keywords.
[00:09:22]
Exactly.
[00:09:23]
Exactly.
[00:09:24]
Yes.
[00:09:25]
Now, that brings up another point of something that I think is pretty clearly working for
[00:09:32]
elm, which is no exceptions, asterisk, right?
[00:09:36]
Of course, unless we're solving the halting problem, we're not going to have no exceptions
[00:09:44]
because you can always do an infinite recursion.
[00:09:48]
Yes.
[00:09:49]
And in some cases, it will be infinite.
[00:09:51]
And in some cases, it will crash the stack.
[00:09:53]
Well, right.
[00:09:54]
Exactly.
[00:09:55]
It could be a conceptually infinite recursion, which in practice is going to mean a finite
[00:10:03]
recursion that's just going to crash the stack.
[00:10:08]
Which one is better depends on your use case, I guess.
[00:10:12]
I think someone crashed the stack there in your background.
[00:10:16]
They did.
[00:10:18]
Paris.
[00:10:19]
Too many parties over here.
[00:10:24]
So this no exception thing is really working.
[00:10:27]
And of course, there are cases that can make exceptions.
[00:10:31]
And I think this is something to double down on as well.
[00:10:36]
I know that this comparing two functions with double equals is one thing that can currently
[00:10:43]
crash the runtime, which I know that Evan is thinking about ways to solve that problem
[00:10:51]
through the type system potentially.
[00:10:54]
So that's another thing to potentially double down on that's working for Elm.
[00:10:58]
Also the error messages.
[00:10:59]
I mean, that is one of Elm's biggest features is that the error messages are so nice.
[00:11:06]
And ever since they were introduced in 2015, I think, they have been improved and improved
[00:11:13]
and improved.
[00:11:14]
There are still some cases where they can be improved.
[00:11:17]
But oh, my God, there's just so good.
[00:11:20]
Yeah.
[00:11:21]
I mean, it's pretty clear that that's been wildly successful.
[00:11:25]
Just if you trace the influence to other tools and communities and how it's had an effect
[00:11:33]
on them.
[00:11:34]
So I guess Elm does have side effects.
[00:11:38]
Elm does have side effects.
[00:11:41]
Were they intentional or not?
[00:11:43]
Right.
[00:11:44]
Right.
[00:11:45]
So I think this is another interesting point about the sort of meta process of Elm.
[00:11:50]
I think Evan has talked about how the error messages were not, first of all, it wasn't
[00:11:57]
something people were complaining about.
[00:12:00]
People weren't like, hey, these error messages suck.
[00:12:03]
People didn't have a problem with them.
[00:12:05]
And it was something that Evan started exploring.
[00:12:09]
And I think that this is something that, I mean, people complain about this.
[00:12:15]
But this is how Evan works and brilliant things come from that way of working.
[00:12:22]
And I'll take them.
[00:12:23]
I will take these brilliant ideas that emerge from this process of exploring.
[00:12:28]
Exploring things that aren't necessarily the obvious path of things that people are actively
[00:12:34]
complaining about.
[00:12:37]
I mean, no one was complaining about the error messages because they are bad in pretty much
[00:12:42]
every other language, right?
[00:12:44]
Exactly.
[00:12:45]
Yeah.
[00:12:46]
I don't know any languages that have good error messages apart from Elm and languages
[00:12:51]
that have been inspired by Elm, like Rust.
[00:12:54]
Yeah.
[00:12:55]
Yeah, exactly.
[00:12:56]
Yeah.
[00:12:57]
It's like if you ask people what they want, they'd say they want a faster horse kind of
[00:13:02]
thing.
[00:13:03]
Yeah, always.
[00:13:04]
Yeah.
[00:13:05]
But sometimes the faster horse doesn't bring you closer to your goal, right?
[00:13:10]
Yes.
[00:13:11]
Yes.
[00:13:12]
Yeah.
[00:13:13]
Yeah.
[00:13:14]
I think that many of the most beloved parts of Elm have come from that process.
[00:13:20]
And I don't know, I just want to, I guess, take a moment to recognize that.
[00:13:25]
At least that's my personal feeling because I think that sometimes we can get caught up
[00:13:30]
in saying how we think things should work and we forget to say what successes have come
[00:13:38]
from the approach.
[00:13:40]
And a lot of great things have come from Evan's approach of really, and he's given some really
[00:13:47]
great talks about this topic.
[00:13:49]
He gave a really good talk, I was there in person at Deconstruct Conf, he was talking
[00:13:53]
about this approach and he's given a few other talks about the meta process of batching things
[00:13:59]
and looking at the bigger picture, doing an exploratory approach where he's not necessarily
[00:14:07]
doing the obvious things, but he's sort of thinking.
[00:14:10]
You know, Richard often talks about let's do the ambitious approach.
[00:14:14]
And I mean, Elm is a bold language.
[00:14:18]
It's a bold concept to do something with pure functional paradigms.
[00:14:24]
And yeah, and we sort of get stuck with this like, okay, well, here we are now, but we
[00:14:31]
forget how we got there, you know?
[00:14:33]
And we got there through these like bold explorations.
[00:14:39]
I haven't followed Elm's evolution because I was kind of late to the game.
[00:14:43]
I think I was there for when 0.16 was there.
[00:14:47]
And then I had a moment where I wasn't there and I started when 0.19 was released.
[00:14:55]
So I didn't go through the early stages.
[00:14:57]
But I really like how Elm turned out to be with the great error messages, the promises
[00:15:04]
of no runtime errors, which is almost true, but true enough that I have never seen it
[00:15:12]
crash in practice, which is something.
[00:15:17]
And also the way that every tool is designed, every building block of Elm is designed where
[00:15:24]
tooling can have so much information about how the program works and what it needs, what
[00:15:30]
the dependencies are that makes a tooling author's job so much easier.
[00:15:37]
I mean, when I was working with the ESLint, I had very little information about what the
[00:15:43]
code I was looking at was doing.
[00:15:46]
There were values, there were function calls, that's it.
[00:15:50]
And every file you were looking at was split on its own.
[00:15:55]
You couldn't see what was happening in one file and correlate it with what is happening
[00:15:59]
in another file and find issues when combining the information from both.
[00:16:05]
But the Elm language makes that so easy, gives you the information about what is in your
[00:16:12]
dependencies, gives you access to the dependencies source code, if you want to look at that, has
[00:16:18]
an explicit import system, has an explicit Elm JSON file with all the dependencies and
[00:16:24]
the versions.
[00:16:26]
And that makes things a lot easier.
[00:16:28]
And also the fact that there are no flavors of Elm, no different flavors, only a single
[00:16:35]
flavor, makes it really easy to support everything.
[00:16:38]
Are you talking about JSX versus TSX versus some custom Babel language extension?
[00:16:46]
Yeah, or even just different versions of Elm or of the language of JavaScript, of ECMAScript.
[00:16:54]
Like a Node.js runtime versus Dino versus...
[00:16:57]
Yes.
[00:16:58]
I mean, I've worked on the Node slash NPM ecosystem for a few years and making all those
[00:17:05]
tools work together, making every tool support, every new flavor of JavaScript, it's a pain.
[00:17:12]
Using Webpack?
[00:17:14]
Using Webpack.
[00:17:16]
I mean, all of them are amazing, really.
[00:17:20]
All these tools, they're really good.
[00:17:23]
But to make them work together, that is just very hard for both tooling authors and for
[00:17:30]
users.
[00:17:31]
And it's just because there are so many flavors that you need to support and so many people
[00:17:36]
you need to please, users you need to please, that it's really hard to do the right thing.
[00:17:41]
Yeah, I totally agree.
[00:17:45]
I think Dino is actually trying to solve this problem to a certain extent where they're
[00:17:49]
saying like, listen, we've got this fetch thing in the browser and then we've got this
[00:17:57]
other way of making requests in this sort of server side code and it's really hard to
[00:18:02]
do code sharing and we have to sort of check for different environments and let's just
[00:18:07]
double down on using standards.
[00:18:10]
So Dino is trying to use web standards.
[00:18:13]
So they're trying to implement as many of these APIs following web standards as possible
[00:18:18]
to sort of try to tackle this problem.
[00:18:23]
When it comes to Elm, like when I'm working on Elm pages, similar to what we were saying
[00:18:28]
about Elm review where the most interesting thing about Elm review is Elm, I see it the
[00:18:32]
same way with Elm pages.
[00:18:34]
To me, the most interesting thing about Elm pages is Elm.
[00:18:36]
It's not the pages and it's trying to bring out these uniquely interesting qualities in
[00:18:44]
Elm.
[00:18:45]
For example, I'm trying to remember the word that's used.
[00:18:48]
It's not idempotence.
[00:18:51]
This idea of having something running in different environments the same way, you can have issues
[00:18:57]
where if you run it in Node or if you run it in the browser, there are different APIs
[00:19:02]
available.
[00:19:03]
So if you try to call fetch in some backend code, then you have to patch it to make sure
[00:19:10]
you expose an equivalent API.
[00:19:14]
So these sort of frameworks like Next.js and this sort of thing have this issue where people
[00:19:18]
will install an NPM package.
[00:19:20]
They'll try to run something.
[00:19:22]
It depends on the FS package to do file system stuff.
[00:19:26]
And that doesn't exist in the front end, but you've installed some NPM package and it tries
[00:19:31]
calling that and it crashes.
[00:19:32]
Because it's not a package, it is module.
[00:19:35]
The core modules from Node, yes.
[00:19:37]
It's a core, exactly.
[00:19:38]
It's just one that just exists in Node and then Webpack 4 would automatically patch those
[00:19:46]
to use these stubs for things like FS.
[00:19:49]
So you could depend on the FS module and other built in Node modules.
[00:19:55]
Through ponyfills and ponyfills.
[00:19:58]
Yeah.
[00:20:00]
And I mean, it's really, you can imagine like one build tool like Webpack, like you said,
[00:20:05]
they're doing extremely complex, impressive things.
[00:20:09]
The fact that there's so much complexity is going to cause a lot of pain and a lot of,
[00:20:14]
you know, you use one tool, it works.
[00:20:15]
You use another tool, it doesn't work.
[00:20:17]
You go from Webpack 4 to Webpack 5 where they stopped doing those polyfills or those stubs
[00:20:23]
and it breaks.
[00:20:24]
Suddenly all these things start to break.
[00:20:25]
You go from required to ESM and all these things start to break.
[00:20:29]
So there are all these things that are so easy because of this, just everything is just
[00:20:34]
pure functions and types in Elm.
[00:20:37]
And so with Elm pages, if you're running certain things that are running actually in a Node
[00:20:42]
environment on like server side code at the build step, it doesn't matter.
[00:20:46]
You just write Elm code and you don't have to worry about was this Elm code that was
[00:20:50]
targeting Node JS or was this Elm code that was targeting the browser.
[00:20:55]
Like with Elm pages, there's this idea of a data source and you know, just like a command,
[00:21:01]
like you can create a command somewhere, but it's not going to do anything unless you return
[00:21:05]
it to a place that's expecting a command, namely the init and update functions.
[00:21:10]
And similarly in Elm pages, there's this data source type.
[00:21:14]
And if you give that to the right place in Elm pages to, you know, to a page module,
[00:21:20]
then it can do something with that.
[00:21:23]
But those types enforce those constraints.
[00:21:26]
So you don't just like, and that's just Elm working, this Elm pure function thing where
[00:21:32]
like things don't just perform side effects, they're data.
[00:21:36]
And you can build these meta platforms around that idea, but you can't unwind it from this
[00:21:44]
totally open arena of JavaScript where side effects can come from anywhere.
[00:21:50]
You can't then put constraints on that and start getting these guarantees and predictability
[00:21:57]
that you get in Elm.
[00:22:00]
So that's working.
[00:22:01]
In a way you can see Elm pages as a flavor of Elm, of regular Elm code.
[00:22:08]
But even with that in mind, but even if you see things that way, for instance Elm review
[00:22:16]
doesn't have any specific logic to work with Elm pages.
[00:22:22]
So Elm pages is just another regular Elm project from this tools point of view and same thing
[00:22:28]
for IDs and for Elm formats.
[00:22:33]
So because you have just built upon the standards of the language and extended it in a way that
[00:22:40]
is not, that does not break anything, any assumption that tooling might have, there's
[00:22:48]
no additional work tools have to do, which I think is not the case in the JavaScript
[00:22:54]
ecosystem where new tools create new assumptions, new problems actually to solve.
[00:23:00]
There is actually one other flavor of Elm which we have talked about on the show and
[00:23:04]
that is LameDera.
[00:23:06]
And I do support that with Elm review.
[00:23:09]
The only thing that I had to do was to have the Elm review unused package, know that there's
[00:23:16]
a specific main function, which is called app.
[00:23:21]
I think that was about it.
[00:23:23]
So it really wasn't much effort to support it.
[00:23:25]
That's the way I like it.
[00:23:28]
Yeah, yeah, absolutely.
[00:23:32]
Once you open up the Pandora's box of side effects anywhere, eval, dynamically creating
[00:23:38]
options, things like that, you can't close it.
[00:23:41]
But if you keep that box closed, there's a lot you can do with that.
[00:23:46]
I mean, it's very attractive to have all those things because it would make Elm much more
[00:23:51]
powerful.
[00:23:52]
But by doing that, you would turn the knob from 11 to 9, 8, 3, I don't know.
[00:24:03]
Anything that you would have gained from that would be lost, most things at least.
[00:24:08]
I think Richard Thelman described it this way.
[00:24:11]
If you have a bucket of water and you put one drop of urine in it, then you have a bucket
[00:24:19]
of watery piss or urine water.
[00:24:24]
Yes, yes.
[00:24:25]
You get the point.
[00:24:27]
Right, right.
[00:24:28]
Yeah, I mean, a 99% guarantee is not really a guarantee.
[00:24:38]
You can take pure functions and decide to perform side effects from specific parts of
[00:24:44]
those pure functions, which is exactly what Elm is.
[00:24:46]
That's what managed effects are.
[00:24:47]
You return something from update and then you do something.
[00:24:51]
But everything else is still pure functions.
[00:24:53]
But you can add more things like that, which is essentially what Elm pages and Elm review
[00:24:59]
do.
[00:25:01]
They take certain points.
[00:25:02]
You return a data source in a specific place and it can say, oh, okay, I'm going to go
[00:25:07]
read some files and I'm going to go do a glob and find all the matching files and return
[00:25:14]
those to you.
[00:25:16]
I'm going to do a glob watcher and every time the files change, I'm going to do a live reload
[00:25:23]
in your dev server.
[00:25:24]
Similarly, like Elm review, you do these things and it's going to run a fix and modify this
[00:25:32]
part of the code and run Elm format on it.
[00:25:36]
Those aren't pure things, but you do it by returning a specific data type in this specific
[00:25:41]
place.
[00:25:42]
So you can always add effects from pure functions, but you can't take away, you know, you can't
[00:25:51]
add purity to a completely dynamic environment.
[00:25:56]
You can't put the Pandora's box back and you can never close it.
[00:25:59]
To kind of step back from the purity and everything, I think a bigger point we're getting at here
[00:26:07]
is that another thing that's really working for Elm and the Elm ecosystem is there's this
[00:26:13]
purity which now we're seeing all these meta frameworks emerging that are building on top
[00:26:19]
of this.
[00:26:20]
To me, this is something that's really working like Elm SPA, Lamdera.
[00:26:26]
I find these tools very exciting and I would love to see us doubling down on this in the
[00:26:33]
future of Elm.
[00:26:34]
I think that they're hugely valuable.
[00:26:36]
I agree.
[00:26:37]
Yeah.
[00:26:38]
And I think these things that leverage these benefits we're talking about that come from
[00:26:43]
Elm, being able to run it in multiple environments and not worry about implicit things that we're
[00:26:49]
depending on, like depending on the file system modules in Node and things like that.
[00:26:53]
Those things just aren't problems in Elm and there are so many ways you can take advantage
[00:26:58]
of those by building these sort of meta frameworks around Elm.
[00:27:02]
So I'm excited to see what emerges next.
[00:27:05]
I would love to see us doubling down on that.
[00:27:07]
So another thing that I think is really working for Elm and the Elm ecosystem is, you know,
[00:27:12]
we've talked about this before, but Elm Optimize Level 2.
[00:27:16]
To me this approach is very sustainable of essentially having these experiments that
[00:27:25]
we can iterate on quickly and we don't need any changes to Elm and the Elm compiler's
[00:27:31]
output or anything like that.
[00:27:33]
We don't need to ask Evan to change his process, which we've talked about, you know, batching,
[00:27:40]
doing explorations, exploring bold changes, all these things that really have brought
[00:27:46]
a lot of the things that we most love about Elm.
[00:27:49]
We don't have to ask him to stop doing that to go and work on these optimizations for
[00:27:55]
performance to the compiler output because, you know, Matt came up with this idea of,
[00:28:01]
hey, let's have a post processing step to apply these optimizations to the compiler
[00:28:06]
output.
[00:28:07]
And he created a platform where anybody can go and plug into that and benchmark it and
[00:28:12]
iterate on it quickly.
[00:28:13]
And we're seeing a lot of people do that.
[00:28:16]
We're seeing you adding some pull requests there.
[00:28:19]
And Robin and all these people can pitch in there and it doesn't require us to get in
[00:28:28]
a change to the Elm compiler.
[00:28:29]
So to me, that is really working and I'd love to turn that up to 11.
[00:28:34]
Yeah, also something that is very cool with that project is that from what I can see,
[00:28:40]
everyone is of the same mind in that we're trying to find optimizations that can apply
[00:28:45]
to all Elm code and not using it as a way to have native modules again.
[00:28:53]
Right, right.
[00:28:55]
Which it totally could, which you could totally do in your own project just by manipulating
[00:29:00]
the compiler JavaScript code.
[00:29:03]
But everyone that works on this project, as far as I can see, is of the mind, we're trying
[00:29:09]
some things and if they work out, we want to backport them to the compiler or make it
[00:29:16]
possible for the compiler to backport them, to use them.
[00:29:19]
That's a great point.
[00:29:20]
Right.
[00:29:21]
This is sort of like a philosophical idea that you make these changes in a way that's
[00:29:26]
not breaking the guarantees about Elm.
[00:29:29]
It's like esbuild versus Babel in a way I think encapsulates this idea that Babel, I
[00:29:38]
think, went perhaps a little bit overboard in these custom extensions.
[00:29:43]
Because if you're doing custom language extensions, then you can't fit together one project's
[00:29:49]
custom language extensions with another because it doesn't work.
[00:29:53]
The syntax highlighting tooling and the ESLint rules and all these things suddenly don't
[00:29:59]
know what to do with something.
[00:30:01]
Yeah.
[00:30:02]
I remember for instance that a lot of people used Babel or Webpack to add a way to change
[00:30:09]
their imports to other modules.
[00:30:11]
Like instead of doing required open string dot dot slash dot dot slash dot dot my file
[00:30:19]
dot JS, they wanted to do my file dot JS on its own, which is not standard, which usually
[00:30:27]
means this is a module or this is the name of a package and maybe a file inside of the
[00:30:34]
package.
[00:30:35]
And a lot of tools would have to support that.
[00:30:39]
And I remember that that was a pain.
[00:30:41]
For instance, I worked on ESLint.
[00:30:43]
For instance, I worked on ESLint plugin import.
[00:30:47]
And well, obviously we needed to support multiple ways of importing things because people added
[00:30:53]
custom things and mostly because they thought that having all those dot dots were a bit
[00:30:58]
ugly or were painful for maintenance, but it was more painful for tooling authors, arguably,
[00:31:06]
from my point of view.
[00:31:08]
And now Babel needs to support that.
[00:31:09]
And now IDEs need to support that.
[00:31:13]
And if you're doing something custom, well, maybe you do it in a slightly different way
[00:31:18]
than another project, than another tool, and that makes things just painful.
[00:31:23]
Right.
[00:31:24]
Right.
[00:31:25]
And this is not a JavaScript language design thing.
[00:31:29]
This is a sort of an ecosystem philosophy thing.
[00:31:34]
And so yeah, sorry if I bash JavaScript too much.
[00:31:37]
No, no, no.
[00:31:38]
I'm just pointing out that people could do this in Elm, but they're not.
[00:31:44]
And I hope that continues to be the case because I think that's working.
[00:31:49]
I think that in the Elm world, we really value explicitness, predictability, sort of having
[00:31:58]
one way to do it, having simple ways to express things and not going and having these custom
[00:32:07]
language extensions and things like that because it becomes unsustainable and it really breaks
[00:32:15]
all these things in the ecosystem.
[00:32:18]
So I mean, if Elm review started having to handle custom syntax extensions or custom
[00:32:25]
semantics and things, that would really start to break a lot of assumptions in tooling.
[00:32:31]
So anyway, esbuild has more of this philosophy of, in contrast to Babel's ability to write
[00:32:37]
these custom plugins, esbuild is starting to rein that in and say, hmm, let's not have
[00:32:42]
it be customizable.
[00:32:44]
Let's only support sort of future syntax.
[00:32:47]
So I can transpile es2022, 2023 stuff into es2015 syntax, but it's standard syntax that
[00:32:57]
everybody can sort of get behind these same standards.
[00:33:00]
So I like that philosophy and I'm glad we're seeing more of that in Elm.
[00:33:05]
And so yeah, back to that point about Elm optimize level two, like you were saying,
[00:33:10]
it can go back upstream.
[00:33:11]
So we can do all these experiments, we can iterate and find the best way to tune in that
[00:33:17]
performance of the JavaScript output of the Elm compiler.
[00:33:21]
And then once that's really matured and stabilized and we've found, you know, Robin did a great
[00:33:27]
series of posts about some experiments he's been doing there.
[00:33:31]
Those experiments don't need to happen in the Elm compiler itself.
[00:33:35]
They can happen in this external thing with very rapid iteration.
[00:33:39]
And then once we've sort of sorted that out and it's matured and stabilized, then they
[00:33:43]
can make their way back into the Elm compiler.
[00:33:45]
So to me, that's really working and I would love to see more things taking that approach.
[00:33:52]
And I think that having these external tools that don't make, you know, changes to the
[00:33:59]
Elm compiler bottleneck is something that really works for Elm.
[00:34:03]
For example, from the early days, Elm format has been that way.
[00:34:06]
It's been an independently managed tool.
[00:34:09]
And I think, you know, Evan has done a really great job of, you know, sort of giving his
[00:34:15]
insights to tooling authors, connecting with them and, you know, he'll do calls with people
[00:34:21]
and share his thoughts and give ideas.
[00:34:25]
And he's got a really great vision to sort of help people think through these things.
[00:34:31]
So I think that really works.
[00:34:34]
And I think that's a recipe for success in the Elm community.
[00:34:37]
So I'd love to see more of that.
[00:34:39]
Yeah.
[00:34:40]
So being disconnected from the compiler outputs, right?
[00:34:43]
Yes, exactly.
[00:34:44]
Decoupled.
[00:34:45]
Decoupled architectures.
[00:34:46]
Yeah.
[00:34:47]
If we go back to the JavaScript ecosystem again, that's also very true in the sense
[00:34:54]
that most open source projects over there, they don't rely on the browser, what features
[00:35:04]
the browser supports or how it works.
[00:35:07]
Nobody creates a tool like Webpack and expects the Chrome team to implement a new feature.
[00:35:14]
They expect them to support the standards, the web standards, but that's it.
[00:35:21]
Yeah.
[00:35:23]
I've sort of, I've shared my thoughts quite a bit on this topic, but I think it's relevant
[00:35:27]
here too about the Extensible Web Manifesto and this idea that, you know, these sort of
[00:35:34]
browser standards teams learned this lesson from shipping this app cache API that was
[00:35:41]
trying too hard to solve every problem and be custom tailored for specific use cases.
[00:35:47]
And then they realized, you know what?
[00:35:49]
We're failing to solve every use case, but we're not going to be able to solve every
[00:35:54]
use case as the platform team.
[00:35:56]
And in fact, that's not what a platform should be doing.
[00:35:58]
A platform should be providing robust building blocks that people can use to solve their
[00:36:05]
use cases.
[00:36:06]
So people shouldn't be stuck in a dead end where they can't solve their problem for their
[00:36:10]
use case because the platform doesn't provide the right building blocks.
[00:36:14]
And those building blocks should be robust and work well and should consider the core
[00:36:21]
security concerns and the core problems that could occur.
[00:36:25]
For example, an app cache getting into a state where you can never bust the cache and users
[00:36:30]
are stuck seeing the same page.
[00:36:32]
That should never be able to happen.
[00:36:34]
That sounds lovely.
[00:36:35]
The platform should have those guarantees baked in.
[00:36:38]
And then the application code can take those building blocks and safely build things with
[00:36:43]
them.
[00:36:44]
Right?
[00:36:45]
So I see that as a really great like philosophy.
[00:36:49]
And I think that I see that as a recipe for success that the platform shouldn't be trying
[00:36:56]
to solve every single use case.
[00:36:58]
They should be providing simple, powerful, robust building blocks.
[00:37:03]
So I think Elm should stay focused on that as well.
[00:37:06]
I mean, Elm doesn't give you the building blocks for everything when it comes to web
[00:37:12]
standards.
[00:37:13]
But it at least gives you the escape hatch that you need to use those building blocks.
[00:37:18]
So ports and web components.
[00:37:20]
Yeah, I think web components are probably underused.
[00:37:23]
Like I'd like to see more of that.
[00:37:25]
And I'd like to see more like people encapsulating shareable web components that can be used
[00:37:31]
nicely in Elm code.
[00:37:33]
For example, like web components can have custom events that they can emit.
[00:37:40]
And we could see sort of shareable like web component definitions and Elm handlers for
[00:37:49]
decoding those custom events that they emit, for example, right?
[00:37:52]
I would love to see us kind of doubling down on that.
[00:37:56]
So another thing I think that's really like working for Elm is Elm has this architecture,
[00:38:02]
the Elm architecture.
[00:38:03]
This is how Elm works.
[00:38:05]
And like in the React ecosystem, there seems to be so much churn around these different
[00:38:11]
like data layers, which has its pros and cons.
[00:38:15]
But I think a lot of people find it very frustrating that they're like, okay, now, Redux is the
[00:38:20]
thing.
[00:38:21]
And then suddenly everybody's like, now we're done with Redux.
[00:38:24]
That's not the way to do it anymore.
[00:38:26]
And then everything is using hooks and everything is going to these different React query or
[00:38:33]
different data layers.
[00:38:35]
Even when you use Redux, you have the choice to use Redux Thunk, Redux Sega, and other
[00:38:42]
things to do asynchronous events or actions, I guess.
[00:38:50]
And just that choice changed your entire application structure.
[00:38:56]
Yes, exactly.
[00:38:57]
And then certain things don't fit together.
[00:38:59]
And you have to think about what fits together and the ecosystem has to like these core building
[00:39:05]
blocks churn and then everything around it has to churn.
[00:39:08]
And so anyway, I'm just very happy that that's baked into Elm.
[00:39:13]
And it's like a very thoughtfully designed approach that works really well with all of
[00:39:19]
Elm's language guarantees and purity and stuff.
[00:39:22]
The Redux had limitations with this pattern being applied in JavaScript because things
[00:39:27]
like pure functions and managed effects don't really work that well in that context.
[00:39:32]
But in Elm, it works.
[00:39:33]
Everything works together cohesively and we don't have to churn and experiment around
[00:39:38]
this thing.
[00:39:39]
We can experiment around other things.
[00:39:41]
And similarly, I think that just the simplicity of Elm and having one way to do things and
[00:39:51]
leveraging the same tools to do more things is really working for Elm.
[00:39:56]
So that's something I'd like to continue to see.
[00:39:58]
I think we really benefit a lot from that.
[00:40:01]
One aspect that I think is very important is that a lot of innovation is brought by
[00:40:05]
people that are passionate about a topic.
[00:40:08]
So for instance, I was passionate about static analysis through my work with the East End
[00:40:13]
before I joined the Elm community.
[00:40:17]
So I was well suited to add Elm review and a tool like that to the ecosystem.
[00:40:25]
There was Elm analyze, which helped me a lot as an inspiration, but which had different
[00:40:30]
goals.
[00:40:31]
I had all the tools necessary.
[00:40:33]
I had all the building blocks necessary and all the data that I needed to create an amazing
[00:40:39]
tool.
[00:40:40]
And I think that is true for all the tools that we mentioned already and some that we
[00:40:45]
haven't.
[00:40:46]
And I think that having people explore and experiment with something that they're passionate
[00:40:52]
about is very important.
[00:40:54]
So we mentioned the error messages.
[00:40:57]
That was Evan being interested, curious about good error messages and spending some time
[00:41:04]
to work on it.
[00:41:06]
And that just happened to be Evan who worked on the compiler, but it could have been someone
[00:41:10]
else who might have done a fork of Elm for a while in his own backyard and then suggested
[00:41:21]
it to Evan.
[00:41:22]
I don't know how that one would have worked.
[00:41:24]
The same thing happens for Elm test.
[00:41:26]
Someone was passionate about having a good test framework for Elm and worked on that.
[00:41:33]
And with fuzzing baked in, which is not, you don't see that that often that a testing framework
[00:41:39]
has fuzzing built in and a very thoughtful fuzzing API.
[00:41:42]
I know a lot of people put a lot of thought into that API.
[00:41:47]
And then we have other tools like Elm JSON, which someone felt like the Elm compiler was
[00:41:53]
lacking as to the commands that it provided to install packages.
[00:41:59]
And now we have Elm JSON, which is amazing.
[00:42:01]
And hopefully there will be backboard to the Elm compiler at some point for sure.
[00:42:06]
And for people who aren't aware, we should say this, if you do npm install dash G global
[00:42:14]
Elm dash JSON, this is not like Elm dot JSON files.
[00:42:18]
This is an npm installable tool.
[00:42:21]
I think it's built in Rust, of course, as one does, called Elm JSON.
[00:42:25]
And it helps you install Elm dependencies, upgrade Elm dependencies, resolve Elm dependencies.
[00:42:31]
Yes.
[00:42:32]
So someone felt that pain and aimed to solve it.
[00:42:37]
It didn't require evidence work, evidence participation.
[00:42:41]
And now we have it.
[00:42:43]
We're unblocked on that matter.
[00:42:45]
Exactly.
[00:42:46]
I totally agree.
[00:42:47]
To me, I sometimes think of this as like the Apple approach of like, let people innovate.
[00:42:55]
And then once something is very obviously a good idea, then you steal it.
[00:43:02]
Of course, with Apple, they're stealing things from developers who are getting paid for these
[00:43:09]
tools and then suddenly they take it over and destroy their business maybe.
[00:43:13]
And maybe that's not great.
[00:43:14]
But for something like Elm optimize level two compiler optimizations and Elm JSON and
[00:43:21]
tooling like that, if it gets sucked up by the Elm compiler, then it's a win for everybody.
[00:43:27]
Nobody's getting their businesses lost by that.
[00:43:32]
But that said, Apple does this thing where they'll let people build these external display
[00:43:38]
tools where they find a way where you can plug in an iPad and display an external display
[00:43:44]
based on that.
[00:43:45]
And then Apple kind of sits back and sees the innovation happening.
[00:43:49]
And then they say, hmm, it seems like people really like this.
[00:43:52]
All right, this is going to be part of the next OS release.
[00:43:57]
And then they release sidecar.
[00:43:58]
But anyway, I mean, I think that's actually not a bad recipe for a large open source project,
[00:44:06]
like a programming language.
[00:44:08]
Yes.
[00:44:09]
But also all of those changes that may be stolen in a way, they all need to make sense.
[00:44:17]
So they need to fit the Elm philosophy culture maybe as well.
[00:44:24]
And they need to be compatible upstream and not be doing syntax extensions or things like
[00:44:29]
that.
[00:44:30]
Yeah.
[00:44:31]
Yes.
[00:44:32]
Or maybe as a proposal and then see how it goes.
[00:44:37]
But yeah.
[00:44:38]
Absolutely.
[00:44:39]
I really like this general approach of just build something that's independently useful
[00:44:47]
but also could be useful if it's pulled in upstream to an official thing or the Elm compiler
[00:44:54]
or not.
[00:44:55]
And I mean, for example, Elm format.
[00:45:00]
I think Go and Elixir and a lot of other languages have these things built into the core and
[00:45:08]
the core executable for these tools handles that.
[00:45:14]
And that might work for those ecosystems.
[00:45:16]
But for Elm, it just works so well to have an independently maintained Elm format tool.
[00:45:23]
I just think that that's the right approach for Elm and for making the most of Evan's
[00:45:31]
approach, which he's been very thoughtful about.
[00:45:34]
And I think people spend so much energy thinking about how it could be different rather than
[00:45:40]
saying how do we make the most of it and work with what we've got.
[00:45:45]
So I'd like to see more of these tools that work in a decoupled way because in my view,
[00:45:52]
they really just are better suited to the way the Elm works.
[00:45:56]
And why sort of imagine that things are going to work a different way when we can sort of
[00:46:02]
see things that are working and do more of those things.
[00:46:06]
So let's say we had a different flavor of Elm popping up.
[00:46:10]
How do you think that that would work out?
[00:46:12]
My point of view is that it could be better in some ways, and I hope it would be otherwise.
[00:46:17]
Why would you even start it?
[00:46:20]
But a lot of the things that we have in the Elm community and mostly tooling would probably
[00:46:26]
not work.
[00:46:27]
And that would be a giant waste.
[00:46:30]
So if you added a different flavor of Elm with new syntax or a different way of how
[00:46:39]
it operates, then maybe Elm review would not be compatible with it.
[00:46:44]
Maybe Elm GraphQL would not work with it.
[00:46:46]
Elm formats, Elm tests.
[00:46:49]
And as I mentioned in the JavaScript ecosystem, every time a new tool comes up or a new custom
[00:46:57]
extension to the language, well, now everything needs to support it.
[00:47:01]
And that is a pain for everyone.
[00:47:04]
Yes, exactly.
[00:47:06]
I totally agree.
[00:47:08]
And just to be clear, you're talking about if there were like a fork of Elm with a different
[00:47:16]
name, but something that forked Elm.
[00:47:19]
And yeah, I totally agree if it were to sort of change any semantics or syntax guarantees,
[00:47:29]
change anything regarding native code.
[00:47:32]
I mean, suddenly, if there are changes in native code and things like that, Elm review
[00:47:39]
doesn't work anymore because things that are safe changes are no longer safe.
[00:47:43]
Things that are unused might be used perhaps, or who knows, you just can't analyze things
[00:47:48]
the same way.
[00:47:49]
So yeah, I think in my opinion, I wouldn't find that interesting.
[00:47:55]
I wouldn't find that to be a useful project if something forked Elm and diverged in a
[00:48:03]
way that was irreconcilable with the core Elm semantics and syntax we have now.
[00:48:09]
I wouldn't find that interesting personally.
[00:48:12]
If someone else finds that interesting, good for them.
[00:48:15]
That's great.
[00:48:16]
That's just my personal opinion.
[00:48:18]
But to me, it would not be something that I would be interested in.
[00:48:21]
If there were a fork of Elm that used the same semantics and syntax as Elm, I would
[00:48:30]
be concerned about splitting the community and creating confusion there.
[00:48:38]
That would be my biggest concern.
[00:48:40]
I'd be concerned about...
[00:48:41]
Do you mean the user space or the tooling author space or both?
[00:48:46]
Yeah, where are packages published and are people confused about publishing things in
[00:48:52]
different places?
[00:48:54]
Are people confused about whether to use this one or that one?
[00:49:01]
Sometimes you need to look at the Elm documentation.
[00:49:03]
Sometimes you need to look at the fork documentation.
[00:49:06]
Exactly.
[00:49:07]
And here's the thing.
[00:49:10]
I think that forking...
[00:49:13]
What do we mean by forking?
[00:49:15]
There was a post, I'll try to dig up the link and find it, but there was a post recently
[00:49:19]
that was talking about this of like, what do you mean by forking?
[00:49:23]
Do you mean creating a snapshot in time where you make a couple of changes?
[00:49:28]
Or do you mean actively maintaining a large scale project and community around it?
[00:49:34]
Those are two very different things.
[00:49:36]
The post that was talking about this was talking about it in the context of Electron and like,
[00:49:41]
all right, you want to fork Electron?
[00:49:43]
Well, let's talk about what that would actually look like to maintain an active fork of Electron.
[00:49:49]
And then let's talk about if that's what you want to do.
[00:49:51]
But anyway, I think it's quite ambitious and I think it's a lot easier said than done.
[00:49:59]
So I would be very skeptical of that being something that's actively maintained and that's
[00:50:08]
going to be done in a way where it doesn't create confusion around where to find things
[00:50:13]
and that sort of thing.
[00:50:15]
So that said, people can do what they want to do, but those would be my concerns.
[00:50:20]
But what I see as the blueprint for success are again, let's look to the successes we've
[00:50:27]
had in the community so far and how can we use those things that we've seen be very successful?
[00:50:34]
In my opinion, Elm format has been wildly successful.
[00:50:39]
Now it's just the status quo.
[00:50:42]
But if you take it away, I would be very sad.
[00:50:45]
If it disappeared from my life, then I just would be useless.
[00:50:52]
I'd have to go build it before I could work in Elm.
[00:50:56]
It's just like part of how I write Elm these days.
[00:50:59]
So it's been wildly successful.
[00:51:03]
I think other projects can be similarly wildly successful.
[00:51:08]
I think that we can, how can we create a decoupled approach to improving Elm?
[00:51:16]
I'd love to double down on that because I see a lot of success from that approach.
[00:51:20]
As I mentioned earlier, if there is a big fork of Elm in the sense that it's an entirely
[00:51:27]
new project with a new community, with new ways of working, you were saying you were
[00:51:33]
concerned about splitting the community and tooling would be one part of that because
[00:51:39]
yeah, you wouldn't have Elm format, you wouldn't have Elm review, you wouldn't have Elm Graph
[00:51:43]
QL, you wouldn't have Elm test.
[00:51:45]
And all those authors would have to, well, sometimes be brought back from the dead because
[00:51:53]
Elm tools are just working, don't have a maintainer anymore, I guess.
[00:51:57]
Not the ones that I've just mentioned, but, and they would all have to be convinced to
[00:52:02]
be moved or copied to the other fork.
[00:52:08]
And that's a lot of work, one, to convince them and then to actually do the work.
[00:52:14]
And we don't have that much time in the sense that I don't think there's many projects in
[00:52:22]
the Elm community that have more than two or three maintainers.
[00:52:25]
And even those are the exception rather than the rule.
[00:52:31]
I think most of them have one main maintainer and then a few people who help here and there
[00:52:40]
sometimes.
[00:52:41]
Yeah.
[00:52:42]
I mean, I think it could potentially be done in a way where it doesn't depend on people
[00:52:46]
like republishing packages or something like that, but it's something to be aware of.
[00:52:51]
And anyway, I mean, I think if somebody is taking on a project like that, I guess I have
[00:52:57]
a very skeptical eye about this idea of that solving a lot of problems.
[00:53:04]
To me, my concern would be that it would introduce more problems than it would solve.
[00:53:09]
And so that's why if somebody were to do it, I think, I hope they would consider the points
[00:53:17]
we're talking about of being cohesive with the upstream Elm and that sort of thing, and
[00:53:27]
not creating a divergence where it's changing semantics and things in ways that are irreconcilable.
[00:53:35]
I mean, for instance, ElmJSON copies the same behavior as Elm in a way and acts as a replacement
[00:53:47]
when you want to install packages, but it doesn't create an entirely different fork
[00:53:52]
of the language.
[00:53:54]
Which Lamdera does too, actually.
[00:53:56]
And Lamdera actually happens to be a fork of the Elm compiler.
[00:53:59]
We don't think of it as such because it is essentially like a swappable Elm.
[00:54:06]
It attempts to preserve all of our expectations about Elm, but it does do certain things that
[00:54:14]
Elm doesn't, in particular, running certain things in the backend and maintaining these
[00:54:20]
server side things and that sort of thing.
[00:54:21]
So yeah, I think that that's been successful for that particular approach.
[00:54:28]
But if somebody is purely just trying to patch some things about the way that Elm works,
[00:54:34]
I would be skeptical of that being the best way to solve those particular problems.
[00:54:39]
And I would look more to the types of things that we've been discussing that have been
[00:54:45]
success stories that we can look to as a blueprint.
[00:54:48]
Because Elm is all in all pretty much a language that we just love.
[00:54:53]
Yeah.
[00:54:54]
Yeah.
[00:54:55]
It is just so good on so many aspects that it doesn't require much changing or much evolution
[00:55:03]
actually even.
[00:55:04]
Right.
[00:55:05]
Right.
[00:55:06]
And it's a simple language.
[00:55:08]
There's just and I love that about it.
[00:55:11]
There's just there aren't that many ways to express things with alternate syntax and things
[00:55:17]
like that.
[00:55:18]
But the innovation happens around that simple core.
[00:55:24]
Another thing that is working very well for Elm that again, I think we sort of forget
[00:55:31]
because we get used to things just like we get used to Elm format being baked into our
[00:55:36]
process.
[00:55:37]
But the Elm 19.1 compiler performance is insane.
[00:55:43]
And that is really working well.
[00:55:47]
I mean, I hear a lot of people like going to build things in Haskell or Rust or these
[00:55:53]
other tools with a lot of these language features that us Elm folks really appreciate.
[00:56:00]
But then they're like, but the compiler feedback loop is so much faster in Elm.
[00:56:06]
And it makes such a difference to that iteration cycle.
[00:56:09]
I mean, it doesn't.
[00:56:10]
Yes.
[00:56:11]
It even allows us to do some things that we otherwise would not probably.
[00:56:17]
For instance, Elm review compiles the configuration.
[00:56:21]
I think Elm pages also does something like that.
[00:56:24]
It does.
[00:56:25]
It actually compiles in the dev server.
[00:56:28]
If you like change a file or add a file that is depended on by a data source, it recompiles
[00:56:35]
and executes that data source and sends the data back to the dev server and hot reloads
[00:56:41]
in that data, as well as also recompiling the Elm code and shipping that back with a
[00:56:48]
hot reload.
[00:56:49]
So, yeah, if it wasn't fast, that wouldn't be possible.
[00:56:53]
Yeah.
[00:56:54]
So you wouldn't want to use Elm review if it wasn't that fast.
[00:57:00]
If it took like a whole minute just to compile your configuration, then that would be an
[00:57:06]
entirely different experience.
[00:57:09]
People would maybe still use it, but it wouldn't be the same thing.
[00:57:14]
And if the compilation process was more complex, for instance, every time I hear people talking
[00:57:21]
about Haskell and choosing stack or cabal or whatever, that is just very painful to
[00:57:30]
set up from what I understand and from what I have tried.
[00:57:34]
Whereas with the Elm compiler, you just run Elm make, you already have an Elm JSON file,
[00:57:38]
and things happen in a sound way and in a fast way, and that makes everything much,
[00:57:45]
much simpler.
[00:57:47]
So we wouldn't have Elm review and Elm pages the way that they are today if the Elm compiler
[00:57:52]
was not fast and did not behave the way it does, is basically what I'm trying to say.
[00:57:57]
Great.
[00:57:58]
Yeah.
[00:57:59]
Yeah.
[00:58:00]
And another thing that I actually have on my list here of things that are working are
[00:58:05]
I think that leveraging these qualities of Elm for performance.
[00:58:10]
So for example, the fact that Elm has been really competitive in these sort of, you know,
[00:58:15]
really competitive in these sort of frontend framework performance metrics and benchmarks.
[00:58:20]
When it's doing these things that you would think of as not performant, like immutability
[00:58:27]
and not to mention targeting JavaScript, which is this very tricky thing to optimize for
[00:58:36]
because it's got all these just in time optimizations and things.
[00:58:39]
But even without, you know, like there have been so many optimizations that, you know,
[00:58:46]
you and Robin in the past couple of months have been finding these like big performance
[00:58:50]
gains that have been making their way into Elm optimized level two.
[00:58:54]
But even without those, Elm is so competitive and it seems like we're just scratching the
[00:58:58]
surface of what performance could be for Elm.
[00:59:01]
So leveraging this purity for making performance optimizations, I think is very interesting
[00:59:09]
because Elm is a limited, you know, runtime.
[00:59:14]
The sort of update cycle, you know, if it compiled to WASM at some point, imagine how
[00:59:21]
we could double down on performance there by taking these sort of assumptions that we
[00:59:26]
know about how Elm uses data and allocating memory in a way that's tailored for that and
[00:59:32]
that sort of thing.
[00:59:33]
There's so much we can do by taking advantage of these qualities that Elm has for performance.
[00:59:40]
And we already see a lot of them and we could double down on that.
[00:59:44]
And you know, like HTML lazy, I love how that is something that you can drop in.
[00:59:51]
And the most dangerous foot gun that it has is not that you'll have incorrect information
[00:59:57]
where you're telling it something has not changed, but it actually has changed and become
[01:00:02]
Dale, which you can do with a lot of these other front end framework optimizations.
[01:00:07]
The biggest foot gun is that you accidentally pass in a new type of data rather than something
[01:00:12]
that is referentially going to be equal and the optimization doesn't kick in.
[01:00:16]
That's the worst that can happen.
[01:00:19]
Which is basically just comparing two JavaScript arrays extra.
[01:00:25]
That is the entire penalty.
[01:00:27]
It's not getting the optimization you expected, that's the worst thing that can happen.
[01:00:33]
So anyway, I think that these things are really cool, taking advantage of Elm's purity and
[01:00:39]
the language itself for performance.
[01:00:42]
So another thing, kind of stepping back a little bit more to the community, because
[01:00:48]
you and I think a lot about this.
[01:00:49]
I think that, well, what's working for Elm?
[01:00:53]
I've got to say, there's a certain podcast that I think is working very well for Elm,
[01:00:58]
if I do say so myself.
[01:01:00]
I wonder which one you mean.
[01:01:05]
I've certainly been enjoying that.
[01:01:07]
But I would love to see more content in the Elm ecosystem.
[01:01:12]
We've been seeing some cool stuff coming out lately, but I would love to see people sharing
[01:01:18]
more.
[01:01:19]
So the Elm conferences have been such high, I've been so impressed with the quality of
[01:01:26]
talks at Elm conferences and the organization of Elm conferences.
[01:01:30]
I am going to include conferences under things that are working for Elm and the Elm ecosystem
[01:01:37]
in my list, even though there is of course a caveat, which is now, I think that global
[01:01:43]
pandemics are not working so great.
[01:01:48]
If we could turn that knob down.
[01:01:50]
Turn that knob down.
[01:01:51]
Exactly.
[01:01:52]
Yes.
[01:01:53]
That's the one knob I'm going to...
[01:01:55]
We're focusing on turning knobs up, but that is one knob that I think we can agree would
[01:01:59]
be nice to turn down.
[01:02:02]
But conferences have been working so well, and I hope that they will reemerge when things
[01:02:08]
sort of settle down in the global landscape here.
[01:02:11]
But it has been cool to see Elm online as a consistent global virtual platform for Elm
[01:02:19]
talks popping up.
[01:02:20]
That's been really great.
[01:02:21]
And also just some people are making videos on YouTube regularly.
[01:02:28]
That is a nice source of content if you are looking for some.
[01:02:31]
Exactly.
[01:02:32]
Yeah.
[01:02:33]
So let's talk about that for a second.
[01:02:36]
So if people want to be the change they want to see in the Elm ecosystem, what do you think
[01:02:42]
that looks like?
[01:02:43]
Like what are some things that...
[01:02:45]
Because I think that it's...
[01:02:47]
I think we should be careful when turning things up to 11.
[01:02:50]
There's a difference between telling someone to turn something up to 11 versus you realizing
[01:02:57]
that you can help to turn that knob up to 11.
[01:03:00]
So what are some things you think that people have in their power to turn up to 11?
[01:03:05]
I think people should go for what they're passionate about.
[01:03:09]
If you're passionate about static analysis tools, then build one, then contribute to
[01:03:16]
one, explore things that are new, explore things that are old.
[01:03:21]
Just work on it and then share it and ask people for feedback, which is not always very
[01:03:27]
easy because we are a pretty small community.
[01:03:30]
But I think we have a community that is pretty excited in the sense that if we see new cool
[01:03:38]
things, then we get excited as well.
[01:03:46]
Sometimes getting that excitedness across is a bit hard, but yeah, work on something
[01:03:51]
that you feel passionate about.
[01:03:53]
Share it on discourse, on Twitter, on Reddit, on Hacker News if you are bold and brave,
[01:04:02]
and then see how people reply to it.
[01:04:04]
I would really urge to try and follow the Elm philosophy about making tools that work
[01:04:12]
well across the whole community, that have the same ideas of having greater user experience,
[01:04:19]
greater error messages, being helpful, being delightful.
[01:04:24]
If you try to incorporate all of those, which you don't have to do to begin with, then I
[01:04:30]
think you will get somewhere that will help people and you will find other people to help
[01:04:35]
you out.
[01:04:36]
Yeah, I think that's a great message.
[01:04:39]
I want to add to that that to contribute, let's say we're talking about a tool or a
[01:04:46]
package, you don't need to be the author or lead maintainer of a tool or package to be
[01:04:53]
contributing.
[01:04:57]
Actually this is part of this Elm philosophy tweet that Evan wrote, which we'll link to
[01:05:02]
in the show notes.
[01:05:03]
Well, let me just read a few of these points because I think they're very relevant to this
[01:05:07]
point of how people can contribute.
[01:05:09]
It starts with be kind.
[01:05:12]
That's one thing to keep in mind.
[01:05:14]
Learn from everyone, collaboration requires communication.
[01:05:18]
Not every problem should be solved with code.
[01:05:21]
Communication is contribution.
[01:05:23]
Understand the problem.
[01:05:24]
Explore all possible solutions.
[01:05:26]
Pick one solution.
[01:05:29]
Don't try to be every solution.
[01:05:31]
Simplicity is not just for beginners.
[01:05:33]
It's better to do it right than to do it right now.
[01:05:35]
It's not done until the docs are great.
[01:05:37]
Take responsibility for user experiences.
[01:05:39]
Make impossible states impossible and there are worse things than be explicit.
[01:05:43]
I just love all those points.
[01:05:48]
We've talked about them at length, but always good to have a refresher.
[01:05:53]
By the way, those things are really working for Elm and those philosophical ideas, you
[01:05:58]
really do see them all the way running through all of the Elm ecosystem, I think.
[01:06:04]
If somebody wants to contribute, you can write an Elm review rule.
[01:06:08]
You can contribute to an Elm review rule.
[01:06:10]
You can see something.
[01:06:12]
I've been seeing a lot of people making some great contributions to projects that I maintain
[01:06:18]
recently and I really appreciate it.
[01:06:22]
I try as much as possible to trust people to take ownership when there's something that
[01:06:27]
they're passionate about.
[01:06:29]
I'll try to be there to help them understand how it can fit into a project and that sort
[01:06:36]
of thing.
[01:06:37]
I try as much as possible to just trust them to solve the problem and use their creativity
[01:06:43]
to do so.
[01:06:44]
I really appreciate it when people do that.
[01:06:47]
You don't need to be a lead maintainer or create a new project to contribute in some
[01:06:51]
way.
[01:06:52]
There are a lot of ways to contribute.
[01:06:53]
In fact, even just sharing your feedback is a form of contribution.
[01:06:57]
Also just writing a blog post or talking about Elm at a conference, and maybe even more so
[01:07:05]
at non Elm conferences to get the language out there even more than it is today.
[01:07:12]
Those are helpful.
[01:07:13]
Even if you just blog about your favorite tool which might or might not be Elm review,
[01:07:22]
it makes us feel good and it will be helpful for other people, I'm sure.
[01:07:27]
Those things make a difference.
[01:07:30]
You never know what impact it's going to have, but it's actually people writing blog posts,
[01:07:36]
just sharing their experiences or sharing how to do something that they wish they'd
[01:07:41]
known how to do when they started.
[01:07:44]
Those things can go such a long way.
[01:07:46]
If you do want to write a blog post or you want to contribute to a project, be sure to
[01:07:53]
turn that knob to 11.
[01:07:55]
Write plenty of blog posts and plenty of contributions.
[01:08:04]
Only if you see that it works.
[01:08:08]
Yes.
[01:08:10]
I think that people have more power at their fingertips than they realize.
[01:08:16]
I think that's one message I'd like to give to people that every little thing counts.
[01:08:24]
Even if you're not turning a knob all the way up to 11 by yourself, even if you're just
[01:08:29]
nudging that knob a little bit, it makes a difference.
[01:08:33]
It's not like you and I were granted godly permissions from the Elm core team to do something.
[01:08:43]
No, we did stuff because we felt passionate about them and they worked out well.
[01:08:50]
They may not work well, but in our case, they did.
[01:08:53]
I'll say for as far as specifically open source projects go, man, when I look back, it's kind
[01:09:02]
of fun looking back at early open source projects.
[01:09:05]
But I've been dabbling in open source for a long time.
[01:09:12]
Even as early as when I was at my first job after college around 2013, I was creating
[01:09:20]
open source like, did anyone use them?
[01:09:24]
I used them a little bit, kind of.
[01:09:27]
I made a simple little Ruby command line tool to help do some high level git things.
[01:09:36]
Was it useful?
[01:09:37]
Probably the most interesting thing about it was the name of the project, which was
[01:09:41]
legit, which is a play on words.
[01:09:45]
It's probably the most impressive thing about the project, which is saying a lot.
[01:09:50]
Is it a play on words?
[01:09:51]
Please explain it to us.
[01:09:53]
As we know, jokes are at their best when they're fully explained.
[01:09:57]
Did you just explain my joke?
[01:10:01]
Perhaps I did.
[01:10:05]
It takes practice to get good at finding things that will be useful for other people.
[01:10:12]
But hey, if it's useful for you, then at least you know it's useful for one person.
[01:10:17]
Parts of my contributions were always to scratch my own edges.
[01:10:24]
My own edges and then the ones from my teammates.
[01:10:28]
And then sometimes they turn out to be useful for other people.
[01:10:38]
This is just my personal value system, I guess.
[01:10:42]
But I really like trying to fit into the existing way of things working as much as possible,
[01:10:48]
rather than trying to say everything should be different about this, that everything needs
[01:10:54]
to be changed.
[01:10:55]
I really like to say, what is working about the way things are being done and how can
[01:11:01]
I contribute given the way things are working?
[01:11:06]
For example, you look at TypeScript and TypeScript is saying, all right, we've got this JavaScript
[01:11:12]
code.
[01:11:13]
This is kind of here to stay.
[01:11:16]
This is how JavaScript works.
[01:11:18]
Are there a few semantics and things that could be cleaned up to make it easier to build
[01:11:23]
a type system around?
[01:11:25]
Sure.
[01:11:26]
And people have created type systems that are simpler and require less work to architect.
[01:11:34]
But we want to take JavaScript and help people who have JavaScript code.
[01:11:40]
And so let's build an incremental thing that fits into your JavaScript code bases and helps
[01:11:45]
you with that.
[01:11:46]
Right.
[01:11:47]
And so how can we do things that fit into the way that Elm works, the way the Elm ecosystem
[01:11:53]
works, the way people are using Elm?
[01:11:56]
And we see all these great examples of that, that really add right now.
[01:12:02]
And could they become some official part of Elm tooling at some point?
[01:12:08]
Maybe.
[01:12:09]
Maybe they need to be.
[01:12:10]
I mean, in a lot of cases, a project being valuable doesn't depend on that.
[01:12:17]
Maybe Elm optimized level two will never make its way upstream into Elm.
[01:12:22]
And that wouldn't be the worst thing in the world.
[01:12:24]
What might we get instead?
[01:12:26]
What will the next better error messages of Elm be?
[01:12:31]
And what would you rather have, the next better error messages of Elm or the Elm optimized
[01:12:36]
level two changes making their way upstream?
[01:12:39]
You know, maybe we'll get some WASM stuff instead of that or something that wasn't even
[01:12:44]
on our radar.
[01:12:46]
And we were asking for a faster horse and we get a car.
[01:12:49]
So anyway, like I just I think that I'm a believer in not expecting people to change
[01:12:57]
the way things are being done, but instead saying, given the way things are right now,
[01:13:02]
how can I be of help?
[01:13:04]
How can I contribute to this thing that I want to improve?
[01:13:07]
We need like a the more you know, public service announcement message now.
[01:13:14]
This entire episode was a public announcement message.
[01:13:18]
Yeah.
[01:13:19]
I mean, I hope that I hope that it comes through that Jeroen and I are genuine in our thoughts
[01:13:26]
that we're sharing here.
[01:13:28]
People might not see things the same way as we do here, but we're trying our best to share
[01:13:33]
our perspectives here and sometimes, sometimes conversations can have a lot of voices.
[01:13:41]
And we wanted to add our voices to this conversation about the state of Elm for the record.
[01:13:49]
So we could kind of put in a different perspective.
[01:13:52]
And since you listener cannot have a conversation with us through this podcast format, you can
[01:13:59]
reply to us through discourse or Twitter, where we can continue this conversation if
[01:14:05]
you want to.
[01:14:06]
Yes, we always love hearing from people and having a conversation.
[01:14:10]
And also, if anybody wants to, you know, inspire it at all to be the change they want to see
[01:14:16]
in the Elm ecosystem, Jeroen and I, I think it's fair to say are always very happy to
[01:14:22]
help out any way we can talk things through, point you to the right place.
[01:14:26]
If you want to bounce an idea, there are places to do that, too.
[01:14:29]
There's a great API design channel in the Elm Slack, but we're here to help how we can
[01:14:35]
as well.
[01:14:36]
All right.
[01:14:37]
Have we shared all of our thoughts?
[01:14:41]
I think so.
[01:14:42]
I think so.
[01:14:43]
And I will just say for the record, every time before Jeroen and I record, every time
[01:14:48]
he says, I don't think we'll have that much to say.
[01:14:52]
That means it's going to be a long episode.
[01:14:54]
That's how you know.
[01:14:57]
Yeah.
[01:14:58]
Well maybe I'll just end up saying it every time just so that we have longer episodes.
[01:15:01]
That's right.
[01:15:02]
Exactly.
[01:15:03]
Which by the way, let us know if you like shorter or longer episodes.
[01:15:07]
I don't know.
[01:15:08]
Feedback is always welcome.
[01:15:09]
So we can turn that knob all the way up to 11.
[01:15:11]
Yes.
[01:15:12]
If you want longer episodes, we'll turn it to 11.
[01:15:15]
11 hours of content per episode.
[01:15:19]
Beautiful.
[01:15:20]
Beautiful.
[01:15:21]
Well, I look forward to seeing what 2022 brings with turning up those knobs to 11 and Jeroen.
[01:15:32]
Until next time.
[01:15:33]
Until next time.