Hello, Dillon.

And today we've got another guest joining us, Martin Stewart. Thanks so much for being on the show, Martin.

Hello. I'm so glad to hear you two say that. I love the intro.

Yeah. Well, we've been meaning to have you on for a long time, so it's great to finally get you on.

There are lots of things we could talk about with you, but today we're talking about the State of Elm 2022.

All right. Looking forward to it.

Yeah. So, well, first of all, what is the State of Elm and why gather this data?

What was your motivation? Why did you care about there being a State of Elm 2022, unlike 2021, 2020, 2019, when there wasn't a State of Elm?

Yeah. Yeah. I guess for some real quick background, originally Brian Hicks was the one who ran State of Elm.

And I think he did it for 2016, 2017, 2018. And after that, he had had enough of it. It was too time consuming.

Yeah. So there wasn't for three years. Why I took over then, I actually had to reread my Discord logs because I remember why did I do this?

And I can't quite pinpoint it other than Mario.

We were discussing like, hey, wouldn't it be cool if there's a State of Elm for the 10th anniversary of Elm?

And we were like, yeah, we should do that. And then at some point that we became just me.

Mario was understandably busy, so I don't blame him.

Yeah. Yeah. That's what I did.

Because you weren't busy. Yeah.

I work part time, so I do have a fair bit of free time to do spontaneous projects.

Oh, that's nice. And in a sense, Mario did help because you used LimeDare to build it.

Yes, exactly. That's why he built LimeDare. He spent many years putting it together so I could make this for the community.

So you could have fun building LimeDare apps and he could keep maintaining LimeDare.

Yes, exactly. Yeah.

Yeah, I actually found a recent tidbit that I guess I had learned and forgotten.

I was rewatching Brian's Elm Europe talk where he talks about the 2017 survey results.

And he was asking, when is there an Elm conference? I think to Richard.

And he said, well, you tell me, like, if you're so interested in it, why don't you organize one?

And of course, he then went on to organize ElmConf US.

And he did the survey as a data gathering sort of preparation for the conference to see was there enough interest out there

and to understand more about potential attendees to the conference.

So it's kind of a cool tidbit.

So does that mean that Martin, you're going to organize a conference as well?

I didn't think this far ahead.

LimeDareConf 2023.

Yeah, yeah, let's do it.

That would actually be amazing.

Maybe Mari will help this time, I hope.

I mean, I would go to a LimeDareConf. It sounds incredible.

Yeah, there you go.

So that's a, anyone wants to help organize that so that I don't have to organize that?

That's always the tricky part.

It definitely crossed my mind with the state of Elm as well.

And I was very close several times to just doing one.

But you should work at home pages, Dillon.

Exactly. See, that's the tricky part. Choices.

Yeah, well, let's dive into some of this data here.

So there's a lot of information.

So first of all, the number of participants in the 2022 survey dipped down compared to the 2018.

But it was more than the original 2016 survey.

So what do you make of that, Martin?

I want to note real quick that in the original release of the state of Elm, I had forgotten to include the 2016 numbers,

which made it look worse than it actually was because it looked like it was just a downward trend, not down, then up, or rather starts low, then increases, then goes down.

Yeah, I think, well, I guess my conclusion really is I don't know what to think of it because it could be just that the survey didn't reach as many people.

Because, I mean, we haven't done the survey in like four years.

So people don't know about it.

They don't have the habit formed anymore of just checking every year to see if the survey is out.

And it could be that I don't have the same kind of reach that Brian does.

I actually asked him about that.

And he said that he, in addition to Elm Slack and Elm Discourse, he also posted it to external communities and a mailing list as well, which I didn't do.

Of course, it is possible that someone else did this for me.

Like I noticed that the 2022 state of Elm, they could post to the Reddit because someone else did it for me.

I don't know if that's an explanation or not.

It was also open for less time, right?

It was only open for 20 days compared to 60.

Exactly.

Yeah.

I guess, you know, maybe this is heresy to say, but maybe the Elm community just got smaller.

Who knows?

No, that is impossible.

Yeah.

Yeah, I mean, the methodology for any sort of data gathering is always important and you can't read, you know, you never know exactly what the data is saying.

All you can do is try to improve the methodology over time.

So, yeah, it's interesting.

Hopefully we can sort of see where the numbers go next year if sort of having another state of Elm this year gets it back on people's radar.

You know, I do wonder also if things like conferences get more engagement out of community members and like how much there is people sort of being less engaged with community the last couple of years.

So interesting questions and hopefully we can sort of get more insight over time and see more trends.

An exercise to the listener might be to maybe gather like history or like statistics on discourse and Elm Slack to see if those things are trending upward or downward, like user counts and activity and see if it matches what we're seeing here or if this is an outlier.

It's a great question.

Those industrious users of ours.

Yeah, very good question.

So there's a question about halfway through the survey, which is how long have you been using Elm?

And a lot of people replied between two and five years, like around 15 percent of respondents said they were they've been using Elm for 15, for five years, also 15 for four years, also 15 for three years and also 15 for two years.

And then then there's a downward trend for one year and less.

So I'm thinking since COVID, since we haven't had any conferences, we have not increased the community much.

So I feel like there's my gut feeling or my understanding is that the community didn't grow much in the last few in the last two years.

I think you might be misreading that because there's the one year bar, but then there's between three months in a year and three months.

And if you add all those three together, so that would be a one year span.

That's more than 15 percent.

If you include the OK, yes, if you include all that have used Elm for less than two years, then it's about 21 percent or something.

Yeah, which would seem to indicate growth now, which is good.

I think one thing to keep in mind and again, this is I mean, I think this is going to be a recurring theme in this conversation because first of all, disclaimer,

none of us are statisticians. And secondly, you just never know exactly what the data means.

It's it's just kind of a data point, but it doesn't tell you exactly what the data means.

It's just data. But for a percentage of people using it, percentage of respondents who have used Elm under three months or between three months and a year,

that might be an underrepresented group in survey respondents because you might be less likely to do a state of Elm survey if you've been using it under three months.

And you may not be using the Elm Slack or follow the Elm discourse or read it.

Exactly. Yeah, absolutely.

Or you might be more likely to and it's an accurate reflection or more than more than the accurate reflection would be.

We don't know, but we can only speculate.

Yeah, at least thankfully, none of us are biased. So that is very good.

Precisely. So another question almost near the beginning is what is your level of experience with functional programming?

And we see a lot of people who are responding that they're good enough to use it professionally, like the majority of people.

And then a tiny portion of them are saying that they're experts, less than their beginners.

Do you think that it's because people feel like they're good enough with functional programming to use Elm,

but just not good enough to use it in other languages like Haskell or PureScript, which have more advanced functional aspects to it?

Yeah, you're saying like to be a professional, you need to get paid or if you're good enough to do it professionally, that means you're good enough to get paid doing it.

And so if Elm is a language that's or at least I think we all agree that Elm is a language that's pretty easy to get into.

So if you're if you can get into it and it's easy and then you can get paid doing it, then that's a criteria that's easy to fulfill.

So, yeah, it's not it doesn't seem too surprising to me that like it's a pretty high number that can use it professionally.

And then that people don't consider themselves an expert because they know Haskell exists.

If I could just go back to the how long have you been using Elm question for a second?

I'm looking at the at Brian's blog post about the state of Elm 2018 results where he has the 2016, 2017, 2018 and a few charts comparing the results.

I'm noticing that for under three months, about 34 percent of the 2017 responses were under three months.

Thirty four percent compared about thirty four percent in 2017 in 2018, it's about 20 percent.

And in the 2022 survey, under three months was about four percent of the survey respondents.

Now, that could just mean that, you know, I mean, we've got people listing seven years of Elm experience, six years of Elm experience at this point.

So it could just mean that we have a bigger tent with more more of a range of Elm experience.

Or maybe there's something that we were getting people in those earlier stages more engaged or getting getting the survey out to them.

So I just wanted to kind of bring our attention to that a little bit, because that's that is kind of interesting.

Yeah, I'm not sure what to make of that. Dang it.

I'm not a statistician. Yeah. Time to go back to school.

Yeah. Very interesting. So and I do wonder what like, again, the lack of of in person conferences we've had the past few years or just any conferences.

Having Elm online has been great. The Elm online meetup that Mario runs, but also like local meetup groups and those sorts of events have not been happening for the last few years.

So I wonder what sort of impact that has on engagement for newcomers.

That's another exercise to the listener. Start a conference for Elm. Love it.

That's a great exercise to do once per month to get good at it.

Yeah, in all seriousness, if anyone is listening to this and is really passionate about I wish there was an Elm conference, maybe you're the person who's scratching their itch there.

We would love to see it. Absolutely. Yeah.

So are you surprised by the other languages that people know about?

So it seems like most people like the language that is most known by Elm developers apart from Elm is JavaScript and then TypeScript.

That's not surprising at all. Yeah, that's not a surprise. Yeah.

So just how to read the charts, because this is a question where multiple answers can be chosen.

It reads different from the other charts that we have.

Yeah, yeah. I'm glad you brought that up because, again, not being a statistician, this is something where I just threw things together and thought, oh, this is good.

And it wasn't until recently that I realized that, no, this is really kind of misleading.

Specifically, if you look at the percent of answers filter, that's literally the percentage of total answers.

So if someone answered, say this survey was just answered by one person and they picked five things, then those five things would all get 20%.

Like maybe to some people or a lot of people, that's really misleading.

They would expect 100% for all those five things then.

Right. So, yeah, maybe for next survey, I should rethink how that's at least explain it anywhere in the survey that works.

Yeah. So, yeah, just the questions that say multiple answers can be chosen, such as this one.

Yeah. Got to be a little extra careful if you're looking at percentages.

Yeah. So in this case, we have 572 people who said the new JavaScripts out of 821.

So that's a big chunk of them.

OK, hang on. Sorry.

Another thing that is for all these questions, besides the do you use Elm question, people who responded with or rather to the do you use Elm question,

if people responded with no and I don't plan to, their responses aren't considered for the remaining questions.

Right. Yes. And on top of that, if someone doesn't answer a question, then obviously they're not counted either.

Ah. Because like no one's forced to answer questions.

So they could like say, yes, I use Elm and then not answer anything else.

There really should be like a total like number of people who answered a particular question, like somewhere within the question.

Mm hmm. Give you an idea of how many people actually, yeah, actually answered it and not just the number of answers.

But the raw numbers still give the raw totals give some sense, I would imagine.

So like maybe another exercise for the listener would be I think it would be really interesting to take some of these results

and compare them with some of these numbers that Brian has for the 2016 through 18 results.

You know, normalize them a little bit for percentages of total for some of the questions that can be compared to just see what we learn.

But yeah, like for, you know, I mean, some obvious trends you're going to see like TypeScript in in 2018 had 71 respondents out of 1176.

Which is super low. Quite low.

Yeah, that's that's trended in a very different direction.

And I do wonder, like, what what does that mean for people's interest in Elm with somebody who has more exposure to TypeScript or who's passionate about TypeScript and says like, oh,

let's convert these parts of our code to TypeScript because it's a really useful tool.

Is that going to make them more inclined to be interested in Elm or less inclined?

That would be an interesting thing to understand more because, you know, does it do they say, well, I don't need Elm because I've got a type system or do they say this stuff is really good.

What if I had even more of that? What if I had stronger guarantees?

The TypeScript is so low that I almost wonder if maybe that wasn't like a choice people could just click on.

They had to like type in a type in a free text field because I noticed that with some of the questions in my 2020 survey was sorry, 2022 survey was that like if they weren't an explicit answer,

they could get like considerably less chosen, even if they should have been chosen more often.

Like, for example, with incremental Elm, one of the questions was like what places you go for news and discussion. Incremental Elm got like five people picked it, but like there's way more than five people there.

And I know there's discussions and news there. So like, so like that's like a smoking gun evidence that there's some bias going on.

Yeah, there should almost be like a little symbol next to predefined answers that people could select and write ins.

Because as you say, the write ins mean that it's probably an underrepresented answer because more people would have reached and clicked for it than would go to the trouble to write it in.

Yeah, it's like for the state of JavaScript. There was a question about which podcasts do you listen to and Elm radio was on there, but only because people wrote it in. Otherwise we'd be way higher. We'd be in the top three, I'm sure.

Well, we were like the second highest write in podcast, which was cool.

Yeah. Yeah.

Surprisingly high actually. I think Elm wasn't listed either in the state of JS last time. So that also, think of how high it would have gotten if it was listed.

So yeah.

So even with the a bit hard to read numbers from this question, we can figure out that most people know JavaScript quite well out of the respondents. A lot of those also know TypeScript well and quite a few come from Python or Java.

And then we get Haskell people, but this is for all of the users. So there are additional filters for people who use Elm and those who are considering Elm. And those change how the numbers.

Yeah. If you click on considering Elm and then look at percentages, Haskell drops down several places. Which, yeah, I guess that makes sense because if you're using Elm and you're in the ballpark of Haskell, whereas if you're not using Elm, you might not be totally sold on functional programming yet.

And so you're less likely to consider Haskell.

Yeah, we can see mostly the bigger known languages at the top. Python is also a big one. Do you know if PureScript and TypeScript, if PureScript had a lot of answers?

PureScript landed in the other category.

Backend, yeah. Interesting.

Five people picked it or so.

Was it a write in option?

Yeah, it was a write in option. So it wasn't a specific choice.

Yeah. And also, like the question is, which one are you most familiar with? So if you're more familiar with JavaScript and a bit less than PureScript, then you can understand the question as, well, I should only write in JavaScript.

I think I chose that wording because that's, let me double check now. I think that's exactly what was used in the original state of Elm questions.

Yeah, it is.

So I wanted to keep some consistency so that the data would be somewhat comparable.

Yeah.

Though it was then unfortunate that I didn't have enough time to actually extract the old data and place it in the new one.

So it would be easy to compare instead of all this, like us fumbling around trying to guess, well, this percentage, that's a percentage of what? Can we compare that to the old data?

But the data is there now.

At least the data is there.

So somebody could go and write a blog post comparing those things. It would be very interesting to see.

So is the raw data available anywhere?

So the raw data is not available. So if someone contacts me, I'll be happy to provide it to them.

When people filled out the survey, there was a little checkbox at the bottom that said like, I have not put any information into the survey that I wouldn't want revealed publicly. But even despite that, I want to play it safe and not just expose it to everyone.

But yeah, if individuals want to see the data, yeah, I'm happy to provide it. And then they can do statistics more easily.

Yeah, that'd be very cool to see.

So for where people get their news and where they come to discuss things, we got the known ones, I'd say, which are at the top.

Discourse, Slack, blog posts is also in the top three. It's a bit hard to know which blog posts they come from.

Yeah, blog posts was so popular that I kind of wish I had split that apart at the individual blog posts.

But I'm certain they're all thinking of your blog post when they pick that.

Well, I would like to know if that's the case.

You know, gut feeling, you know it's true.

I have the analytics from my website, but it's not that high as far as I can remember.

Well, if it's 292, then there you go.

That actually looks like a match.

I guess people can't see exactly what we're looking at. So 292 is the number of people who picked blog posts.

Yeah. And then there's the Elm Weekly newsletter and then there's Elm Radio where people come to discuss or just to get news.

Are we news outlets now?

Well, I mean, Steadicom 2022 is news.

I mean, if Simon comes on to talk about the Elm tooling CLI, that's news.

Yep. Absolutely.

I think we're news.

I know. We're part of the media. We're part of the problems and the solutions as well.

Yeah, I hope so.

I mean, yeah, I hope that it gives people a bit of an on ramp to get some Elm material in different mediums.

If some people learn better by videos, they can watch front end masters or conference talks.

If people learn better through tutorials, they can go through blog posts.

If people like to wash dishes and hear discussions and understand how to think bigger picture about things, then podcasts are great.

So it's good to have a variety of media options, I think. Multimedia, if you will.

One fun piece of trivia for this one is, so I was just mentioning how some of the questions were negatively biased by the fact that they weren't default options.

In this case, Facebook groups was one of the default options and exactly one person picked it.

So I'm guessing if it wasn't a default option, no one would have picked it.

Yeah. Are you showing the ones where zero people responded to it, chose it?

I don't think that ever happened that a default option was picked zero times.

But if it did happen, then I think it would be filtered away.

Okay, actually, sorry, I take that back. So the country question.

That's a case where there's lots of default options and we don't have an even spread of people.

So some countries don't have own programmers.

So in that case, yes, the countries that have zero own programs, own programmers in them were filtered away.

Okay.

But yeah, I included Facebook groups only because it was a default option in the previous surveys.

But I'm thinking going forward, it's not going to be included.

Yeah. And you can see a noticeable jump looking between the 2017 and 2018 results for this question

and the 2022 results that we're looking at here for where do you go for Elm news and discussion.

You can see a noticeable drop in percentage of respondents who say Elm subreddit and an increase in the number of people saying Elm discourse,

which makes sense because it's much more active on the Elm discourse nowadays.

But of course, again, you know, we don't know if that's because of how those different groups are represented in the survey

versus if that represents the actual general percentages out there.

But I would imagine there's just more going on in the Elm discourse.

But, you know, there are some of these places that how do you find out where to go for these things?

It's kind of word of mouth to a certain extent.

Does anyone want to touch upon the what initially attracted you to Elm question?

I think this one's interesting because there seems to be a noticeable shift between what attracted people who are using or have used Elm

in contrast to people who are considering Elm.

Oh, yeah.

Specifically for people who are considering Elm, the fact that it's a pure functional programming language

and that it's an alternative to JavaScript are significantly higher compared to people who have used Elm or are using Elm,

where it's still high, but it's not nearly as high.

It's like 20 percentage points less if you combine those two answers.

OK, hang on, maybe 15 percent.

Maybe I'm exaggerating a little bit, but it's noticeable.

Yeah, what bothers me is that when you say, oh, I'm interested in Elm because it's pure functional programming.

I'm like, yeah, but why?

What part of a pure functional language attracts you?

Because, for instance, well, maybe I know more about it now,

but I was more interested about the ease of maintenance and ease of refactoring.

I think that's what I chose as my option, probably the only one.

And I didn't choose pure functional programming because for me, yeah, pure functional programming is what attracts me.

But it's because I'm able to maintain my codes easier.

Right.

I think I said something like pure functional programming for this answer, too.

And I mean, for me, when I initially found Elm, the ability to write tests for pure functions was super exciting.

And the ability to debug and refactor code that's pure was really interesting.

So that was what turned me on to it initially.

But as you say, it's hard to decide.

There could be a lot more behind these answers.

I don't remember actually what I picked now when I answered this survey.

But if I had to answer right now, it would have definitely been pure functional programming, alternative to JS.

But yeah, it's tricky with pure functional programming.

But then people did have write in answers where, well, it says 1.9 percent of all users wrote ease of refactoring slash maintenance.

So you're not the only one, Jeroen.

I say that I wrote that, but I also don't remember.

I think that's what I replied, but it would be so nice to know, like, what did I answer?

So like next year, I should have an account creation system so like it can highlight what you picked.

I would create an account just for that.

Wow. This is turning out to be a lot of work.

No wonder Brian gave up on this.

Yeah. When you announced that you were doing it, I was like, huh, you don't know what you're getting into.

Yeah. But I'm happy that you do. But I'm sorry for you.

Well, I mean, so in my defense, like I did think, oh, this is going to take some work.

And then and also people when they like thank me for putting this together right after I had announced the survey was open.

I did say things like you should thank me after the results are out.

I knew there'd be more work to do, but I didn't realize how much I still didn't realize is the full amount of work necessary to bring this out.

Yeah. And for next time, bring a statistician to the table.

Yes. And implement all the GitHub issues people have.

Actually, there's only two at the moment. People really should write down things they find and not just write it on Slack because, you know, Slack eats messages.

Yeah. And we'll link to the issues of the project.

But hopefully next year, I mean, yeah, there'll be work to do, but hopefully not too much because a lot of the effort I spent on putting this together this year was creating an admin panel that like gives me some tools to more quickly group answers.

It lets me bring someone else on board. Shout out to Wolfodex, by the way, because he's the person I brought on board who helped me group the answers so that it took like without him, it would have probably taken two more days or something before the answers were released.

Yeah, normalizing data is a lot of work. I can say from doing our game show challenges, our family feud style games, it is a massive amount of work to kind of group together similar answers and figure out how to categorize them and normalize all the data.

Yeah. Sometimes it just feels like there's no good way to group things. It's like a smooth blend from one possible answer to another. Where do you draw the line?

Precisely. I mean, you took the bold step of both creating the data collection tool in Limedera, homegrown, and the data presentation layer, which for previous DataVelm surveys, it's been a sort of out of the box survey tool.

And then Brian writing blog posts, showing charts with the data. So that's, I mean, that in itself is a massive amount of work. Forget about scrubbing the data and all that stuff. But you created admin panels to be able to do that sort of data normalization and present the data and all of that.

Yeah, I sort of brought this upon myself. A colleague asked me, like, why not use Airtable? I think that's what he suggested. And like, I thanked him for suggestion, but quietly I was thinking like, it's not Elm.

Right.

Why would I use that? It's not Elm.

It's not going to work in Limedera.

I mean, I would probably export the data and then import it again. I haven't used Airtable, so I can't really say what exactly I would have done. But I mean, it could have worked. But it's not Elm.

I use Airtable for the showcase on the elmpages.com website, elm.pages.com slash showcase. It's presenting individual sites that people submit to the showcase, and there's a button to submit your Elm Pages site.

And it's a form created by Airtable. So you hit submit, and Airtable gives you a form with all those columns. And then Elm Pages has a data source to pull down all of the entries.

Okay.

I just have to click an approve button on one of the columns that's admin only, and then it shows up in the results. Airtable is pretty cool, but it's not Limedera.

Exactly. It's not Limedera. I'm not going to claim that what I did was the easiest way or the best way. I really get a lot of enjoyment out of writing my own solutions.

And I have a hope that doing it this way in the long run makes it easiest because I've had experiences with third party tools becoming difficult to work with once you need something they're not built for.

And then it's difficult to work around them. But again, I can't say if it was really the right call other than I enjoy programming Elm, so why not?

And what was the name of that talk you gave recently about like making hobby projects, like changing the calculus for what hobby projects you can build?

Okay, so sort of a secret. That's not really a secret. I'm going to be presenting it at GoToAurhus in a month.

But yeah, it was a presentation I gave at a meetup practice for that called Hobby Scale, Creating Web Apps with Minimal Fuss.

Yeah, yeah. Using Limedera to write web apps with server support.

You definitely walk the walk on that one, which is cool. I mean, I love that idea of how can removing glue code with Limedera make it viable to build certain things that wouldn't be worth building a custom solution for because the amount of glue in other paradigms.

Yeah, I guess we're at risk now of just having another Limedera episode on the show.

Yeah.

Because I love talking about Limedera.

Really, I think we should have you or any Martin for that matter, but I think we need some Martin Limedera episodes in the future to do a deeper dive on that.

Yeah, I'd love to be a repeat guest at the show.

We would love that too. Yeah.

I don't know how much time we have left on the podcast, but one thing I would like to talk about if there's time is the last two questions, which one is kind of a downer to talk about.

What has been the biggest pain point in your use of Elm? And the other one's the nice feel good one. What do you like the most about your use of Elm?

Yes, absolutely.

Should we take the sad one or the happy one first?

Let's take the sad one first. I mean, and is it necessarily sad? I mean, I think that if we're saying that something is a pain point, then I mean, it's also an opportunity to understand what could we work on?

What are people having trouble with? But also like, there are also certain things that are going to have certain design decisions are going to have trade offs, right?

Engineering is all about trade offs. So I don't necessarily think of it inherently that every time there's a pain point, it means it's sad or there's something bad.

Sometimes it's like an easy win. Sometimes it's an inherent design trade off that is part of the part of the package.

I can clarify that perhaps part of the reason why I feel like this part is like the sad part. Yeah. Is because I had to read through all the actual things people wrote, like the literal answers before I grouped them into this nice sanitized graph that you see.

Yeah. There's absolutely nothing I would say felt hateful. Yeah. Or like, you know, you know, you know, what much what you might read on Twitter or Reddit on a normal day.

But yeah, you can really feel for some people like feel their frustration.

Can you remind me where these write in or where there's some predefined choices?

This one was purely free text. Cool. That's what I thought. It took a lot of time to go through it. So I might rethink that next year.

OK, so what were the biggest pain points then?

Yeah. So this is another situation where, you know, you could group things in any number of ways.

So I like I wouldn't read too much into the percentages, but the top one, like shown on the graph here, lack of PR is being merged, infrequent updates in core team attitude is the way I politely put it.

That was one that came up a lot. And like it's one of those things where it doesn't it's not a problem for me.

Like there are sometimes issues that have like PR that have existed for a while that haven't emerged.

And I can get that that's frustrating for people. But at the same time, like it's in practice, never been a problem for me personally.

So I'm not saying these people are wrong. Right. Right. Yeah. There's some I guess I guess a disconnect.

I mean, that's the way of putting it between like how I feel and how other people feel.

Yeah. Right. Just like you say, there are some issues that say along as say a lot for quite a while.

But since there are not that many in practice, like some people will be hits much harder by them than others.

And I guess like the people who stay the longest in the community are the ones who haven't been hit by them at all or that much.

Yeah. And I mean, I think everybody has a different experience of this.

And I mean, it's been coming up for, you know, since since the early days of Elm, you know,

Evans given multiple talks about Elm's release cycles and the batching approach and what does success look like?

I think was a talk he gave where he talked about some people saying like they really thought that the official Elm Lang site should have more blog post updates and more items in the news section.

Somebody somebody was very animated that they thought that was very important.

And I think that's not uncommon that like I mean, you see it.

You see it all the time that trying to think what it was, but I've been hearing this kind of thing come up in other communities, too, where people people want to say is X dead because of some concept of what it what it means.

You know, frequency of the release cycles or amount of news happening.

But, you know, Elm has like a stable core.

Right. That's that's another side of that coin.

And there are benefits to that.

And it's not likely to have a massive breaking change anytime soon.

And that stability is a good thing.

And the core of the language lets you accomplish most of what you need to for building front end web applications.

So it's it's a mixed bag.

But and I think this can mean different things for different people.

But that said, the perception is important for things like blog posts and those sorts of things.

And and clearly there's a there's an understandable concern with, you know, pull requests that and and bug, you know, issues that are being tracked for a long time.

I would argue that I think that the if you look at something like, you know, TypeScript is TypeScript going to have like how many open issues does TypeScript have?

I think that because Elm is this very kind of small language with not a lot of language features and it's trying to become more and more refined as to like this paradigm of expressing code.

I think it's easier to see these things as problems because these problems stick out like a sore thumb because the error messages are so clean.

The language is so small and there are so, so many thoughtful APIs.

I can mention real quick there that you like that hits the nail on the head for like my initial experiences with like I'm using Elm and like ninety nine percent of it feels amazing.

But then like a little part just like gets in the way and like unlike a lot of other languages where there might be an escape hatch that lets me feel like I'm smart so I can work around the principled way of doing something.

Elm is just like, no, full stop. No, you're doing it the right way. And like that can be so frustrating.

Yeah, it's also because it's done so well in general.

Like if you have if I make a painting and it's going to be ugly because I don't know how to paint and there's a scratch somewhere in the corner, then no one will notice it.

But if you have the Mona Lisa and there's a scratch. Oh, man. Right.

People are going to complain about it. So just FYI, because you half asked that it has five thousand two hundred errors.

Sorry, issues open and the compiler has 250.

Well then, yeah, that invalidates everyone's criticism.

Yeah, exactly. No, I mean, we are not biased at all.

Yeah. No, I mean, I think we all experience, you know, some amount of frustration with, you know, a particular things that we would love to have in the language or, you know, like, wouldn't it be nice if custom types could be comparable?

Things like that. It's like it seems, you know. But but again, yeah, as you guys are saying, if you have I think that Elm in particular really takes responsibility for the user's experience in a remarkable way.

In that it says, like, I'm giving you a complete sandbox. So I'm sort of taking responsibility for what you're able to do within that sandbox because I'm not giving you escape patches to break out of that sandbox.

So I'm not giving you an any type, not giving you no, I'm not giving you synchronous foreign function interfaces where you can directly call JavaScript and say, trust me, I know what I'm doing.

I know what the types are. I know it's going to be well behaved and not cause side effects. These escape patches don't exist. And so you're working in the sandbox.

And if you don't have something, suddenly it doesn't feel like a first class thing anymore.

Yeah. FFI is actually like almost as mentioned as the lack of PRS being merged.

Martin, do you want to explain what FFI entails? Like, is it mostly people who like more direct FFI with JavaScript or is it people just say it's a pain, it's annoying, but it is how it should work? What is it?

Yeah. Part of it is people complaining about ports, just dealing with ports, having something becomes asynchronous that they want to be synchronous.

They're complaining about that. Yeah. So I think FFI covers mostly two situations. The first being people literally just saying they want to call JS directly.

So they don't want to deal with asynchronous, like they can call JS asynchronously through ports.

But that's a hassle when you want to do something synchronously instead. And the other one is sort of an overlap with the there being browser APIs missing.

So a good example of that is internationalization, where there are existing JavaScript libraries that will do this for you.

For formatting time and things like that. Yeah, yeah, exactly. And I guess to some extent you can work around that with custom types. Sorry, not custom types, with custom elements.

Yeah, absolutely. Which I've done and it worked pretty well.

Okay, cool. I don't have that much experience with it, but it seems like at least some people aren't convinced or not aware, one of those two. And so that's another complaint.

Yeah, and it's definitely for sure those things should not just be pulled over wholesale into Elm.

A lot of the time we talk about, actually, Yorun and I were having an interesting conversation on Twitter with somebody about the point of FFI.

They were saying that, you know, like, it's a shame that Elm doesn't just provide FFI and people are saying it's a pain point. So why don't we just provide it?

And we were saying, well, like, there are two sides of that coin. It's you have FFI, but not having FFI is what we love about Elm.

And we talked about that on our What's Working for Elm episode.

So, like, just because there are pain points doesn't mean that there's not another side to that coin.

In my case, I think if there was FFI, I don't think Lamdera would be possible, at least not nearly as well.

Precisely. Yep.

Another example, I put together a package for simulating multiple front ends and a Lamdera back end communicating and interacting with each other.

And this package, in order to make it work, I had to recreate all the effectful packages.

So all the browser APIs and such, like I needed to create a custom type that represented everything they could do.

And boy, was I glad there aren't many browser APIs. Right.

Right. It's an incredible tool and it's incredible.

You gave a talk about that at Elm Online, which we'll link to and the demo of it.

But to me, that is such a great example of what I in my brain is termed the promise of Elm, which is like, all right, we have this pure language.

What do we do with that purity? What guarantees can we leverage?

And to me, like Elm review, Lamdera, Lamdera test, the framework you're talking about that you built to show different connected clients and do time traveling unit like program tests.

Yeah. These are the things that are really exciting about Elm.

And when you don't have just direct FFI, like something like Rescript, you see a different evolution of the ecosystem, which we build these different solutions to these problems.

But things like internationalization, where you have, you know, time zone data and data about how numbers are formatted and about how you display dates in different regions.

That stuff should not be re implemented in pure Elm packages because it's just a whole bunch of data and a whole bunch of data that you could get wrong and a whole bunch of data that's going to bloat your bundle size that belongs in the browser.

That locale related stuff like the internationalization APS really belong in the browser.

So, yeah, I mean, could there be some native way to access that?

Perhaps. Is there going to be in the near future?

Probably not, but we can use Web Components.

And for now, that's probably the best solution.

So, yes, it is imperfect.

But also, like the other side of the coin, all of these libraries that are not just wrappers of JavaScript libraries are something that I don't think we would have if we just had FFI.

It changes the evolution of the ecosystem.

One question I have for you, too.

So maybe this isn't entirely true, but it feels now that we've gone through some of these pain points and basically basically said, like, like this, this is a pain point.

But it is what it is. This is the optimal situation.

Like you might wish there was FFI, but no, there shouldn't be FFI, even though we acknowledge the pain.

But I'm curious then, like to avoid us just coming off as like, this is fine while the room is burning from the opinion of someone who isn't completely enamored by all.

Are the things here that we do think could be improved?

It's perfect.

Yeah, it's a great question.

I mean, for sure, like, to be clear, I don't think that I think you're in and I are both on the same page that I don't think FFI could be, quote unquote, improved in the sense that just giving FFI and saying people are saying that they wish they could just directly call JavaScript.

And so just giving that feature would make things better.

We're both on the same page that that would defeat the whole purpose of the thing we love about Elm most, which is being able to rely on its purity.

That's the most exciting thing about Elm to us, because the possibilities that emerge from that.

But that doesn't mean that there couldn't be a different state of things where I mean, sure, why?

Why couldn't you have a built in API in Elm for that exposes parts of the internationalization API that's built in browsers?

That seems like a reasonable thing.

And that is something that I think could be an improvement that would not break the things we love about Elm.

Yeah, I'm sure there are also some JavaScript or browser functions which are pure.

Maybe not browser ones, but the ones that where you would always get the same value, like maybe the user agent, for instance.

You can't access that from Elm, but you could.

And it would just always be the same value. So we could give access to that.

Yeah, it could potentially be accessible through like flags that you could get some initial data when the application starts rather than a global thing or something like that.

Yeah, but for instance, the user agent could be a global thing.

It could just be always, it could be constant that's assigned before you start Elm.

Although I like the idea of it being passed in more as flags, because then you can't have unit tests that depend on some implicit global state that will be different.

But if it's passed in through init and you can access it in flags, then it's here's data from outside, but it's deterministic.

Okay, then I don't have a good example. But if there are some, then I would be fine.

The point is we are getting so many guarantees which lets us build amazing tools and make it super easy to refactor Elm code that we shouldn't throw a pebble into the gears.

As small as a pebble it could be, it can break the whole system if it's thrown in the wrong location.

Yeah, so yeah, my thinking is like FFI is fine as long as we don't break any of the guarantees and ports is one of those systems where we have that.

Doing HTTP requests through tasks is one of those systems. Web components is one of those systems as well. So that might break things more than necessary, but so far so good.

Yeah, so could there be a world in which we have the same guarantees that we know and love in Elm and yet there are certain platform APIs which have sort of first class way to access them in Elm exposed.

Could there be more of those? Could there be a process for building out more of those perfectly coherent state of things?

But is that likely to happen? I think it's probably not likely to happen and my satisfaction using Elm doesn't depend on that.

Yeah, so to a certain extent I guess I would advise people that if their happiness using Elm depends on that process changing, maybe Elm isn't a good fit for them.

You know, because that might be a continued frustration. If we want to talk about I'm happy with Elm, but let's also explore how things could improve.

That is I think a more productive conversation to not expect that, but to explore what could improving things look like.

Martin, you had something to say?

My question was more covering all the pain points, not specifically the one we talked about with FFI, but I wasn't very clear about that.

I'm wondering if maybe we should have a look at the happy question instead though, so we don't spend all our time talking about what's wrong with Elm.

So you were wondering if we have any pain points?

Okay, so yeah, my question was specifically like there's this whole list of things that people find as pain points and the ones we covered like lack of PRs being merged, FFI, none of the browser APIs.

Oh, then there's some fun ones like people wrote none. 6% of people wrote none. Yeah, I love that pain point.

But then there's things like better IDE support where it's like that's a pain point.

And unlike FFI where like I can understand people would find that as a pain point, but like I disagree with them.

Better IDE support is something where I agree that is a pain point. It's a pain point for me too.

And more importantly maybe is that it's not something the core team needs to handle.

It's like it's something exercise for the listener could improve.

So that was my question. I was wondering, like, are there any sorts of things like that you see here where you think that, yeah, this is something that is an issue and it's also something we can improve as a community?

The one that comes to mind is the community. There's one that you grouped as the community is small or unresponsive or dismissive.

So for unresponsive and dismissive, I disagree and or slash don't understand.

Exactly. You're dismissing them now.

Exactly.

The community is dismissive. Now we dismiss that.

Okay. You know what? I'm just not going to respond to it.

Okay. Solved.

But the part about the community being small, that I feel like we have a lot more grasp on it so we can organize conferences, we can blog more about Elm, we can join JavaScript conferences and talk about Elm over there like Richard did so often.

And I think that's how most of us have known about Elm.

Yeah, I think that's a big one is it's so easy to get settled in a small, cozy community and become this impermeable bubble.

And like we all think Elm is great and we can't fathom why no one else uses it, but like no one else even knows what Elm is because we never leave our bubble to tell them about it.

So there's one thing that is maybe a bit of a tangent, but there's a lot of people who criticize the fact that there is not a lot of pull requests being emerged.

And so people saying that they're making pull requests to the core packages or the core tools.

But I feel like we could have a lot more activity in the community projects.

So like Elm UI doesn't have that many people contributing to it. Elm Review doesn't have that many to it either.

There's a lot of very cool projects, tools, ideas as mentioned as well, which could absolutely benefit from more contributors.

And if people don't join a project at some point, it's likely that the author is going to leave the community because that's what people tend to do.

They for different reasons, because they go to other languages or because they have their own life next to the Elm community.

Apparently, I haven't been there yet.

Or the burnout, which doesn't happen because Elm is a wonderful language and people don't burn out working with us.

But yeah, I feel like if you want to improve things, you can contribute to the community either by writing blog posts or by helping out your favorite tool or library.

Like Elm doesn't stop at the core packages and the compiler. There is so much more to do and there's so much to be done.

And if you want to help out, reach out to your favorite maintainer, which might be Dillon, which might be Martin, which is probably not me.

And ask if you can help or if you can do something.

I feel like that's something that we don't see all that much in the Elm community, probably in part because we're such a small community.

Like in the JavaScript world, you have people knocking at your door all the time because there are so many developers.

The community is so big. But I do feel like there is plenty of opportunity to contribute to those tools or to organize conferences.

That would be amazing as well.

Please organize conferences. I want to go to a conference.

Please do.

Probably in Sweden.

Yeah, and I totally agree with all that.

And there's so much you can do too for preventing that open source maintainer burnout too.

I know for me, creating small reproducible examples if you find an issue or giving a concrete explanation of if you are requesting a feature, like what problem you're trying to solve, an example of how you're trying to solve it now, things like that.

To me, I think people can look at open source as here's a free thing that someone is building and I can ask them to build more things or expect them to build more things or go in a certain direction with it.

And to me, I see open source as like, here's this thing that someone is putting out there. And if there's a problem that I need to be solved, the source code is right there.

I can go solve that problem for myself and now everybody can have that problem solved.

Or there's like an Elm review rule that I wish I had.

Well, I don't have to go ask you to build it, because not only is it open source, but it's like a plugin ecosystem so I can write my own Elm review rule and start using it for myself and other people can use it.

But, you know, I think, yeah, be the change you want to see in the Elm ecosystem. I think that is super powerful stuff.

And then the question of the better IDE support, that is actually my personal, you know, Martin, you were asking like, what is the biggest pain point for us?

I wouldn't frame it as a pain point though, personally, because if I look at like my experience using VS code with JavaScript or TypeScript, which is good, but my experience like editing Elm code is better than that.

It could be worse.

It could be much worse. It just has so much potential because of Elm's guarantees. And there's so much more I want from the IDE experience in Elm.

So that's my biggest pet project. And I think that it would have a multiplier effect for everything else we see in the ecosystem if we had world class refactorings and editor tooling.

So I would love to see that.

I come from like before Elm, I was a C sharp dev. Yeah. And Visual Studio. I know some people prefer Visual Studio code.

I don't understand why, because I think Visual Studio with the caveat of it tends to crash a lot. But when it's not crashing, it's amazing.

Yeah. And ReSharper?

Oh, yeah. And ReSharper on top of that. Yeah. It's like nothing compares to that, at least in my experience.

And so that's why I complain about Elm's IDE, because that's the standard I got spoiled with.

Yeah. Yeah. I mean, I've done like a decent amount of Java programming and like going through a Java code base with an IDE only and having it like generate all the code you need or like invoking a function as if it exists.

And then having the IDE create the correctly typed function placeholder for you and then refactoring things and pulling out code and inlining.

It's like you can get by without directly typing any code for hours, just refactoring Java code.

And it's amazing. And I want that in Elm so much. And like in Java, you have, you know, something could throw a runtime exception.

Something could have an array index out of bounds exception and all these types of things.

In Elm, if you're doing that refactoring, you don't have to look back because you're using your IDE to like flow through all those changes.

And you can trust them because there aren't as many asterisks as there are that when you do this in Java, it's probably safe.

Your code is probably not breaking, but you're not 100 percent sure.

This is one of the reasons I'm looking forward so much to Richard Feldman's Rock programming language, because it's promising to have an IDE built alongside the language.

And to me, that's like Elm with the promised IDE, like the best possible IDE Elm could have. Rock might fulfill that.

But I think he said he would only want syntax out of it and nothing more.

I hope you heard wrong.

Well, should we should we hit on what what do you like most about your use of Elm?

All right. Yeah, I think the top one type system slash safety slash type driven development.

Yeah, 100 percent. I guess it's a pretty close call.

It's like it's almost tied with compiler error messages, which yeah, also that one's really good.

Oh, man, there are so many good things in that list. Ease of refactoring slash maintainability.

And then if it compiles, it works. That phrase popped up so many times in its literal form.

I mean, these could be Elm Radio episodes.

That's true. There you go.

I mean, yes, so much of what has been written here is just like what we covered in Elm Radio in so many episodes.

I think I think that in the ecosystem, we will more likely be agreeing on what is very good about Elm than in JavaScript, for instance.

Like, I'm not sure what people would answer if if we asked that question to JavaScript developers, like, what is the best thing about JavaScript?

But I know what it will be for Elm. It's like no runtime exceptions and maintainability through type system.

Maybe or through some other means. But yeah, the reliability of Elm and the experience of Elm will be in the top for sure.

For JavaScript, I'm not sure what people will reply.

Yeah, although I would love to see over time, like because these are things about Elm.

I would love to see more things about the ecosystem and the tooling and, you know.

Elm, you got three votes.

Yeah, which, you know, perhaps people don't think to put that here because it says, what do you like most about your use of Elm?

But I would hope that like these, there's so much potential to what you like.

Elm has this core that gives us so much we can do with it.

And using like code generation tools and these sort of more meta frameworks that we're seeing, you know, Elm SPA and Elm pages.

I hope that we see more of that kind of exploration in the coming years and that that becomes more of what stands out to people about Elm.

You know, like a lot of people love Elm UI and that's, you know, we've got some some responses in there about that.

I would love to see that taking up more and more of people's responses of what they love about Elm.

And I think that that is one of the best things we could do for Elm's growth is to like help people understand these things out there more and see more exploration in these areas.

Yeah, I agree. It's really cool what the community has come up with so far.

I'd love to see what happens in the future.

Also, three people picked Elm Review as positive things about Elm.

I think one person picked Landera and it wasn't me.

It wasn't me for Elm Review either.

There you go. So four people. Four people like Elm Review.

You also have a few questions about Elm Review.

Yeah, that's true.

So, yeah, you have a question. Do you use Elm Review and 22% say that they use it regularly, which I find to be surprisingly low, to be honest.

Just to compare it with Elm Format, where I think 90% of the people use it.

I think that Elm Review is still in the early growth trajectory.

I remember in the earlier state of Elm surveys, like at Brian's Elm Europe talk where he was presenting about the 2017 results, Elm Format was like a big new thing.

That was probably in a similar point in time relative to its initial release compared to Elm Review now. That was one of the big questions.

Would people not want to use Elm Format in some cases and why?

So I think this will be a really interesting one to keep an eye on for next year's results.

Yeah, I think what surprised me most is that I have this bubble of information where I talk about it all the time and people seem to really like it.

So my feeling is like almost everyone is using it around me at least.

And then there's this somewhat low number.

So I feel like, yeah, the responses that I get from people are not what matches my experience.

For next year, maybe I should add an additional filter, which is like you can view all answers or answers in your bubble.

Oh, yeah, absolutely. That's why you create an account. So now it's a social network.

Exactly. You hear the things you want to hear.

What percentage of Elm Review users listen to Elm Radio or what percentage of Elm Radio listeners use Elm Review?

I bet there's a bit of a correlation there.

Probably. Also, quite interesting that Elm S.P.A., there were around 800 and some total participants, right?

And Elm S.P.A. had 145 people who responded that they're using it. It's quite large.

So that's a real trend. I'd say that's a notable trend lately.

You're looking at the what frameworks do you use question?

Yes, I am. Yeah. And 80 people said they use Elm Pages. So that's a cool trend, too.

And I'll be really keen to see what happens in the next year or two after I release version three,

which is going to be a more general purpose, something for kind of pulling in dynamic data, including user data.

That'll be really interesting to see what kind of use cases people use it for.

And then there's a humble Lambda with half as many users as Elm Pages, at least according to the question.

Yeah. Yeah, it would be interesting to know in what context people use these two.

Like, I'd be curious to know how many people are using Elm S.P.A. in production.

How many people are using Elm Pages in production? Are they using it for a marketing page, personal blog?

How many people are using Lambda for hobby applications?

How many people are using Lambda for work? I'd be very curious.

Actually, there is a specific question for Lambda, which is surprising now.

That is surprising, Martin.

Especially coming from you.

Sorry, I didn't understand which question are you looking at?

No, we were saying it's surprising that you didn't have a specific question for Lambda.

Oh, well, yes, I was thinking everyone's going to think I'm so biased if I do that, so I won't include that.

I mean, it's state of elm.lambdera.app. It's biased already.

Yeah, well, you know what? Maybe what frameworks do you use should just be 100% because you're using this survey.

That's true.

And on top of that, Elm Pages, what, does it use the Elm, the Lambda compiler now, right?

V3 uses lambdera, so that's right.

Yeah, exactly.

Checkmate.

But do those projects use Elm Review?

Yeah.

Elm Pages does use Elm Review.

Okay, and the projects I've made that use lambdera basically all use Elm Review.

Does the state of Elm survey code base use Elm Review?

It does. It was actually quite useful in detecting, well, not all instances of, but it was quite useful in detecting some instances of me forgetting to include questions.

That's good.

It couldn't catch everything because the no unused package doesn't detect unused fields.

Oh, yeah. Yeah. Yet.

But it was at least one level of security against me just totally forgetting to include a question in the survey.

The second layer of defense was, I think it was Jeroen, you asking me, hey, where's the test questions?

Yeah. In the results.

Yeah, exactly.

Well, Martin, are there any things on your mind for the survey next year that you might want to gather more information about?

If I'm honest, I'm thinking more about what questions can I remove?

And that's because, you know, I'm the one who has to categorize all this.

Yeah.

But part of it also is I think there's a risk of just, you know, everyone wants more information, more data points so they can like get finer and finer like conclusions about the community.

And I think there's a risk that as you do that, eventually people go like, I don't feel like answering this question.

I'll skip it because there's too many other questions.

And so the quality of the data worsens.

So I think it's important to always think about when you want to add a question, what question would you want to remove?

Because like, I think the survey right now, there's 23 questions that the user answers.

And I don't know, maybe 23 is the magic number or maybe it could be more because with State of JS, it felt a lot longer than this one.

I don't remember how long it was.

Yeah, I agree.

Yeah. And then like, I was, I think I answered everything in it, but I was just kind of like, you know, like none or maybe, or, you know, the quickest possible answer on some of them.

Because like, I don't care about half these questions.

I just want to like say I use Elm.

Like part of the State of JS.

Yeah, there were also a few questions like, do you know about this new API that has landed in JavaScript recently?

Right.

Like, there were like maybe 10 questions just for that.

Yeah. 90% of the time, my answer is like, no.

Yeah.

Right. And then people probably bias the data because they want to sound smarter.

So more people say they've heard of things.

I mean, you could ask a question like, do you use list.map?

Do you use maybe? Do you use results?

And if you don't have 100% over there, then it feels a bit weird.

And then ask a question like, do you use list.scrape, which doesn't exist?

And if any answers that say yes to that, you can say, oh, these are, they're not Elm users.

I can mention real quick.

So some of the multi choice questions, so the ones where you could pick multiple answers, sometimes they had answers like, well, for example, do you use Elm?

There's both yes and no in varying forms.

Okay, actually, hang on. That's a bad example.

Because specifically on that one, if you click no and then click yes, your no answer gets removed.

So that's a poor choice.

But there were some other ones where you could say, like, for example, what programming language do you use on the back end?

And one of the answers is not applicable.

And then, of course, there's a list of programming languages as well.

And there's nothing stopping people from picking not applicable and the list of programming languages.

And I let that slide.

One, because I'm lazy, but two, because I figured if I need to go through and figure out who spammed the survey with junk data, that's one of the like canaries is, did they fill in both of those?

If they did, okay, that's a junk one. I can get rid of that.

Interesting.

So, yeah, yeah.

A little thought went into that.

Yeah. Well, again, I'm very glad that you went to the effort to do this again.

It's great to have the results back.

Thank you very much.

Should we, should we share a few of these warm fuzzy quotes for what do you like most about Elm that you have at the very end here?

The one specifically I wrote down in the comments or?

Yeah.

Okay.

And I mean, I could go through the list, but I think, yeah, I think these are the, well, there were so many.

It's hard to pick a best.

Yeah.

Let me try my best narrator voice now.

Elm always felt like what Apple wants its products to be actually done right in programming language form.

That isn't entirely a positive, but I've never had an experience before or since where everything just worked, trademark.

So well, so long as you stick to the type of problems Elm is good at.

And then someone else said all of Elm's typically touted strengths recently as I have onboarded new engineers.

It's been great to see how quickly they pick up Elm.

And the last one, web apps that work reliably.

And in my experience, even less experienced software developers generate more stable code when working in Elm than in other languages.

I actually really love that last one.

That's been my experience too.

Like I was coaching a team once that was using AngularJS and they migrated to Elm and they were saying it was very difficult for them to figure out how to, how to approach a problem in AngularJS.

And with Elm, they felt like, Hey, like my first thought of how to approach a problem, I might hit a dead end.

But I kind of like that because then I know that wasn't a great way to solve the problem and I go a different route.

Whereas in AngularJS, they go and they try to use some API and then it's, Oh, you're not supposed to use that API.

That's not a good, good practice that's frowned upon.

Yes.

The pit of success concept.

Yeah, absolutely.

The Apple one resonates too, because, you know, yeah, yeah.

I picked it because like, like, like they literally say, this isn't entirely a positive, but like I picked it anyway because it resonates so well with me too.

It feels like an Apple product in some ways where it's like, well, maybe I should let you explain what you think of it and not just talk over you.

Well, no, no.

Well, I was just going to say it's like, yeah, there are pros and cons.

Exactly.

And it's, you know, the Elm takes responsibility for the user's experience in a pretty dramatic way.

There are pros and cons to that.

If you don't take responsibility for the user's experience, they can sort of go anywhere they want and do anything they want any way they want.

And there are pros to that.

There are cases where that's kind of nice, but, you know, so there are tradeoffs.

And I think the Apple analogy captures that pretty well.

I remember at my previous job, someone came up to me because I was the resident Elm expert and they asked me, can I do metaprogramming in Elm?

And my answer was just no.

And I thought, like, if this was another language, you would have probably been, well, maybe you could probably do it in this way, but might not be advisable.

And like, there's the risk that they go off and spend a couple hours on it, make something and it works, but not so great and everyone suffers for the rest of time.

Your decision to do that.

Not to say metaprogramming is like just always bad, but like in Elm, you don't have to consider the tradeoffs.

It's just you can do code generation or you there's other ways to work around it that are more stable.

And yeah, there's one good way to do things usually.

Yeah, there are not a lot of foot guns available in Elm.

You have to try pretty hard.

Yeah.

All right. Well, thanks again, Martin, for doing this survey again and for coming on the podcast.

If people want to follow you or find out more about what you're working on, where's a good place to do that?

I've been meaning to make a blog in Elm pages, but I just haven't gotten around to it.

In the meantime, just I guess you can like watch my GitHub account and when new repos appear, then you know what I'm working on.

I don't really have like a social media presence.

So that's I guess check Discord. I'll probably announce new things there, too.

Yeah. Just put put like a search notifications for Lamdera in the discourse.

Oh, and of course, if you find problems with the survey, like in addition to the things we've already found now with like misleading information and what not.

Yeah. Please make a GitHub issue for it. It's fine if you tell me slack as well.

But there's a risk I'll forget it. So I try to collect all the problems people find there.

Fantastic. Great. Well, thanks so much. And Jeroen, until next time.

Until next time.