Clients expressing doubt about choosing Elm

Maldus512 · 2021-02-07T16:06:50.553Z

rupert:

I am curious, what makes you think this?

“Meltdown” is a strong word, but the atmosphere in the Elm community is less than ideal for a variety of reasons and an outsider will pick up that sentiment pretty fast when there are so many blog posts voicing discontent.

rupert:

I wonder if the existence of Reddit /r/elm does more harm than good. Would a proposal to close it down be out of order?

I think that would be a terrible idea. Besides being partially helpful (“Elm is dead” stuff only comes up from time to time) this would add up to the narrative that the Elm higher ups silence dissent. Also, I can almost guarantee that some r/ToHellWithElm would pop up just to spite the language.

DullBananas · 2021-02-07T21:06:39.695Z

Maldus512:

Also, I can almost guarantee that some r/ToHellWithElm would pop up just to spite the language.

There’s already r/f###apple, r/f###nestle, r/f###caillou, r/f###pencilsharpeners, r/f###wasps, and many others, so I wouldn’t be surprised if r/f###elm is created

opvasger · 2021-02-08T14:07:29.584Z

carltongibson:

The situation has got bad though. The bad vibes in the community have reached out such it’s now the dominant theme if you search for Elm.

Dominant in terms of engagement/attention - if you’re sifting past the emotionally-charged uproars, it’s positive and good.

Theories on why these emotional posts gets so much attention has been put forth - I believe the effect is described in the talk called “the hard parts of open-source”?

JR2 · 2021-02-08T22:55:11.390Z

Can’t some folks come together and fork Elm and move forward with it?

I’ve spoken to so many people in the web development world about Elm and many agree it’s fantastic but because of the slow updates they can never be certain if the project is dead or alive.

I’ve invested a lot of time into learning Elm and have a personal production application that uses it. But with client projects I have to reach for React. It would be bad of me as a developer to implement Elm in client projects when it’s future is always in the balance.

It seems a lot of people want Elm, but Evan doesn’t have the time to put into it. He has to let it fly, or die.

Maldus512 · 2021-02-09T07:56:41.417Z

While I believe both technical and management decision that drove Elm up until now deserve their fair share of criticism, I have to tell you that this comment does not really make sense.

JR2:

Can’t some folks come together and fork Elm and move forward with it?

I’ve spoken to so many people in the web development world about Elm and many agree it’s fantastic but because of the slow updates they can never be certain if the project is dead or alive.

Elm is not dead. It understandable how it might appear so for an outsider, but it really takes a minimum amount of contextualization to realize it is moving forward at an acceptable pace. Evan is not big on roadmaps or announcements but you can find a comment from him reassuring that he is still working full time on Elm every month or so.
Yes, there are issues and pull requests that remain open and unanswered for years. Those are also very minor problems and I’ve yet to find or witness some breaking bug in the Elm ecosystem that has been ignored.
Elm works, and works well for its niche. The bad rep that has built over the years have nothing to do with slow development, those are just strawman arguments that get thrown around out of frustration; its issues are (in my opinion) mostly limited to attitude and communication towards the community. This is still a problem for pushing Elm in your workplace because the surrounding ecosystem suffers from it, and a project with small library support is less compelling and looks less stable. Also, someone might (rightfully) dislike the core team’s approach and decide that they don’t want to work like this, just like someone might prefer Open Source tools instead of proprietary ones.

JR2:

It seems a lot of people want Elm, but Evan doesn’t have the time to put into it. He has to let it fly, or die.

You have to realize that declarations like this might sound hurtful for some, especially when it’s quite clear that work is being done and Elm is quite alive. Its community is small and its numbers are not growing, but saying stuff like this only fuels the argument that Elm’s criticism is not serious or founded.

JR2:

Can’t some folks come together and fork Elm and move forward with it?

It doesn’t really make sense to “fork and move forward” with Elm. Its community is already small and it wouldn’t be worth to split it again. Regardless, Elm was incredibly successful at influencing the whole landscape of programming languages; besides tons of libraries for other languages that tried to imitate it, a whole array of entirely new languages was born in its wake (also following this very idea that “Elm is good but could be better”). Instead of forking Elm your effort is better invested in making an Elm-like library for Purescript, Rescript or Mint (or so many others), languages that are more powerful and expressive and follow a more open development process. This is not an invitation to leave, it is literally more efficient to try out alternatives that are already there.

Last but not least, the Elm Team is openly opposed to forking efforts. After 0.19 some people were discussing the idea, and a figure prominent in the Elm Team came to complain in a pretty harsh way.
I remember reading somewhere that Evan himself is not opposed to a fork as long as it doesn’t use Elm’s name (do not quote me on this). This, together with the fact that the Elm compiler uses a pretty restrictive license in terms of derivative work makes me think that forking Elm just to fix some perceived issue in this regard would lead to a lot of unwanted conflict.

Sorry for derailing the conversation a little, but I really wanted to make clear that slow development and sparse updates are not a real issue.

Lucas_Payr · 2021-02-09T09:54:32.204Z

Maldus512:

I remember reading somewhere that Evan himself is not opposed to a fork as long as it doesn’t use Elm’s name (do not quote me on this).

I believe you mean this discussion?

Afterthoughts around about Kernel code and custom operators complaints Request Feedback

Just one note. I don’t think any fork should include elm in a name. I’m kind of fan of interpreting this Clause in BSD3 quite strictly: 3. Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. I think it protects original authors from being tight to stuff they don’t approve of, what ever it might be. I would suggest picking up some name of the tree for name…

gampleman · 2021-02-09T12:23:58.203Z

Re the “why doesn’t someone just fork it?” (and presumably continue development with a different governance and development attitude) question: It is not clear that one can get the level of quality and consistency that Elm has with a significantly different process.

Or in other words, everybody knows that “design by committee” is suboptimal, but we at the same time love to talk about “bus factor”.

malaire · 2021-02-09T13:09:40.116Z

Maldus512:

Yes, there are issues and pull requests that remain open and unanswered for years. Those are also very minor problems and I’ve yet to find or witness some breaking bug in the Elm ecosystem that has been ignored.

This code hangs forever and this bug has existed for years in Elm:

String.right 1 "🙈" |> String.toList

pd-andy · 2021-02-09T13:30:28.425Z

Honestly I don’t think that’s it.

Developing a language is hard work
Forking a project is hard work
Coordinating work with other contributors is hard work
Getting people to use your fork is hard work

Although I think there are plenty of people talented to do that hard work, I expect the main reason why it hasn’t been done is those people have complained and subsequently left the community at different times.

Forks (besides one-person forks) happen when a group of people with similar ideas on what the future of a project should be get together and start working. There’s no group of passionate people to make that fork happen, just a steady trickle of common complaints and attrition.

rupert · 2021-02-09T14:00:52.213Z

Rather than a fork, I think what Elm could benefit from is a release branch. Let me explain…

Suppose you are working on some software system that is undergoing an ongoing R&D phase. At some point its nearly ready and your sponsor is needing to find some customers and ship it to pay for all that R&D. At that point you maybe do some tidy up on the mainline, and then take a release branch. On the release branch you do the necessary preparation work to ensure the customer gets a polished product - like adjusting the look and feel, integrating it with Active Directory for the clients single sign-on, add some custom database fields, stuff like that.

When the customer starts using the software for real, they are bound to do things that you did not anticipate, so you will get a stream of bug reports coming back from them. You fix these on the release branch, but you also apply these patches back onto the mainline. If you are smart you also first write a test to demonstrate the bug, then fix it, and add the test to the regression pack so that the bug never comes back, if somehow its patch gets overlooked on some branch (happened to me once, got called out by my boss on 31st Dec to fix a date rollover bug to 1st Jan at Client Co. and it was all my fault…)

After some more R&D, the next version of the software is ready. Customers may be slow to upgrade as it is not necessarily fully backwards compatible with what they already have - but you still have the release branch to support them until they are ready. When they upgrade, they get a completely new version from a new release branch.

So a release branch in some ways leads the mainline, because it is finding and patching bugs that feed into it. But on overall direction of the R&D, design of the system, features and so on, the release branches are downstream from the mainline project.

For me Elm is a goldilocks language, my favourite actually, I think overall the best programming language yet invented. So I would not want to fork it because I have no improvements to make to it as a language. But as people have noted before, its a bit of a walled garden. Thrust into the real world there is clearly an unresolved friction. That friction isn’t easy to fix, due to the way that the compiler and package system are tightly integrated, and the bottleneck on merging fixes back into it. That said, some of that friction has been very nicely fixed by third party tooling efforts along the way (thank you ).

Now imagine that we had a release branch to handle the interface onto the real world. A place to fix issues, explore opportunities, support customers, and a place where those things could happen with less friction but a greater plurality of contributors.

terezka · 2021-02-11T11:45:41.938Z

Hi everyone!

Heartwarming to see so many people caring about the future of Elm.

I think a fork is a wonderful idea. As unintuitive as it may seem, I don’t think of a fork as a threat to Elm at all. The more choices are available, the better a fit is available to the individual, which is only good! As I see it, only positive things can come of it:

a) Either the fork is a great success and everyone uses it instead. Maybe Elm learns from it or become obsolete. Regardless, there has been progress and people are happier!
b) Or the fork doesn’t work out, and we will all have a greater understanding of why things are the way they are. Also good!

If some people have a different vision for the language than Evan, then they should absolutely have the freedom to unfold and work towards that vision, just as Evan has the freedom to unfold and work towards his vision. This is the reason we have such a diverse programming language landscape in the first place: Elm was initially inspired by Haskell, but wanted to explore different priorities/goals and here we are! Maybe another great language will come from a critique of Elm. The communities of course remain closely related, just as Elm is close with Haskell and JavaScript- just more harmonious because more people can choose to work the way they want, towards the goals they wish.

As others have noted too, of course it is a lot of working to keep such a fork alive, but I think it’s worth a shot! There are obviously some very prolific people who wish for things to be run differently, so I trust in their passion to shepherd the project along. All that posting energy could be turned into programming! I know Evan supports a fork, too! Just make sure to call it something else, so there is no confusion about what people are choosing. Maybe “Ash” would be a cool name? Or some other three-letter tree name? Worst case scenario, it could function as a community-lead “unstable” release, where independents do the work of keeping it up to date / merging in changes, which would be a nice compromise: Evan doesn’t have to do extra work, and everyone else gets the changes they want.

Again, I recognize everyone is coming from good place, and I’m grateful for your engagement!

eimfach · 2021-02-11T17:17:04.247Z

c) One or multiple forks live besides Elm which bring new ideas of what are good approaches and what to better avoid. A spec for Elm would also help to implement a diversity of compilers (like in C Land) in other languages, maybe so with different targets (Benefits of Elm Type System + TEA on Server)

Also I just came over this saying, which I kind of must agree with: “Wise languages designers start small and stay small.”

nil · 2021-02-13T15:13:22.865Z

I did some analysis on Elm for a company early 2020 and ended up skeptical about applying this to a large Line of Business application.

Here is my first impression as I recall it:
The elm-lang.org website had no recent updates or blog posts, the Search Result on google was broken (still is), the reddit was dead or dying, the discourse had some activity but mostly locked threads, the package manager has a lot of packages with few or no updates. Relative to React there are few public apps demonstrating its potential. I read some of the impressive, and some of the dismissive blog posts. I quickly dismissed the enterprise potential, and the project ended up with React.

I was intrigued enough about the promise of no runtime exceptions to continue learning the language and following the community on my spare time. After getting to know the language, its design goals, it packages philosophy, and its community better I now have a different view. It’s not a clear-cut decision in Elms favor, but it would not be dismissed before technical experimentation.

I think Elm and this community has something great brewing, but elm does not have adoption as its focus. And this lack of driving adoption is a blocker for companies looking to adopt. They default to the same safe choices as their peers, and elm no longer has that much of an perceived edge to other languages that the risk of being non-conforming is worth it.

Finally, this is not a personal or organizational critique. This is how I perceived the project from the outside when going in with NO prior knowledge to Elm. I write this as a data point to how this can be improved, as I have since become interested in the language and its possibilities.

Janiczek · 2021-02-13T21:38:23.110Z

evancz:

and I am sure those authors would appreciate a surprise blog post from a happy user.

I think that’s a great idea, and personally it’s a takeaway for me from this thread: “Let’s write a blogpost about ‘Elm at GWI’.”

Let’s “fight” the vocal negative minority and lack of outsiders’ feeling of uncertainty about whether Elm is dead, by being more vocal about our experiences writing Elm at work.

I feel we, as a community, are able to come up with great testimonials and experiences when prompted, but it might help to be proactive about it.

Actually one thing that popped into my head while writing this: what about having some logos and testimonial quotes on the Elm homepage? Ableton, MS, IBM are some that come to mind, … GWI , Gizra, etc. etc.

eimfach · 2021-02-14T09:43:38.218Z

Janiczek:

Actually one thing that popped into my head while writing this: what about having some logos and testimonial quotes on the Elm homepage? Ableton, MS, IBM are some that come to mind, … GWI , Gizra, etc. etc.

I wonder who do you address with this ?

Janiczek · 2021-02-14T14:07:00.288Z

It was an idea aimed towards @evancz since he maintains the Elm webpage.

terezka · 2021-02-16T07:24:39.358Z

Love this energy! I’ll add the logos to the site (and fix the search result issue). If you have any testimonials at hand, let me know too! Thank you!

Janiczek · 2021-02-16T08:48:55.030Z

Tereza, I suppose you’ll need to ask the various representatives for permission, right? For example I’d love to get the GWI logo up there but I didn’t ask for nor get any permission yet internally within the company.

terezka · 2021-02-16T11:43:52.113Z

Oh yeah, of course Do you mind asking GWI? I’ll reach out to some others, too. If there are any other representatives in the thread, please let me know if you’d like the logo up!

(Edit: Feel free to send the logo + quote to tereza@elm-lang.org - thank you!)

luke · 2021-02-16T17:52:02.551Z

@terezka StructionSite wants to put up a logo!

StructionSite

StructionSite - Intelligent Project Tracking | Site Documentation |...

StructionSite provides a smarter, easier way to document and track the progress of your jobsites. Designed for the field, capture your project in context quickly.