Will Elm Release Time Getting Longer for Every Release?

[eeue56]

I don’t want to comment on Evan’s behalf, but:

• A lot of the work for 0.19 involved re-writing large parts of the underyling system, which made bugfix releases require “all” the changes to be published, not just parts
• I’ve discussed this with him previously, and from what I recall, bugfix releases is something that will happen more frequently going forward. I might be recalling incorrectly, however.
• Some of the investigative work that you may follow on Github has been to split things up in a way that makes bugfix releases easier to release

[John_Orford]

maybe a stable-release-maintainer is what’s called for…

[opvasger]

Given 0.19 and not 1.19, I wouldn’t count on it.

[simonh1000]

I can readily see how this might apply to some of the compiler issues with recursive types, but what about the thing new Elm developers raise with me: the inability to read messages in full in the debugger. That’s not much more than CSS i think?

[luke]

That’s not much more than CSS i think?

The specific work to make those messages visible is a straightforward visual change, yes. But the links that Noah shared explain that releases are done in batches in order to create cohesive changes that can be communicated well. So in addition to the visual update, the debugger needs to be moved to a new package to account for how program startup will work in 0.19. Then its native code needs to be updated to the 0.19 format. Then optimizations that 0.19 enables need to be introduced into the debugger code. And we have to make sure all of that is done in a way that doesn’t make long-term plans more difficult to achieve. There’s more to delivering open source software at this scale than ticking off github issues, and thinking about it that way results in disproportionate and distracting pressure from the community on developers to Just Fix The Bugs And Release, How Hard Can It Be?

[xtian]

Certainly introducing features as part of cohesive releases is valuable, but I think it’s worth asking whether coupling fixes for outstanding issues to those releases (especially when the fixes could be self-contained) helps or hinders the community and ecosystem.

The current organizational structure of the Elm project makes these sort of bugfix releases expensive, but I have participated in other open source communities where the (often thankless) work of triaging issues and wrangling fixes was delegated to community members who had the time and will to contribute. The Ember project comes to mind specifically. I’m sure some people from that project would be willing to discuss their approach and its relative advantages/disadvantages.

IMO it ultimately comes down to sharing the burden of maintenance so that we can all reap the benefits of a more solid foundation. I think this is possible to do without compromising on a coherent vision.

[MarkHamburg]

Even without shared maintenance, some of the most successful open source projects — e.g., SQLite which for a long time was essentially just the work of Richard Hipp — have managed to maintain a practice of rapidly releasing bug fixes for the existing official release while still developing the next release. I’m sure some times this requires making the fix twice but it also means that the community to whom the software is being released isn’t stuck trying to figure out how to work around a buggy release.

Elm’s version history also potentially exacerbates the problems associated with tying bug fixes to feature releases in that some times those releases cause enough disruption that they are difficult to adopt. 0.17 to 0.18 was pretty simple but there is at least one project that noisily abandoned Elm because of the elimination of FRP in 0.17. Dropping FRP may have been the right choice for Elm as a language but the precedent that has been established is that one needs to not expect interim bug fixes to Elm AND when bug fixes do arrive they may arrive in a form that is difficult to adopt.

My general point is that, as a developer, I’m sympathetic to it being difficult to deliver bug fixes while independently delivering features. It would be nice to know that there was sympathy for the difficulties that the choice not to do so causes.

Mark

[pdamoc]

So in addition to the visual update, the debugger needs to be moved to a new package to account for how program startup will work in 0.19.

No, it does not need to be moved to a new package. Some bugfixes can be easily retrofitted to previous releases. I think the CSS changes for the debugger fit easily into this category.

releases are done in batches in order to create cohesive changes that can be communicated well.

The changes can be communicated well with major and minor releases. With a minor release it can be just a change log of bug fixes. With a major release it can be something more complex, maybe an extensive blog post some marketing efforts, posting stuff on various news outlets, etc.

There’s more to delivering open source software at this scale than ticking off github issues, and thinking about it that way results in disproportionate and distracting pressure from the community on developers to Just Fix The Bugs And Release, How Hard Can It Be?

Nobody denies that there is more to delivering OSS than just ticking off github issues but let’s not pretend like there is nothing wrong here. There are no “developers” of Elm. There is only Evan. If there would have been 2, Evan would have been free to develop 0.19 while the second developer could have maintained 0.18. Since there is only one developer, 0.18 remained unmaintained. There were no bugfixes to it. Not even the lowest hanging fruits. With this approach in place, even highly impactful changes like the compilation flags discovered by the people exploring the compilation time issues could not be released for the public. That change does not even require a single line of code to be changed in the compiler and it has cut my compilation time in half in certain painful places.

[simonh1000]

like the compilation flags discovered by the people exploring the compilation time issues

link please …

[rupert]

Since there is only one developer, 0.18 remained unmaintained.

Not disputing anything you said which is all valid, but isn’t that the point of setting the version number to 0.18? I’d consider that version number to be an alpha release, beta as it gets closer to 1.0, and only from 1.0 onward to be a supported and maintained release. Is Elm in fact an alpha that became too successful?

I’d like to know what the plan is to get from 0.19 to 1.0.

[pdamoc]

link please …

I lost the link. It was in #compile-time but it is lost due to message limit. The slackarchive does not have anything archived for that channel past January 15.
This pull request has more information.

[rob]

There was a compile time thread here recently.

Repos with slow compile times wanted for research

I’ve been working on profiling builds and I need some more data points, if you have a public repo that takes a while to build let me know. I’ve been using a version of elm-make compiled with some RTS flags enabled (-A128M -n4m), and it has cut build times in half. I’ve tested with some open source projects and seen similar results. There is little effect on compilation times for smaller, less interlinked files, but for files with a lot of imports it has made a large difference. I will post a…

[pateh]

On mobile now, but you have to recompile elm-make with different flags, I posted some binaries over here https://github.com/hpate-omicron/elm-make/releases for Linux and Mac.

You can run your current build with elm-make +RTS -s -RTS, if a ton of time is spent in the garbage collector then the recompilied binaries will help a lot, the flags that have worked best for me are -A128M -H128M -n8m

[mfeineis]

As for the “Is Elm in fact alpha software?” How could anyone think otherwise, maybe because 80% of the npm ecosystem seems to be 0.x packages, who knows? While I don’t think that the label reflects on the supreme quality of the language, for me it is clearly in public alpha. For one it’s been in pre-release 0.x since 2012 and every version has had breaking changes, sometimes very severe ones. Usually for a beta you consider the API mostly done and wait for clients to find the edge cases that are still lingering. But maybe that’s just me.

I don’t expect 1.0 to be on the horizon yet, Evan explicitly stated that he isn’t in a rush - “Get it right instead of getting it now”. This is the feature set I’m keeping in the back of my head.

My guess - based on the roadmap document - is that with 0.19 new use cases will open up and the community will start to experiment and I expect at least one minor correction/addition release to smooth out the edges of these. Maybe new use-cases will become obvious with that. So this’d be 0.20.

There are also a lot of Web APIs that are currently not directly supported but need to be integrated via ports, which might take another minor release to even out - maybe Elm doesn’t need more support for Web APIs? I personally am fine with the ports solution but I have a feeling that a lot of people might beg to differ. So kind of 0.21 - maybe not.

Rumor has it that the tool integration will be a priority in the future so some kind of language server integration might need another minor release - I’m not familiar enough with the elm-compiler to gauge whether this is necessary or already in place but I wouldn’t be surprised if this warranted a whole bag of workload that has typically been batched. So could be 0.22?

And then there’s also this interface/monad/implicit situation that is bothering people that might get addressed some day, maybe it won’t, so for good measure there’s at least one minor release. So potentially 0.23?

I think the availability of the planned integrated garbage collector for WebAssembly in the near future will attract a lot of attention to all sorts of “compile-to-js” languages, including Elm, of course. From a technical standpoint, if I were to implement the WebAssembly target I’d be darned sure that there will be no more hard breaking changes, so I put my baseline of 1.0 (maybe way) after that GC date availability. Seeing how there isn’t even a draft spec published as of today for that I wouldn’t hold my breath. I could be wrong and the code gen is in such good condition after the big 0.19 that adding WebAssembly before 1.0 might be an option, I don’t know.

[rupert]

Cool, so 1.0 by 2030…

But to be serious. 1.0 does not mean no more breaking changes, you can always break and go to 2.0. I think 1.0 would mean its good enough to be considered ready, and worth putting in the effort to maintain and bug fix the release. You would not go to 1.0 if you are thinking of releasing 2.0 next week, but if it is going to live for a year or more then surely it is worth maintaining it?

[mfeineis]

Off-topic: Not unless you’re called .NET Core 1.0 - well at least 2.0 seems to be production ready…

[MarkHamburg]

The following is not a criticism of Evan’s choices on development path or of other aspects of the Elm community but rather a response to the argument voiced in this thread that the version number says Elm is just alpha so one should temper one’s expectations accordingly.

One might argue that the indicator of alpha v beta v whatever for a technology isn’t the version number but rather the point at which there start being conferences targeted at consumers of the technology rather than developers of the technology. Or at least that reflects how it is being promoted to the world even if the version numbering says that it is being treated differently from a development standpoint. One could infer from the version number choice that Elm is an alpha level, work in progress for which one should not expect bug fixes but if that is the desired inference then it probably needs stronger promotion to counter the image conveyed by other aspects of the Elm “marketing” —e.g., an Elm conference that opens with “Wow! I’m so impressed to see all of these people here for an alpha level technology.”

Mark

[xtian]

One could infer from the version number choice that Elm is an alpha level, work in progress for which one should not expect bug fixes but if that is the desired inference then it probably needs stronger promotion to counter the image conveyed by other aspects of the Elm “marketing” —e.g., an Elm conference that opens with “Wow! I’m so impressed to see all of these people here for an alpha level technology.”

Right. If Elm is considered alpha-level or highly experimental software then that needs to be communicated very clearly in any marketing efforts as well as in the official docs.

There’s no problem with a project remaining in alpha status for an extended period of time, people just need to know about it so they can make informed decisions in their work.

[mattpiz]

Right. If Elm is considered alpha-level or highly experimental software then that needs to be communicated very clearly in any marketing efforts as well as in the official docs.

There’s no problem with a project remaining in alpha status for an extended period of time, people just need to know about it so they can make informed decisions in their work.

There are two sides of this I think. One the one hand, yes Elm is an alpha (0.18) in the sense that retrocompatibility is explicitely not taken into account at each new version. This is probably not explicit enough. But on the other hand, it is a very stable alpha since breaking releases happen roughly every year. Plus recently, transitions have been done semi-automatically with the help of tooling.

In any way I think that a team thinking about adopting a relatively new/small language like Elm should first talk to people already on board, either physically at meetups or with the community online (discourse, slack, reddit). And any elm dev with more than 1 release cycle experience could answer these questions. This with the added benefit of having more specific answers, drawbacks, pitfalls and resources references.

[simonh1000]

the irony of course is that the consensus seems to be that much of this won’t be be necessary with 0.19