Why and how we retired Elm (opens in new tab)

I interviewed somewhere once and mentioned that I did some projects in Erlang and learned a bit about functional programming. The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.

This was one of my first tech interviews after spending nights and weekends self-teaching. I only mentioned this at all because the dudes LinkedIn said he was involved with some Erlang orgs.

Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked. Eventually i got my first engineering gig at a more humane company and have been doing great since

I learned recently that the other company went to zero. Good riddance (though I am bummed for folks who lost their jobs)

After ten years of using Scala, I think if I was running a Scala team, the safest thing would be to hire people who are not excited about Scala. Like it, yes, but not be super pumped. Developers who are primarily motivated by the excitement of learning new technology tend to write code that commits everyone around them to learning just as much, just as fast, which obstructs and pisses off developers who are primarily motivated by getting shit done. A team needs to strike a healthy balance between powering up with new ideas and getting shit done, and having people in the team who skew to one side too much to either side of that balance is a recipe for conflict. Eventually people will leave, often highly productive get-shit-done people, unless you fire the disruptors first.

Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive.

Personally, I think being excited about a cool language is a mixed signal. An interest in technology is great, but on the clock that has to be thoroughly suppressed in favor of actual business needs and constraints. At home, I like fucking around with all sorts of stuff. At work, I'm a confirmed member of the Boring Technology Club. [1]

[1] https://boringtechnology.club/

He doesn't go into much detail here but what I _imagined_ he meant was that if someone came to an interview excited about Elm but knew nothing about the company, that would be a strike against them. If someone came excited about Elm _and_ was interested in the company's product that was fine.

But this is just me filling in the blanks as I think they should be filled in. It'd be great to see him spell this out a bit more.

It does feel like a landmine they've set up, perhaps another benefit for them of moving to React is that they can stop worrying about it?

I've seen a lot of companies that superficially resemble Culture Amp. I've seen one that uses Elm. I'm probably going to come in talking about Elm.

I have some sports-related decoration in my living room. It would be a weird experience for someone if they came in, saw it, started discussing sports, and I was put off by that.

I thought that same thing.

Besides, it wasn't liking a particular _language_ they took as a bad sign, it was _functional programming_.

If you like functional programming, and you encounter a candidate who also likes it, and you consider that a red flag ... that seems highly irrational and inconsistent.

(Not trying to sound combative. I appreciate the original post! Just being candid about something that sounds odd to me).

Edit: I would bet there's more context that was out of scope for the original post. I would not be surprised if it were much more than just "liking functional programming." If someone is overly zealous to the point where you might wonder if they'd start an uprising or storm off in a rage if asked to do anything other than functional programming (or anything else for that matter), that would be a red flag.

It’s not uncommon.

I’ve twenty plus years experience building software on the JVM. From EJB’s of early 2000s to original Spring, then the more recent Spring Boot, a plethora of other JVM tooling. Then I’ve used various languages on top of the JVM, Groovy, Clojure, ETA, Scala. I haven’t used Kotlin only because not had a role that needed it. Then I have a list of non JVM languages, frontend stacks and sysadmin/cloud or as they like to call it DevOps

Scala has been my JVM language of choice for the past ten years.

When I was last applying for jobs my experience with Scala seemed like it was a huge negative for the companies I interviewed at. It was “you’re one of them” and things got frosty after mentioning I’m reasonably experienced in Scala and its functional programming libraries and enjoy it as find I have less bugs.

If I removed Scala from my cv and never mentioned it I got a much more positive experience.

Some of the roles I didn’t mind it going frosty. My red flag radar went up aswell and I got the sense of big balls of mud and I’d probably hate it but needed a job. Some it was a huge disappointment, exciting company, exciting projects, perfect fit skills wise but I was seen as a Scala developer not a great fit for Kotlin as excited as I was to use it because of the companies projects.

Not sure what I’m trying to say but this “not good fit” attitude doesn’t seem uncommon if you have used specific languages/tools/things people interviewing you don’t like or didn’t grok. Tech talks a lot about diversity which is mostly virtue signaling and forget diversity of minds is also good.

I run an OCaml project, but I would reject interview candidates who say they are primarily interested in the project because of OCaml. It's definitely a negative factor in the evaluation. I don't need someone adding baroque functional programming purity into a working project with real customers and regular developers. Plus there's a vast amount of C code which is not going anywhere, so I assume they would hate dealing with that.

Yeah, that seems like a weird rule to have. If anything, I’d want engineers to be excited about languages, tools and paradigms, even if they weren’t exact fits with the current stacks we’re using.

The whole article’s point is that these change, anyway. So those people they’re rejecting on this silly rule might eventually become the people they crave if functional programming becomes cool again at Culture Amp in 5 years.

Especially since it's Elm. How many people would have any idea how to even use it & not mention that they're excited by it an interview? Counting that against someone is probably an even worse interview practice than being overly reliant on leetcode. And I hate leetcode driven interviews.

It also seems like the type of bullshit people would spout when asked "why do you want to work here". (Real answer is because i like money, but you can't say that in an interview, and talking about language is generally pretty safe)

“Culture fit” always seems like a cover for decisions that are arbitrary or just personal biases…. or in some cases bigotry.

> I understand the kind of person they’re trying to avoid hiring by accident

I think I might be that kind, firmly in the ivory tower.

I always feel frustrated and isolated because people just don't engage and acknowledge my concerns. I post in a busy Slack channel that the new API we're developing wont respond in less than half a second on my own computer, I ask if my setup is wrong or if our API code is just slow as shit. Nobody answers, but it reinforces my role as an ivory tower trouble maker. Two months later everyone is panicking that the new API is slow as shit. Or I find that our test database has a millions of plaintext passwords from real users (yes, some of you reading this were probably included), after arguing that this is effectively a data breach and we're failing our customers I finally prevail, and we wipe out the passwords from the test database at least, but this causes some extra work fixing some automated tests. Again, I did the right thing but in the end I was viewed as a trouble maker. Etc. This reflects my entire career. It just feels like something is wrong with the industry.

As they said, it's an indication not a "rule".

Anecdotally in interviews, it seems that most people that say that they like functional programming, tend to like the idealized notion of functional programming more than actually building real-life systems with it. When asked about their past experiences with functional programming you'll rarely hear about anything else than toy projects (in contrast to other things people often list as things they are "excited about").

Connected to that (anecdotally) when working with them, those same people tend to be the ones that try to make the code "clever" or overly perfect (in an attempt to fit into the ideal functional programming paradigm). That usually leads to code that's extremely hard to read and maintain as a team.

I think full functional programming languages can have its niche, but I think most projects are better served programming languages that only borrow from functional ones in certain aspects of the language/standard library.

I agree that this sounds concerning, but in the context of the article, I see where it's coming from. They identify as a "product organization", not a tech one. They want people who are more excited about the problem they are solving than the tools they will use to solve it.

It reminds me of an article I've seen that talks about how companies have such generic "values" that they're not even worth having. Innovative? Well, of course. Integrity? Duh. Better values would be those that not everyone will agree with because it tells you what that company actually stands for. "Product over Tech" seems like a great one.

Anyway, as someone who has definitely been super intrigued by FP, I was initially alarmed by this comment, but understood it better after some thought. After all, he's not saying it was a litmus test, just something they noticed that might be a hint for who would and would not work well at this particular company.

I work at Culture Amp and have been involved in hiring decisions, including for people who were excited about Elm so happy to comment here. As others have guessed, this is an "indication" not a "rule", and it was more about people who were applying _only_ because of the tech stack, rather than a sense of wanting to build a quality product, or alignment to the company's mission (improving workplace cultures). We hired plenty of people who mentioned Elm. I mentioned Elm in my interview.

Part of the reason for this is very pragmatic: during the time when Elm was in common use at Culture Amp, almost all of the APIs that Elm would have been talking to were written in Ruby on Rails, and our engineers were expected to be able to contribute to work that required changes in both the Elm front end and the Rails API. If someone was a functional language purist, and only wanted to work in say Haskell on the backend... then they wouldn't enjoy being on one of our product teams where writing Ruby on Rails code was part of the day-to-day.

I felt the same and wondered what the right answer would be. I generally haven't interviewed at companies where I didn't know enough about them to be excited about their domain, and then be excited about their domain, but ultimately as a dev they pay me to write code so I want to also be at least as, if not more so, excited about doing that.

I guess the right answer, if the goal is honesty here, is to couch it in terms of "I'm mostly excited about <your problem domain>, but to be honest one of the reasons I even decided to go this far in the interview process is <tech feature>" or something? I'm not good with people, so I'm as much thinking out loud here and asking for feedback as much as asserting what I'd do.

It's always seemed to me like one of the main perks of having your company use a weirder functional language was the ability to attract talent that preferred it to more standard choices. An experienced developer might be willing to actually take a pay cut if it means using a favorite language rather than grinding out another Python/Typescript CRUD app or what have you.

I understand where the author is coming from, but I think having a preference and being excited about a tool your going to be working with all day is a reasonable thing, and it's ok if developers are excited about a technology for its own sake as long as they can make that compatible with continuing to make the business work.

I’d wager some big bucks that this never actually happened. Sounds super made up. No way they were like “Well Shelly really knows what she’s talking about, but too bad she’s excited about functional programming… that’s just so 2015.”

I think it's fair, even though I'm probably someone who would be knocked by it. You make different tech decisions when you're motivated by the results vs the technology, even if it's not conscious

What's unfortunate is that it's really hard to get motivated by a lot of the products our industry pays us to produce, so we drift towards focusing on the technology instead

My take on this is that he wants to avoid "science projects" being produced rather than client work being finished.

Hiring rules in general are bizarre.

I worked at a place that doesn't hire developers who use Visual Studio!

Another only hired ugly and disabled women for specific jobs to combat male sexual misconduct. Of course, an "ugly, crippled woman" got pregnant by a co-worker in no time.

It’s best not to hire an employee who is excited about anything. These people are running high on emotions and will almost certainly be a troublemaker later. Better to hire a professional who is ready to work and is cautious about rocking the boat.

something I always remember from my brief time lurking on comp.lang.lisp is a post saying a really good language is one that would get you to take a job just because you would get to work in it. it's the pleasure of using a tool that fits well in your hand and works with you to get the job done.

My thoughts exactly when reading that.

What are your thoughts on the direct descendant, Roc? [0] I know it's pre v0.1 so maybe you don't have any, but as a fellow Elm lover it seems pretty compelling on the surface albeit less directly frontend-dev focused.

[0] https://github.com/roc-lang/roc

> it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it

This is something every framework is up against, since React won. It has become more and more of its own JS dialect, so devs that grow up with it also “think in React”.

> not viable anymore at a medium or large company

That's not really the point made in the article, he mainly talked about the difficulties of maintaining a hybrid codebase split between Elm and another framework, and how their specific company situation nudged them to choose React to go all-in with

Elm is used in many medium/large companies. The biggest ones are NoRedInk and Vendr, the later reached 1B valuation recently with 600k+ loc Elm codebase.

>> we seek to hire people who are mostly excited about our product and its mission,

Consider the source: https://www.cultureamp.com/

A completely generic me-too startupy startup. I can't even figure out what their product is.

Doesn't this:

> if the only reason an engineer wants to work for you is because of your tech stack, that may be a warning sign. Culture Amp therefore avoids hiring engineers who are purely technology-focused.

For the case of senior engineers conflict with this:

> Perhaps the greatest challenge for engineers as they reach more senior levels in their career is to make decisions that balance the moment-to-moment joy (or frustration) that a given tool affords them

Because the language is frozen in 2019, it's last meaningful release.

It was doomed to end this way due to the close leadership and being developed behind closed doors by a single developer.

This kind of projects, as amazing as they are, and Elm is absolutely an amazing language and project that has changed and influenced web development meaningfully, are just untrustable.

If you can't have a discussion with library authors where they confront their ideas in the open, you need to move on or pay the consequences.

I don't know, these two quotes don't immediately take me to "Stockholm syndrome."

That's a bit too short, I think. TypeScript plays a role as well, as does an acquisition.

I liked the description of the internal discussions. Working at a larger company where decisions are made in a completely different part of the organization and you're stuck dealing with the ramifications leaves me a little nostalgic for a smaller firm where it's practical to engage all stakeholders.

No, they didn’t end up using WebComponents. The real issue was that it was too much trouble to have Elm & React in the same codebase. They were migrating the code to Elm, but then merged with another company. Now 75% of their company was only familiar with React. Only 6 people were strong Elm advocates.

Because React and TypeScript had progressed since they first decided to use Elm, because the cost of maintaining two frameworks was high, and because the cost to switch to Elm was out of reach, they decided to “contain” Elm by no longer permitting it for new components.

I would say the Web Components portion of this article is a detour, mainly he was explaining his discovery you can't utilize web components to marry React and Elm together as one would hope. The real TLDR is it's too hard to hire Elm devs.

It also didn't impress them. I don't like the idea of using Web Components with Stencil either. I like Web Components though.

They had an acquisition where the code became 75% react over night due to the acquisition. This was the major turning point. Purely business, purely popularity. It wasn't technical superiority.

Hmm, that's not true?

GitHub, Atlassian, Microsoft, plenty of greatly and widely used design systems out there.

The problem is different: they are huge investments that most non-large companies cannot afford for economic and logistic reasons.

I’ve seen this at 2 companies so far and tend to agree. At this point if your design system requires more than css its probably too complicated.

Maybe design systems work when you are the size of google, etc, but otherwise they are way more work than people seem to believe.

There’s also the part where they just let teams get away without fulfilling their responsibility to update both versions of a component and just let their tech degrade.

I'm at the point now where I think a design system team is huge mistake unless you've got 25+ people to permanently staff it. At best the team will provide more consistent UI/UX. At worst they will slow all other teams to a halt with poor documentation, bugs, and broken libraries.

I've seen three different ~100 person companies throw decades of person years into building out design systems, each to eventually throw it all out. By which time many teams have been forced to adopt the half finished project, so now they've got to tear it all out.

We all know now not to build our own databases unless there is an extremely unusual need. In another decade or two we'll say the same thing about design systems.

There's nothing wrong with some CSS colors and basics. But you'll only invite ruin if you try to build out (or wrap) React or Angular libraries. I'd guess right now that a full design system library takes about 25 person years to complete and 10 person years per year to maintain. By which time the target language and libraries will have changed so much you'll have to start over at the beginning and start upgrading.

Every company I've seen try this staffed the team with about 5 people. So they've got about 5 years to get to 100%. What has changed in the front end in the last 5 years? I know one design system team that started 5 years ago on an Angular 1 design system. No they don't have Typescript, no it doesn't work in Angular 16. I know another design system team that started about 6 years ago in Angular 1, then restarted 4 years ago in Angular 2, leaving most of the company on the Angular 1 version which was about 40% complete. Then 3 years ago they decided to stop forward progress for a year to go back and add Typescript types to existing components. They still aren't 100% on the Angular 16 version.

(I think Typescript is great, but I'd guess it adds at least an extra 5 person years to the timeline, since you have to be pretty great with Typescript to accurately apply it to a design system.)

All this to say, building out wrapper libraries for a design system is _really hard_. Just the documentation is probably 5 person years of work. The whole thing is expensive, tricky, and error prone. Unless you can staff 5 teams of 5 permanently, the front end just changes too fast to keep up. The ecosystem will look so different in five years, you'll need a whole division working forever to keep up and move to new tech while simultaneously maintaining the old versions.

And heaven help you when your designers get tired of the look of it after a year and want to redesign it all again. Because they will. (Wasn't that the point of all this, easy changes to the UI?) Now you've gotta go back and update all the half finished Angular 1 code and release a new version, along with your half finished Angular 16 library.

The golden path here is to just provide some basic CSS for buttons, tables, uls, inputs, etc, along with documentation and a site that shows it all in use. Put it up on a CDN with a version in the name so teams can upgrade easily. This whole project could be done in under two person years, just a UI engineer, a designer, and maybe a QA person. It's quick, and after it's over, everyone can work on something else. There's no need to keep a big team staffed forever. There's no need to do a rewrite for React Hooks or whatever. The CSS will work forever. Next year when the designers want a new set of colors, spend a few months to have someone release a new version. Don't change any of the CSS selectors. DON'T CHANGE ANY OF THE CSS SELECTORS. Everyone bumps the version on their CSS src tag and it just works. Easy day.

MS SQL? I've been a ("full stack") web developer for 18 years now, and I've never seen anyone use MS SQL for a web application. That's immediately a tell that I'm in a bubble, and obviously you are as well if you think MySQL/MS SQL are even in the top 3 (behind Postgres, MongoDB, Oracle?).

Since you mentioned it, I just asked ChatGPT and in a list of 30 unicorn companies based around web applications, half of them were built in Ruby which isn't even in your list.

If becoming a successful company is part of the justification for technology choices, you'd need a very strong argument to not pick Ruby.

I'm not really sure that's true, but if you want to make strong recommendations I feel they need to be backed by data, and not some hunch on what technology is popular right now. And Ruby has been less popular for over a decade now, and it's still used by half the most successful companies out there. So the data isn't on your side here.

> These technologies get the job done, people know them, there’s massive community support and critically important when you’re hiring, you’re fishing in the big pool.

There's probably some company out there who used this argument as a reason to not switch from Perl to Python that are regretting their dwindling hiring pool.

> Also, ChatGPT knows these technologies well and that’s increasingly important.

ChatGPT writes Haskell better than other languages I've tried like python or javascript. It even works well fixing the type errors.

This 'reminder to be kind' bullshit is why I got so frustrated with Elm, and ultimately quit using it. For the same reasons, I actively recommend against using it, and I will recommend any place I find using it to migrate away. And I love the actual language and approach, it's in many ways the best experience I ever had in web programming. Ruined by this awful passive aggressive approach to management which itself triggers criticism (by the Elm 'team' disengaging at the slightest hint of 'negativity' such that everyone is always walking around Evan on eggshells).

For an example see e.g. https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

Evan has always hid away from confrontation about his work.

There are libraries for using react components in Elm, but I haven't used them. I bet those weren't considered though.

Once again, backwards compatibility is the main name of the game.

Indeed, if Elm had emerged earlier that could have changed everything, but I'd wager that it is poor leadership and close-mindedness which really killed it off for good (Elm users will deny this, but as the world has moved on, Elm remains stagnant).

There is no shortage of complains about the devs uncanny protection of the core language and their opinionated approach to allowing interoperatbility with the JS ecosystem. Which is a shame because pragmatism always works out against dogma.

Imho, TS is just a crutch that helped JS to collapse from its own weight but still leaves many issues of FE development out in the open. In an alternative timeline, Elm would have been a path towards more harmoneous fullstack development which is more accepted by people coming from the BE side of things.

> maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.

It's an intriguing thought exercise, but even with a head start it would have had serious issues like it has today; the pace of the language is _SO SLOW_ that in today's world it just has a hard time due to that.

I'm not asserting that it SHOULDN'T be slow, that the reasons for doing it that way are bad, or anything like that; it just is what it is, and that's a downside for many people.

> I can't be the only person who wondered why a company was still using the Elm email client.

You are not.

Gopher less cryptic humor.

Yea this looked a bit odd, and I'd not heard anyone say it before. I have therefore made a mental note for job interviews: "I was attracted to your job ad by your tech stack, but I made the application because I was just BLOWN AWAY by your awesome mission to re-invent inventory cataloguing."