Request: Elm 0.19.2: any update to help adoption to prove that Elm is not dead?

Request Feedback
63

I know that the company I work for would be happy to financially
contribute to efforts to keep Elm alive. We need bugs fixed, core
packages updated with new features/improvements, tooling improved, and
other things like that. I am sure there are several (many?) other
companies who feel the same way.

The fact that Elm the language evolves slowly is far less of an
issue. Even if we don’t agree with all (Elm, the language) decisions,
those are separate discussions.

It is deeply unfortunate that Evan is not really involved anymore. Not
that I don’t understand: the strain and pressure of constant
(negative) feedback (especially, when unfair and/or unfounded) takes
an immense toll. It just proves that we need to get the bus factor up,
though.

Is anyone still in touch with Evan? How can we help to move this along?

64

Evan is doing well. He’s also still working on Elm, just not in the same public way that say Jeroen is working on elm-review.

9 Likes
65

We can only assume along some of the ideas described here: Status Update - 3 Nov 2021

All his GitHub work is against private repos, so we have no visibility: evancz (Evan Czaplicki) · GitHub

Its great, and I really do look forward to Elm 0.20 or whatever it is going to be.

But I also do not expect that any of the kinds of issues we are discussing here will be addressed. I think we ought to accept that they will never be addressed unless a new structure is created that enables (some of) us to do the necessary work to address them.

Whilst speculating on peoples intentions without any real factual insight into them, I may as well throw in that @supermario posted on Slack recently about new things that may be happening with the Lamdera compiler. So that may also be a potential avenue for progress, who knows :man_shrugging:

2 Likes
66

Elm is dead, time to move along.

1 Like
67

@malaire I think this thread is for people who are using Elm and looking to continue use it. While I can understand that you’re frustrated with how Elm is run, stepping into a discussion to say that the very thing being discussed is dead is not helpful.

The irony to me is that supposedly Elm has been “dead” for something like 4+ years now, and yet here we all still are writing and talking about it. Sure it’s not as big/popular as JavaScript, but somehow I still manage to find enough new content to fill Elm Weekly every week.

18 Likes
68

re Elm is dead. In the last two years I’ve had jobs at two companies that I had never heard of for whom their product is either all-Elm or a core and crucial part is all-Elm. A very small sample, of course, but they did not seem worried about the “Elm is dead” issue or by they way the language is run. By “not seem worried” I mean not worried enough to switch to something else and instead continue making large investments of time, talent, and money. As the saying goes “rumors of my death are greatly exaggerated.”

My ongoing side project, scripta.io is Elm + Javascript for Codemirror and KaTeX + Lamdera. It has grown to about 40K (20K for the compiler, 20K for the app). I’m quite happy with the language and see no reason to change since it works quite well for my purposes. The “my purposes” caveat is important: doesn’t mean that it works well for all purposes.

11 Likes
69

The combination of 1) many simple-to-address bugs with open PRs and 2) zero comms or delegation from Evan, is just starting to get funny at this stage.

As a solo founder, I consider Elm a professional advantage over the legions of exasperated React devs, so I’m not even sure I want Elm to become more popular, but I do think the Haskell-esque distaste for adoption is a bit silly.

7 Likes
70

I think you got the “avoid success at all costs” wrong :wink: - it’s “avoid (success at all costs)” and the costs was supposed to be limitation on expressiveness, making things safe, research … - basically exploring the landscape.

I don’t think that this was ever something Elm was aspiring to - in some cases Elm did the opposite (restrict expressiveness in order to make stuff more streamlined for folks new to Elm and FP in general.

disclaimer: I’m basing the rest here on what I was able to read here and sites like Y-combinator, Reddit etc. - I was never in touch with any core dev nor do I know how I could get in touch with one.

To me the main issue seems to be that it’s really hard to earn trust with the Elm core devs and that the core devs don’t really seem to go out of their way to interact with the less-involved community.

I sometimes wonder why they allow PRs in the first place or why the repo is not private (indeed it seems the real deal is private).

I still like Elm (especially to on-board and teach new team members) and we surely will have Elm in production but I’m getting more and more weary about starting new projects in Elm and I’m in the process of evaluation PureScript/TypeScript.
To me PureScript is the alternative and we are slowly moving toward this - of course there the danger is that the community is even smaller but compared to Elm it’s easier to get PRs into libraries and of course it’s a lot easier to do FFI and there are no restrictions on you as a end user - in short: you are seen as an adult (and you can shoot yourself in the foot of course).

3 Likes
71

For your reading pleasure: The hundred-year programing language.

Originally posted by @gampleman in the Elm Slack (#misc)

5 Likes
72

It looks like there are two main groups here, each with different desires:

  • First, there is a group that wants to see bugs fixed, but no changes to the language or core library APIs.
  • Second, there is a group that also wants to see these bugs fixed, but also want new language features.

If you’re in the “bug fix” camp, I think the approach taken by elm-janitor is the way to go;

The idea is not to lead Elm in terms of features and try and set a new
direction for it, but just to patch stuff and make sure all patches are
documented and made available for the upstream project (Elm) to pick up if it
chooses to.

What’s needed is a working fork of the compiler and package site, taking the same approach. Call it the “community” fork, and add an (optional) runtime flag to use an alternative community-powered package site. Move the elm-janitor packages into this community package site.

@lydell and @rupert have both laid out plenty of non-breaking fixes and improvements that could be made here.

It would be easy to come up with a simple versioning system that stays in sync with the main Elm version that it’s based on.
E.g. Community fork based on Elm 0.19.2 with five patches applied could be 19.2.5

When the next version of Elm is released, depending on how large the diff is, it might be a lot of work to get these patches re-applied.
Luckily, this isn’t something that happens too often, so there wouldn’t be too much churn here.

Maybe it’s best for this project to be taken on with a fixed date in mind (multiple years) where if there has been no visible movement from Evan, the community fork will consider breaking changes.

If you’re in the “new features” camp, you could then operate a fork based off of this community fork, allowing you to benefit from those bug fixes while still experimenting with any features you choose.

Honestly though, this “new features” group would probably be best served by putting their energy behind a different project like gren or derw.

1 Like
73

You are right and this would be a good first step (heck if someone could finally provide all the killed part where a “better” version was just beyond the horizon when 0.19 hit … WebSockets :wink: … even better).

The problem I see with this is, that we do hear zero from the core-team(?) here (or did we?) - so someone will take a lot of work and then best case core does not care and the poor team doing the work here will do have to do the same every time we’ll get a new release. Worst case might be that on top of that there could be blame about “splitting the community”.

I’d happily go with this approach (although I’m one of those who indeed wants all the power of the compiler - not necessary new features - without training wheels or repo-lock ins) and yes I could probably get my employer to invest in such a thing … but not without “official” clearance and a clear, communicated and committed way to go forward.

1 Like
74

lydells post on the order in which things should be tackled establishes the right principal for ordering this work - which I call “conservative maintenance”. Maybe a better name for it is finding the path-of-least-disruption.

https://discourse.elm-lang.org/t/request-elm-0-19-2-any-update-to-help-adoption-to-prove-that-elm-is-not-dead/8843/30

Fix the stuff that does not disrupt anyone first.

This is a good idea because its all going to be hard work whichever way it happens. If we can get to the point where we are able to fix a few things, in ways that does not exclude any existing user of Elm from adopting those fixes, we also would have proved that we can do this work together. If we can’t, other approaches are equally pointless.

Supporting that idea, is the reason I started cataloguing PRs and ordered them from least to most disruptive.

Yeah, I thought this would be easy, but I thought about it some more and realized its perhaps not so easy.

You could trick the existing Elm compiler into downloading free/core 1.0.25 and thinking that it is elm/core 1.0.5, but I don’t like that the version is essentially a lie. It would get put in the ELM_HOME/0.19.1/packages/elm-core1.0.1 directory. Potentially someone could end up not knowing what version of what code they are really running in production, and this is never a good idea. Potentially people could get confused and repeatability of builds sacrificed.

Ideally I would like to be able for users to use bug fixed packages in a user friendly way, so without having to pin to a git hash using git sub-modules or something like that. With the same kind of semantic versioning that Elm already has. So I think maybe something like having bug-fixed packages never use the elm/*, always their own namespace free/* (or whatever your gonna call it…). When you use a free/* package that can substitute for an elm/* it needs to be done with semantic versioning, and in such a way that its very clear that the substitution is taking place - the substitute versions get added into elm.json or some enhanced version of it, the build is repeatable, package tools report the actual used versions clearly, etc.

It occurs to me that elm diff already implements semantic comparison of packages, so is available as a tool to construct the mapping between the substitutes and originals.

Looks likely though, that we can just do something with git submodules to get us started, then figure out how to make it nicer at a later time.

4 Likes
75

@rupert

Sounds like you should create a thread with a formal proposal, see how many others would be willing to commit to a legit community fork.

2 Likes
76

I’m in the group that wants the perception of Elm to improve.

So I’m conflicted about a fork. Fixing bug would be great, but I doubt a fork will improve the perception of the language, specially if there is no buy in from the core team. I think a fork to fix bugs would be good only if Evan expresses desire to merge those fixes on the future. Otherwise having a fork that gets ignored could be even worse perception wise.

1 Like
77

I see your point. I think that improving perception outside of Elm might require not so much a fork, but a re-brand. For example, I talked to some Apache people about whether a language project such as Elm would be a suitable candidate for an Apache project. One of them gave me a link to a blog post that was put up when its author was rage quiting Elm at the time 0.19.0 came out. I did write back with some corrections to try and establish a more balanced perspective, but its easy to see how someone not involved at all with Elm can get the wrong impression, because what else do they have to go on apart from what they read on hacker news or various blogs?

To give another example. I did Java for 20+ years, starting with it even before 1.0 came out. In those early days it was slow (up until about version 3 or 4 at least), because the JIT compiler technology wasn’t even invented yet. Lots of C++ programmers came to have a look at Java, realized it was slow, went away and never looked at it again. Even today you still meet people that screw up their face the minute you mention Java - “Isn’t Java like… too slow?”. In some instances Java can be faster than C++, and that has been the case since about 2006.

First impressions last.

3 Likes
78

Ta da!

Similar to my theme on the just previous post. Internet/information overload - we are doomed to repeat ourselves in an endless cycle.

1 Like
79

I’m in both groups:

  1. First focus only on the long list of bugs and other things that need to be fixed. Those are more pressing needs than new language features, and will keep us busy for a longish time.
  2. Figure out a process for deciding on new language features. That’s the hardest part of all.
  3. Eventually we’ll reach a point where new language features can be implemented in a nice, less-is-more way.
4 Likes
80

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.