Building and extending trust

Today, I want to discuss trust. Not in trusting our code or our tools, but how we trust each other as people. I want to address trust, because it’s something everyone agrees is important, but not something I see anyone discussing how we can actually build. And actually I see several behaviors in the community which generate distrust, yet are not being addressed.

Starting with some definitions: what is trust? It’s a fuzzy thing, but generally, it’s that we expect others to do good by us, even when we make ourselves vulnerable (e.g. by showing something we’ve built or speaking up when we think something is wrong). When we have trust, things go smoother and people are happier. When trust isn’t there, relations and communication break down, and if you stay in an environment where you feel distrusted, it can make you sick.

It’s important to note that “being nice” does not mean you are trustworthy. It’s definitely a part of building trust, but you can easily be nice, and still be untrustworthy. And yet, much of our focus in the community has been being nice to each other, as maybe a way to implicitly build trust. But let’s focus explicitly on building trust some more.

First off, I want to apologize to anyone I’ve not inspired trust in personally. I know I’ve come off harshly in the past and it will probably happen again in the future. But secondly, though my behavior is my responsibility, I’m here to talk about trust, precisely because my harsh reactions have been partly driven by distrust.

As examples of where the trust breaks down, see e.g. when Evan recently did a talk at GOTO about the future of Elm, and one of our members responded like so:

If the trust had been strong, his initial reaction would likely have been more charitable. Similarly, if Evan had wanted to build more trust, then I believe the best course of action would have been to give some kind of heads-up about the talk here on the official forum.

Another example was when Luke’s infamous post went up, where the main instigation for him was that Richard had responded to him without trust. And that post triggered other stories where trust was missing.

Before we continue, I want to highlight some important points about trust and distrust:

  • Neither trust nor distrust need be explicit. It can just be a feeling you have.
  • Different people have different dispositions towards trust and distrust. What is trustworthy to me may not be for you.
  • Distrust and trust are two separate things which can be present at the same time. I.e. distrust is not the lack of trust and vice versa.

So what’s generating distrust today, and how might we address it?

You may think that “transparency” would be about roadmaps for Elm, what’s Evan working on, etc., but actually I think Evan has been decently transparent about that. Not in the sense that we know what’s coming when, but in the sense that we know he’s off somewhere doing his thing, and Elm will remain stable in the meantime.

But even though this information is out there, a key part of transparency is also that this information is easy to find, which I don’t think it is. You can’t find it on the main Elm page for example, and there’s no stickied post in this forum with relevant links for example. You have to search around to find things.

I’ve already talked at length about this particular issue before, because it extends to other aspects of the community too. In short, just figuring out how things operate is a very opaque task. Is Evan still around? Is the core team still operating? Who maintains various libraries and tools? Is my code going to break with the next release?

Overall there are some important analogies to The Tyranny of Structureless. Though it doesn’t apply 100%, there are some choice quotes about the kind of informal structure we have in the community:

As long as the structure of the group is informal, the rules of how decisions are made are known only to a few and awareness of power is limited to those who know the rules. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware.


The second is that informal structures have no obligation to be responsible to the group at large. Their power was not given to them; it cannot be taken away. Their influence is not based on what they do for the group; therefore they cannot be directly influenced by the group. This does not necessarily make informal structures irresponsible. Those who are concerned with maintaining their influence will usually try to be responsible. The group simply cannot compel such responsibility.

In other words, the informal structure we have today works well for the people who are “in” on it, but can be a big barrier of entry for those on the outside. Not because anyone is acting unfriendly, but because the rules of the community are often not well documented and also differ from what other open source communities do.

This is one place where I’ve always felt a level of distrust in the community, where we say we’re welcoming to outsiders, but only in the way we speak and act directly to each other. In the end, I have a strong feeling this informal structure is a hindrance for people to feel included, and it makes the community feel two-faced; a simple and welcoming facade that makes people want to be part of it, but then also a complicated structure that makes it hard to answer how to get things done that are not entirely in your control.

I get that things are the way they are because Elm isn’t being built by a big organisation, but I don’t think we’ve really discussed the implications of this setup on how it sows distrust quite easily. I think it would be a big improvement with a bit more formal structure, and better documentation of the way in which things work. And if Evan wants to keep the informal structure, then at least make it abundantly clear how that’s working (which I had some suggestions for in my previously linked post).

A and B teams
The Elm community is separated into two “teams”: the A team (core team and blessed contributors) and the B team (everyone else). As per the above, it’s a very informal structure, but it’s there none the less. It’s also important to state that this constellation isn’t bad in itself, but I do think it requires a good deal of trust to work well. That is, both teams need to have good trust in the other. Unfortunately I don’t think that’s much the case these days. A few examples:

  • With version 0.19, the B team lost capabilities they previously had: a foreign function interface (FFI) for calling JavaScript directly (restricting it to only the indirect calling via ports), and custom infix operators. Glossing many things over, I would say this was taken away because the A team did not trust the B team to use these features well.
  • With these capabilities taken away, the B team also lost abilities to solve some of their own problems. For example, creating good Elm APIs for interacting with various browser APIs now became something only the A team could do.
  • Evan has begun presenting his work on the next version of Elm in limited fashion, partly because he feels the B team has overloaded him in the past.

In other words, it feels like not much trust flows in either direction between the teams these days. There are other examples too, but I want to focus a bit more on the example with the browser APIs. When 0.19 was released, the A team essentially said “The B team cannot be trusted to build things which upholds the guarantees that Elm needs when calling JavaScript directly”. It may not have been intended that way, but I believe it was interpreted that way by many people on the B team. This also doesn’t have to be a bad thing, but it does put a lot of responsibility on the A team to then build Elm-native ways of doing the things that people want to achieve via calling JavaScript directly. If the A team had produced a lot of Elm APIs for accessing those web APIs, the B team would likely have a lot more trust in the A team today.

So why hasn’t that happened? Web APIs have been high on the wishlist for years now (as highlighted by State of Elm in both 2018 and 2022), and much work has already happened in the community, but much of that effort never made it into a state where it could be used with 0.19’s restrictions. I haven’t been part of all the discussions, but going via different threads and messages, my feeling is that the effort got bottlenecked on the A team for different reasons.

The A team had good intentions of course, wanting such APIs to be adhere to Elm ideals, and making sure they were of good quality in general. They also asked the B team for help, in theory making room for anyone to step up and add the APIs they needed. However, the A team had basically backed everyone into a corner: they put a lot of up-front requirements in this work, making it untenable for many people to engage in, while also making it opaque how to participate in it, since it’s very informal. It’s the point about transparency all over again, and now people were properly blocked by this process, because they could no longer build Elm code wrapping JavaScript code themselves.

Ultimately, the effort failed, and the web APIs you can use from Elm in 2023 are much the same as in 2018. And I think trust is at the core of it. Because I don’t think the B team felt they could trust the A team in this. It seemed like there was a low success rate in general, and the A team was asking for a lot up front before you could even start trying to write code to wrap the API you wanted, rather than more pragmatic access to APIs. Reinforcing for B teamers, that you’re better off not trying to improve your situation, and instead hoping someone else would be able to navigate their way through the process.

An alternative route that could have been taken could have been for the A team to build tools and documentation for people to use to verify that their JavaScript FFI was sane, and help them understand when to use it. There could also have been different distribution models for packages wrapping JavaScript APIs for example. Many of the pains people with using web APIs in Elm today would undoubtedly have been solved ages ago this way. This would hopefully have led to more blossoming in the community, where more people were able to step up and do good work, rather than be hindered.

This post isn’t about the specifics of web APIs in Elm though, so I won’t dwell more on that, but I think it’s a very strong example of where the Elm community has not been able to manage trust. The A team didn’t trust the B team, forcing the B team to trust the A team, and that trust has arguably not been rewarded. And so the relationship sours.

Which leads us to:

The echo chamber
When 0.19 was released with its new restrictions in place, many people who really liked Elm ended up leaving because they ultimately lost trust in the project for one reason or another. This also meant that a form of survivor bias built up in the community, where dissenting opinions became fewer, because if you were on the B team and unhappy about something in Elm, you had few options but to suck it up or leave.

The survivor bias also reinforced something that was already prevalent in the community before: a high reverence for Evan. This is not without reason, as Evan is very charming and tends to do well thought out work, but the trust of the B team was now becoming blind trust in my opinion. Part of the problem here is that, when the B team lost the ability to experiment with things like kernel code and infix operators, then that also artificially limited the B team from picking up some of the skills that Evan has built up, which just reinforces the distinction between the A and B teams. That is, there are very few people with experience in building APIs that bridge the gap between JavaScript and Elm without going through ports, and the B team now lacked a way to build that experience.

Ultimately this leads to a community where it becomes hard to criticize the A team because of a skillgap that is difficult for people to address, and where people are loathe to talk about the downsides of Elm, because it just reminds everyone how powerless they are to do something about it.

As an example of the echo chamber effect, in this discussion of VDOM rendering, Evan implicitly assumed use of lazy rendering in Elm when comparing to other implementations. This is a misleading assumption in my opinion, because lazy rendering in Elm is very easy to break without realising it. And yet Evan’s detailed (but, IMO, misleading) reply was one people supported a whole lot. After I posted my concern in there, a few people came out to agree about the downsides of lazy rendering, but I wonder, if I had not posted, would anyone else have questioned Evan’s premise?

I really wish for more introspection from the A team here. For example, listening to Evan’s talks, it’s very clear that he has thought a lot about how to manage other people’s expectations when they come to Elm from e.g. JavaScript. But it’s less clear to me how much effort he has spent on considering the consequences of his own actions on the community (like how an informal organisation can sow distrust).

For example, in the “What is Success?” talk from 2018, Evan discusses release cycles, and why people expect Elm to have frequent releases. His take is that this is an expectation coming from the JavaScript community, which simply doesn’t apply to Elm. But that sidesteps a few important points:

  • Up until 0.18, Elm actually had “frequent” releases (multiple releases a year).
  • Evan compares Elm to languages which had had long periods without new releases (Java, C, etc.), but doesn’t talk about how other compile-to-JS languages like CoffeeScript and TypeScript actually did have frequent releases back then.
  • A key difference between Elm and the languages that Evan wants to compare it to, is that Elm does not guarantee backwards compatibility. This is also often associated with frequent releases.
  • Though Elm is of course a language, it’s also a framework for web applications, which there have been many of, and which have often had frequent releases too.

In other words, maybe it was totally reasonable for people to expect Elm to have frequent releases in 2018, and this was a failure on Evan’s part to communicate how Elm should be perceived. That’s just an example of course, and not too important in itself, but I feel like I’ve seen a recurring pattern of “The problem is people bringing the wrong expectations to Elm”-like comments from the A team. Which feels like a lack of accountability, and unintentionally sows distrust, because it’s focused on what others are doing and perhaps shifting blame. A great way to build trust here, would be to acknowledge the precedents the A team are setting themselves, and how those might actually be damaging.

Distrust causes people to leave and frustrations to simmer, and I would guess that many B teamers have stopped engaging with the community because of it. And I know some people will feel like I’m beating a dead horse, but I think it’s really important that we realise how damaging some of the structures in the community can be. Which is also why I’ve acted frustrated before. Because I’ve felt the distrust, without having been able to put it into words. So at least now this is off my chest, and maybe there are others who are relieved that someone put this in writing because they felt something similar. I also hope this can be used constructively going forward.

I also want to say that it feels a lot like people are waiting for the next version of Elm to make things great again, but I really think Elm the language is not what is holding the community back. It’s the community management. And if Elm is to be positioned for the backend as well as the frontend, then that only means that the B team will come to rely even more on the A team, exacerbating any existing trust issues and potentially surfacing all-new ones too. For example, for those who do not feel their issues are being addressed currently, where Elm is only used on the frontend, why should Elm running on the backend build that trust?


I’m kinda curious about posts like this and have some questions that might help me to better understand.

  • Who is the A team and who is the B team, beyond “core team and blessed contributors” like who actually is this? I’ve been around Elm for about 5 years now and I’ve yet to understand who these people are.
    • I wonder sometimes if I’m viewed as part of the A team? If so, what makes me part of that team?
  • GOTO isn’t an Elm conference but a general programming conf. I wasn’t there but I was at elm-camp and did hear some of the same information. Evan trusts those who’ve been at his talks to not talk publicly about his work. If I were to speak publicly, would I not be breaking his trust? If I do break his trust to gain yours, am I truly trust worthy?
  • What’s impossible or prohibitively costly to use through some form of FFI today? Elm & JS FFI is actually partly what attracted me to. Elm and I’ve talked and written about it quite extensively at this point, and yet I still fail to find things I can’t accomplish with minimal effort. I’d love to hear about concrete examples of things that are impossible or too difficult to attempt.
  • Considering I’m the current author of Elm Weekly, is there anything I can do to better highlight things in the community that bring about more trust? I try to focus on what people are writing, speaking about, building, and who’s hiring but maybe I’m missing something?

Part of the problem is that I can’t tell you. I don’t even know who’s on the core team or if the core team still exists. It’s just a vague feeling that someone is “in” and others are not. It was clearer back when proposals for web APIs were actively being discussed, and there were who were clearly part of the process around that. But even then it was informal and not easy to grasp. I don’t think you would be on the A team, but I don’t really know the depths of your involvement with Elm so :person_shrugging:

I’m not asking to be relayed what the presentation was about, just asking for a heads up ala “This talk is happening soon, but please don’t expect to hear anything concrete from it. I would like to keep the contents private because of so-and-so, you’ll hear more when it’s closer to being ready.”

Secrecy isn’t bad in itself, so long as everyone is clear that it’s happening and for a good reason.

That’s besides the point I think. The State of Elm surveys show that the lack of native APIs are causing people roughly as much pain in 2022 as in 2018 (given some leeway in how the numbers can be interpreted). There was a push to do something about it, which fell through, while the A team look like they dropped the ball, and nobody has taken accountability for it (that is, there’s been no public retrospectives or explanations). Regardless of what actually happened, it looks as though the A team lost interest. Which all in all generates distrust.

I don’t know, I don’t follow unfortunately.


There is no “core team”.

Anyway, I think you should give it a rest, we’ve been round this topic 100 times it feels like. You can’t change anything, so whats the point?


To give myself some rest (and maybe others too). I think I’ve finally nailed what’s been making me feel the way I have about the community.


Thank you for laying out your feelings in a respectful way, as I know it can be hard to not burst out with frustration. I’ve been around for quite some time, and I’ve had times of distrust too. As laid out in the first part of your post, I think it’s mostly due to informal knowledge about the current state of Elm from its only official source, the elm-lang website. The limitations of Elm and its development specificities by Evan are now fairly known and should be made more visible on the website to set clear expectations. Since Elm compiles to JS, people expect that anything doable in JS should be doable in Elm too. But it’s just not the case. I also disagree with @wolfadex about everything being doable with effort. For example, JS can achieve sufficient speeds for math (high dimensional linear algebra, image processing, …) but it can’t be done in Elm due to the nature of its data structures. And it’s not doable via ports sanely. That being said, I’ve now just accepted that Elm has a more restricted use cases and limit my uses to those case.

Then on the second part of your post I think you have been confused in believing there is a core team (“A team”). I’m not aware of a core team except for Evan, and he has his own priorities and way of working as you said. In my opinion, “core” was an informal description of people working with Evan when he was at NoRedInk, as they had close connection with him, so it may have been easier for him to coordinate with those people. Maybe few others from when contributors were few but mainly they aren’t around anymore.

For the past couple of years, or even longer, community activity has been completely decentralized from Evan. Some have gone building their own language and tools, like Roc or Gren, some have continued building tooling and libraries for Elm, like elm-land, elm-watch, elm-spa, elm-review, lamdera, etc.

Maybe at some point, someone with enough time, funding, support will takeover Elm, rename it and change its governance system, but in a way that mostly consists in fixes and improvements, contrary to other current forks. This has not happened yet to my knowledge, but some individuals like @rupert are getting closer to that point.


Just for the record - I am nowhere near to that point. The idea has some attractions perhaps, but I simply do not have the time needed to get involved in that right now.

Thats what it comes down to really - those who do the work are those who get to make things happen in open source. I don’t get up in the morning and check on the internet what people are telling me to do, and I wouldn’t expect Elm to work that way either. So I think its pointless to say “things should be different”. If you really want to make things different you should be realistic about it and the huge amount of work involved and then if you really mean it then you might say “I will make things different by doing this thing”. Something I observe about Evans approach is that he does the thing then says “Look at this nice thing I created”, after the work is done. Which is a hard line to take, but I have to respect him for it.


Thanks for setting it straight (and same to @rupert). But there definitely was a core team at some point. You can search around on the forum to see it mentioned, and Evan called it out in this blog post in 2019 too. And I haven’t seen anyone talk about it for a while, so I was kind of expecting it to be disbanded by now. But it was definitely a thing at one point.

What their responsibilities were and what happened to it is all lost on me though.


@mattpiz I think maybe there’s a misunderstanding. Anything is doable in code, and Elm compiles to JS so if I can write it in JS (or wasm or C ABI because those are things that also interface with JS) then it’s possible. Elm just adds some nice guide railings and 99% of the time its easier to play within boundaries.

I find it weird that there are C+Node packages for building desktop GUIs and that’s normal but in Elm we have people upset that they have to mix Elm + anything.

Yes, my initial reaction would have been totally different if there was transparency in this project (trust is a result of transparency).
Simply to know where the project is maybe heading after more than 3 years of flat electrocardiogram, people had to pay $2,300 :face_with_spiral_eyes: + round trip plane tickets + hotel nights with the interdiction to talk about what they saw. The justification of this is to protect Evan from being overwhelmed by community requests.
This is opacity at its best.


This is a very insightful essay. I especially agree with the bit about the survivorship bias and the echo chamber.

Anyway, I think you should give it a rest, we’ve been round this topic 100 times it feels like. You can’t change anything, so whats the point?

While I agree nothing will change I still think discussions like these are helpful. Another (thoughtful) perspective on the issue never hurts; in the worst case scenario, we are just chatting.

Anything is doable in code, and Elm compiles to JS so if I can write it in JS (or wasm or C ABI because those are things that also interface with JS) then it’s possible. Elm just adds some nice guide railings and 99% of the time its easier to play within boundaries.

In my opinion this is the perfect example of the effects of the “echo chamber” that surrounds Elm.

I understand Elm is Turing complete and - even if it wasn’t - it interfaces with JS, a fairly unrestricted and widespread language.
Beyond theoretical computer science, however, there are practical points of friction in writing Elm code that have always been brushed aside as irrelevant but that are obviously important to the people that bring them up.

The use case of performance sensitive mathematical operation mentioned by @mattpiz is the perfect example: they can be done in JS at the cost of passing through the port system, which can become cumbersome. This additional cognitive load becomes very frustrating when the mechanic to bypass it is already implemented and used by the language, but forbidden to everyone because they don’t know any better.

The canonical answer to these kind of issues within the Elm community has always been to simply deny their existence and the developers that were facing them eventually moved to other tools. So now ports are never cumbersome, they are always “nice guide railings”.


To be fair, the secrecy was announced on the GOTO page, but it’s the kind of thing that the community deserves to be told directly still in my opinion.

Thank you kindly :smiling_face:

That’s my perspective as well. If nothing else, building trust is an important skill that is well worth refining for all of us :blush:


Ports are not the only means of FFI in Elm. If you’re artificially limiting yourself to ports then that’s on you for limiting yourself, not on Elm. There are also web components for FFI which are fantastic even when using other langs like Svelte, Vue, JSX, etc. There’s also intercepting HTTP requests, which is something I’ve been doing since well before Elm existed and way back when was considered normal. There’s even the ability to intercept other JS constructs like JSON, which again used to be considered normal well before Elm existed.

So perf sensitive math ops are totally doable with minimal cognitive load using FFI. I, and others, have published all of these hacks and more on GitHub and in blogs, so they’re not hidden away either. Which is why I always ask what the very specific FFI issues are because I’ve yet to find a JS runtime (browser, Node, Deno, Tauri, electron, etc) I can’t access with ease.

I, for one, like the fact that elm isn’t changing often and doesn’t plan on changing often.

I cannot understand the source of the urge to know “where is elm going to be in 3 years from now?”. Especially when this is followed, with slight frustration, by “I need to know, otherwise I cannot trust the project”. Where do you think it will go? - I would answer - are you afraid it will become faster or have more libs 3 years from now? - do you desperately ask your toolbox of hammers and screwdrivers where will they be 3 years from now?
What is wrong with being happy with a tool knowing it will still work 3 years from now? :slight_smile:

I also like the fact that the language is protected from a thousand different interests. Its scope is small and that’s good. I would hate to see elm transfigured by a thousand good and pragmatic intentions. It’s a valuable thing that a piece of software is managed cohesively, principled and conservatively, if for no other reason than that it’s rare.

There is enough room in this world for other types of projects with other priorities, but there should also be room for small, closed and rarely-changing projects. A project should be judged also by what it protects against, not only by how many different competing objectives can it balance indefinitely.

Echo chambers are bad when the chamber is huge, has its exit doors barred, mandates that no other chambers can be constructed, and the echo produced is of silly speech. But a small group of like-minded people (or dare I say, an individual) has been the source of most innovation since the dawn of man. If they all lived in echo chambers then so be it.

If you distrust the project (or Evan or whatever) be happy knowing you can trust that if it compiles it works. This is vice-versa in most other OSS.


I’m sorry, but I genuinely don’t understand how most of your criticism relates to my post. I’m certainly not advocating that:

  • Elm should change a bunch
  • Evan should publish detailed plans of how Elm will change
  • Elm should be like all other projects

I can’t tell where this misunderstanding comes from, so I would love to hear if I wrote something that can be understood that way.

In fact, I’m very happy with Elm the tool. My gripe is with the structural issues in the community which continuously generate distrust for myself and at least some others as well. Distrust brings a lot of pain with it for all involved parties, and I believe the community would be a better place to be if these issues could be addressed. If you don’t believe the issues I’ve highlighted are actual issues, I would love to hear why.

I do want to also disagree with you on echo chambers. I’m not sure I’ve used the term “echo chamber” in a scientifically accurate way, but that was also more to paint the picture than to be scientifically accurate. The underlying issues at this point are that it’s rare for anyone to criticise anything here in the first place. Things simply are the way they are, regardless of whether they are negative or positive. But when negative things are disregarded without due recognition, they don’t go away. Instead they just become the problem of the individual affected by it, rather than a form of collective problem. For issues which are actual individual problems, that’s fine of course, but we should be careful not to disregard systemic problems. In this case, I’ve been trying to point out issues which I believe are systemic, and which have certainly affected me negatively, but also others.

1 Like

I don’t think it is rare at all for criticism to happen here. It happens reliably about once every few months. All the same points come up, some people express annoyance or frustration, others make helpful suggestions. Nothing changes. Repeat…

I think the points you are making are mostly correct, valid and worthwhile - its just that we have been through them all before quite a number of times.


This is the key point of this rant: expectation that someone else does the work.

From everyone according to their ability, to everyone according to their needs?

A personal story: many years ago I won a huge contract to develop a large web application for a multi-billion-dollar entity, despite being disproportionately small as a company to carry that kind of contract. Not only, but (at my request) also received all intellectual property rights for the said product.

Massive value, for free. Life changing.

But that wasn’t enough for me. After a while I asked the person with whom I negotiated the contract if he could put in place a rule that the product must be used (for a subscription fee) by all departments?

Of course, he didn’t grant me that. Instead, he offered something way more valuable. A one-sentence advice that I follow ever since: You must lead the way.

Years later, many departments use the product, as do other customers. The arrangement keeps me on my feet to add value constantly. It’s now fully rewritten in Elm, to my great benefit.

It’s a cliché to say it, yet I do wake up every morning in awe that they are still paying me to have fun. At least one evening a week I catch myself thinking guilty “Hmm, didn’t do any work today.” Only to have a user email me the next day to say how yesterday’s update made a difference!

Elm has partly to do with it, as do many packages and posts by fine people here, and the general culture of mild non-conformity to the drab mediocrity of our profession.

So I’m just sittin’ here and thinking what in the world would make me rant about building trust after receiving these gifts?! Or tell any of 'em they are sowing distrust !?

Let me pass this little piece of life advice to you, unknown stranger. You received a gift in the form of an incredible and unique piece of tech. If you wield it properly, you might never again work a day in your life. Ask not for more. Rather, lead the way.

Consider another choice nugget of wisdom, said with some variation in many cultures:

An institution is the lengthened shadow of one man.

That’s true without exception. Questioning the community this way is questioning the one man. And words can be more devastating than any weapon.

We’re getting immense value for free. Let’s appreciate things for what they are and show gratitude and respect on gift-giver’s terms.

Want “trust”? Lead the way. Get busy. Make others feel their issues are addressed.

NB: Personalities differ; what one thinks well-intentioned post, another finds hurt.

NB2: I’m reminded of this nice write-up by Ryan Fleury. The second part beginning with “I received an email…” seems a suitable read for the occasion.


Yeah, you’re right, let me rephrase: we rarely talk about the downsides of Elm the language. Like:

  • lazy is very brittle
  • Error handling encourages swallowing errors instead of reporting them
  • Linked lists are a very wasteful default container to have, and the Elm List is incredibly difficult to work around (List really is everywhere!)
  • Additionally, Array is missing a lot of basic functionality (e.g. there’s no Array.member)
  • Consistently sorting strings in a case insensitive manner is quite difficult. I recently wrote an elm-review rule to ban calling compare directly, because everybody keeps messing it up.

And so on. The point is that Evan has generally asked many times for use cases to make sure the APIs serve their purpose, but if everyone feels things aren’t going to change, then why should anyone provide feedback? It risks undermining the quality we care about in the long run.

It really isn’t, and I think you glossed over the part where I argued that people had been stopped from fixing their own problems, rather than relying on Evan to do it for them.

Short answer: the pain I (and others) have felt. You can see it pretty clearly if you visit the Elm subreddit for example, but there’s been plenty of it here too. And I’m not one to shy away from pain, instead I am a big proponent of trying to heal it. And to heal it, we must confront it.

By contrast, what you’re arguing sounds more like we should all just be happy about this blessing we’ve received, regardless of what baggage comes with it.

So in fact, I am leading the way. By trying to heal the pain I and others (including Evan I’m sure) have felt over time in a constructive manner. You may disagree that this is worthwhile, and to each their own, but in my view, one of the greatest gifts you can bestow on others is honesty. In a constructive and usable manner of course, but still.

With all due respect, you have no idea how “busy” I am, nor about the ways in which I may or may not be leading the way. You make it sound like soft skills have no place here, that the only way to contribute is to build things, as opposed to e.g. building a friendly environment.

Did you find hurt here? If so I would like to hear more about how my insights were hurtful. Or do you assume others are hurt by it? And if so, why is that bad? If it means we can substantially reduce the pain many have felt going forward, then that is a worthwhile mission I believe. It’s about trying to learn from the mistakes of the past.


You lost me on that one?

Elm has no error handling, but Maybe and Result are effectively equivalent to checked exceptions. The only major language to have checked exceptions is Java, and frequently Java teams decide to go all in on RuntimeException to avoid having to deal with checked exceptions. Elm does not have that escape route, and the compiler forces the programmer to deal with all errors.

Right, but in many cases I’ve seen, developers end up just using some default value when there is an error, letting the program continue without caring about the error. That’s not necessarily wrong either, but because it’s the path of least resistance in Elm, it happens more than it should. I’m personally big on observability, so my main pet peeve with it is that I can’t see that this happens, because logging something is arduous.

Possible solutions:

  • Better modeling to avoid some errors in the first place. But there might not be time for this, or such modeling might be in conflict with other requirements.
  • Returning Cmds from functions to log stuff. But this is only viable for code called via init or update, since you can’t handle Cmds in view functions. And even then, returning a Cmd is strongly associated with logic that needs to interact with the outside world, so making random functions return and pass around Cmd when their domain logic doesn’t need it also makes the code harder to understand.
  • Instead of Cmd, one could have Log type that gets passed around that functions could use, but then you need to return a tuple of (data, Log) in many places, making piping harder. So I think some language support would be needed for this to be ergonomic in the long run. Something like Rust’s ? operator might be a source of inspiration. If nothing else, better error propagation might also make the situation nicer.