I just found another thread here about another proposal for an Elm-like language that shares many of the ideas I have about eliminating Garbage Collection (GC) by using smart reference counting with elided counts and mutation in place when the compiler can determine that the old value is never referenced again, as well as re-using memory allocations for similar conditions in order to save the high cost of memory allocations/deallocations: post here by @Bram; I’m just not as sure about the proposals for “guaranteed memory safe functions”.
Evan even chipped in with a post that offered suggestions to look into using the techniques that the Koka language uses as in the Perceus memory management model and re-using allocations, both of which are as used by the Roc language, and which have become commonly known as optimization techniques to avoid the use of GC with some or similar techniques used in some language implementations such as the imperative language Nim and another imperative language called Lobster. Some of these languages documentation make reference to the Perceus research and to “mod cons” optimizations which have been proven to work.
Although I like the research possibilities of investigating “memory safe functions” as referenced in the thread linked above, I don’t see including this feature in a ElmPlus language as it would break the Elm syntax in ways that would make such a language not backward compatible with Elm; going by history, the development of new languages with their own syntax takes something about ten years before being commonly accepted languages if successful: Nim is now pushing twenty years worth of development, Odin and Zig have something like ten years of development, and even Rust (probably the most popular of “new” languages) has been publicized for about six years - Elm has taken about twelve years to get to where it is although the past five years since version 0.19.1 have been mostly stagnant…
I seems to me that the Roc language is perhaps the most popular of the new functional languages that aims to be able to offer something like the features as I propose for ElmPlus, but my opinion is that it is going to take at least another five years before it is ready for production code to the point where current Elm users might consider switching to it and then they are going to have to switch everything including IDE tooling (thanks for mentioning that, @uweg) and re-writing all of their source code. It seems to me that there is nothing all that bad about the existing Elm source code syntax that makes it worth diverging from in the interests of back-compatibility…
I want to avoid a development project that takes more than a few years to being able to be used in production and generating enough interest so that someone else can take over the management of contributions and maintenance as I may not be able to support it for all that much longer than that - definitely not as long as twenty years as has been the development of Nim by Andreas Rumpf!