Attracting Newcomers : Elm Update Frequency Concerns

Isn’t this thread just more boilerplate on a subject that’s been discussed over and over?

How would simply updating the version number make the language more interesting?

I love Elm because of it’s stability and because Evan will only update the language and compiler when there is a bloody good reason to do so - not for the simple fact of “attracting new customers”… Period. End of. Goodnight.

If people interested in other languages don’t appreciate the stability of Elm, and prefer to use other languages that have constant version number updates, then let them use them and don’t try and make Elm fit their view of the world just to attract them.

Evan has his own approach, it’s been well documented over recent years. Love it or hate it, it is what it is.

Personally , I agree with him, if someone doesn’t, then you’re free to fork the compiler and go your own way. :man_shrugging:

9 Likes

Yes. What will another round achieve? Nothing.

I have read all of your comments. You cannot deny that in every language or any process in this world, it must evolve over time. All technologies in this world should at least have a goal to achieve in the future or milestones that people expect.

Let’s say I have not used Elm, and when I check the last update of Elm, it is 3-4 years ago. What should I think? Is it a very stable language?

It seems that you don’t want to attract new commers nor to grow the community. I’m not even talking about only the Elm language. I’m talking about the discussion that we are having now in this Discouse Board. Is this the characteristic of the the Elm community too?

It seems that not only does Elm language not want to attract newcomers, but the Elm board also doesn’t welcome newcomers either

1 Like

I laid out a way to attract new people, did you miss it? It’s just a few comments above Attracting Newcomers : Elm Update Frequency Concerns - #19 by wolfadex.

1 Like

Probably not, just me poking some fun at it!

It basically comes down to people wanting someone else to do something, that they do not want to do. If you want something done, do it yourself, but I also can tell you, it will be a huge amount of work. Which is probably why no-one ever does it, except of course Gren, Lamdera, Roc. But for whatever reasons, those do not feed back into Elm.

So, if you want Elm to evolve, ideally in a backwards compatible and open source way - get cracking! I would do it, but I just don’t have time right now. I’m 47, full-time employed, wife and 2 kids and 3 mortgages. Most of my self directed time with code right now, is used on learning AI things. But some of you younger people are full of energy and have more free time and younger sharper minds.

Either do it on your own, or do it as a group. But be independant (fork) so that you are no longer blocked on Elm.

That is the only path I see to real progress, because the fundamental issue here is (It basically comes down to people wanting someone else to do something, that they do not want to do. If you want something done, do it yourself, but I also can tell you, it will be a huge amount of work…

Thats an infinte loop there BTW.

2 Likes

My view on this is, that working alone is probably quicker than working as a group, because forming a group that works well together and achieves a lot with aligned goals would probably be difficult. But working alone is only going to go so far, in particular it does nothing to address the bus factor issue, not to mention the bottle-neck issue.

I created elm-janitor, starting out as a solo endeavour, but also right from the start tried to follow best practice of working in the open. Posting about what I was doing, seeking advice from others on how to do things I didn’t know how to do (how to review/test/merge GitHub PRs with git), documenting my working process, and also creating a channel where people can participate in a group effort to evaluate the patches. The predictable thing has happened though, and that is that people now see me as “the janitor”. My intention was really to create a framework that allows all of us to be “the janitors”. I should also mention Marc Walter, who wrote the apply-patches script for it, because without any prompting and completely by his own initiative he did precisely that.

elm-janitor is limited in the scope of what it is trying to achieve. It aims to be forward and fully backward compatible with Elm. It also has a major piece missing from it currently, which is the ability to publish kernel packages and have the compiler pick them up - this can be done actually, but it involves setting up MITM proxy to trick the compiler into using an alternative package site; that requires messing with the certificate authorities whitelist in a way that would be unnaceptable to commercial users building their CI systems - you might do it on your own work computer just to try it out.

By forward compatible, I mean forward compatible to a reasonable interpretation of intention. By that I mean that if you write Elm code and use elm-janitor, since you will get bug fixes that cause different runtime behaviour to the official Elm packages, you will not have perfect forward compatability. But we tried to fix the bugs in line with our best interpretation of what the correct behaviour should be - so that is what I mean by forward compatible to intention.

For me, backwards compatible evolution of Elm is essential. I think it is likely also to be quite essential to most of the people that are making big contributions around Elm packages and tooling. Simply put, we have made a significant investment of time into Elm, and would not want to lose that. Not without some easy way of upgrading anyway. Backwards compatability is the reason that I have not explored Roc or Gren, despite them being worthy and interesting projects.

Also note that backwards compatible can mean adding new kernel APIs and functions, so long as they leave the existing ones alone… :slight_smile:

But for now, I have declared that the roadmap for elm-janitor is to not do that. The reasons for that are:

  • I think it should come after all the existing PRs have been reviewed (pretty much there at the current time).
  • I think it should come after a period of reviewing and creating PRs for existing issues that do not already have fixes.
  • It is a little more controversial, because forward compatability is now being discarded - there would now exist a one way valve through which people could move off of Elm and not come back.
  • There is no package system yet to make this work available.
  • and It is probably the correct time to declare a fork when this does happen.

But if you are serious about evolving Elm, and accept that the only way to do it is to avoid being blocked on Elm, and that the only proper way to do it that carries the existing community along for the ride is backwards compatability and creating a structure that allows the community to participate - I think it is likely that you will come to the same conclusions as I have.

What I have tried to do is map out how I think those conclusions could be turned into a roadmap for continued evolution of Elm that best meets the needs of its current users, and would open up growth and progress that would likely attract many new users.

My personal motivation is that if we can get there, Elm will become more viable for commercial adoption - so time invested towards these goals now, will pay me back in life later by making more enjoyable and profitable work available to me.

As I say, I am not actively working on elm-janitor right now, because I am not the janitor. I would be very happy to set up and support people if they do want to take it further. I also anticipate that there will be some future time, when I am between contracts and sitting on a small (but rapidly diminishing) pile of money, that I am able to pick it and run with it again.

5 Likes

@theparitt, curious about true motivation.

On the surface, this question is about mythical newcomers and “other people.”

From experience, I know when someone talks about “other people,” it is a code phrase for deeper personal concerns.

Can we talk frankly about those deeper concerns?

Is it the fear that publicly aligning oneself with Elm in the current social/work environment will lead to negative comments that will reflect negatively on the employment/reputation? Did it already happen, and now the lack of arguments to defend that position is causing anxiety?

Or was it a decision to use Elm for a bet-the-business product and the unexpected struggle to find new employees already experienced with the tech?

Something else?

Here’s a thought experiment:

Let’s imagine there are constant 19 newcomers/month to this community of practice. As they join, each and every one expresses deep appreciation for the boringness of the unchanging version number and the productivity that comes with it: “So tired of updates that constantly break my stuff. All I want is to learn once and be productive for next 15 years. For so long I felt alone and lost floating in the blinding Sea of Shiny New Things. Elated to have found this Eataly of Programming! Vive le boring!” :expressionless:

Let’s use retro-computing as a proxy for our belief that there are enough people that appreciate the Eternal Boringness of The Great Unchanged that would pay attention to Elm: The 8-bit Guy has ~1.43M subscribers; Devine Lu Linvega’s talks get seen thousands of times. 19/mo should be ok, no?

Would the personal concerns behind the original post still exist in our imagined universe?

4 Likes

Well, thats funny. Today I was in a bookstore, and I picked up a book titled “Natural Language Processing with Python”. I flicked through and by the end of the book it was onto the subject of context free grammars and writing parsers. I was like, what? where’s all the AI stuff, transformers, LLMs etc? Then I turned to the inside cover to check the publication date, 2009. A historical relic.

Technology is a fast changing game, and you keep up or stagnate quickly. Now Elm has done a very impressive job of putting a stake in the ground, and it is actually mightily impressive that a 5 year old build still has relevance in todays fast changing world. It shows to me at least, that there were some great design decisions that went into it. Also that those design decisions intersected well with other parts of the system, so that the core parts could stay out of the way of change and development. I am surprised how well that worked out even.

Vive le boring! Yes. But lets not be so complacent as to not be building the next and better boring. We cannot expect that staying still will lead to this language being relevant long term - its the tortoise versus the hare, not the brick versus the hare…

6 Likes

This.

Let’s hope the op goes through the thought experiment and helps us all make a step closer towards understanding newcomer advocacy.

1 Like

Crazy coincidence: just stumbled on this source file from a live production app. This specific block of code (obviously not Elm) processed ~2.3 million messages this week, and >1bln since written.

Not a language, but still… should I be worried?

1 Like

Frequent breaking updates are not fun of course, but not getting little improvements for years is also very discouraging. Optimum is somewhere in the middle, break rarely, but improve every year or so. 62 open issues on github, and many of hundreds closed are quite reasonable.

1 Like

Maybe the answer is to simply present the positive state of Elm as a language, a platform and an ecosystem:

  • the language has reached a significant maturity milestone
  • the platform and framework has reached a significant maturity milestone that continues to improve
  • the ecosystem is where the innovation is occuring, precisely due to the maturity of the language, the platform and the growth and experience of the community.

Elm Pages v3 released this year, as did Elm Land and the fork of Elm CSS that adds CSS Grid and uses Opaque Types, plus more improvement to build tooling and new libraries that extend the platform and ecosystem.

The bones of Elm is strong and now the flesh is growing.

What is missing? A particular core group from the mainstream frontend world — graphic designers, UX and UI designers. The people that specialise at visual design.

Elm still doesn’t have a portfolio in the visual arts. Elm is like the coolest backend tech on the frontend — invisible (literally).

7 Likes

What is missing? A particular core group from the mainstream frontend world — graphic designers, UX and UI designers. The people that specialise at visual design.

Brilliant.org is pretty nice, but I agree needs more of these domain experts rather than tech focused.

What will happen to the ecosystem when the next release will be out? Nobody except Evan is able to predict what will not work anymore.

I’m not sure this is a sign of maturity of the language.

0.19 was announced as the last release that will break the language and require a refresh of the package server. I don’t know if that is still an intention or not.

Personally I’m of the contrarian opinion, that a ~ decadely refresh of the package site is pretty great actually. It prunes out a lot of packages that no longer serve much purpose - all the abandoned forks, the various proofs of concepts that never went anywhere, the 12th UI/CSS package that nobody uses and so on. It also sort of forces people to figure out maintenance/continuity plans for projects, which is also imho beneficial.

5 Likes

I remember when 0.19 came out there was information about the upcoming changes (no kernel code, no user operators, toInt, color removal ++) about 5-6 months before release. and alpha/beta versions to test the months before the public release, so most used packages was already updated and ready together with the release. My experience going from 0.18 to 0.19 was really smooth with little surprises other than much better performance/compile times. No urgent need for a new version now, but if there was one coming out I would expect something similar, a lot bigger ecosystem now, but elm packages is a dream to refactor, maybe even automatically with all the new tools we got.
Not worried.

9 Likes