Why is Elm getting forked?
I mean the last commit for Elm core was in 2021. Changes require sign off that doesn’t seem likely from who is currently maintaining it. Why not fork it if you are interested in evolving ELM?
[dead]
Gren – an Elm fork
71–80 of 129 posts
Re: Gren – an Elm fork
#72Earlier quoted context omitted.
> people who have decided it’s not for them Rather the opposite, actually. Elm had a lot of promise, and a lot of people really liked what they saw. I consider myself among them: language-wise Elm is pretty much my dream language, and I would love to use it in all my products. But then I tried actually using it, and it turned out one of the core Javascript API wrappers was broken, and rather than accepting one of a d…
Could custom elements help in your case? Many people quit Elm after kernel code was removed, without knowing ports are not the only FFI option.
I wouldn't use Elm anymore even if there were alternatives to kernel code for everything I wanted to do. I don't want anything to do wit a language that imposes pseudo-DRM on me.
Re: Gren – an Elm fork
#73Earlier quoted context omitted.
I don't understand. How does that make it not a fork?
I think maybe the authors are using a strange definition of "fork": if you fork a project and then take it to a different direction, making incompatible changes from upstream then it's somehow not a fork anymore. I'm not too sure though if that's the thinking. (reading from https://gren-lang.org/book/faq.html ) Seems like a fork to me. Or maybe the thinking is that they'll rewrite it from scratch at some point which…
I’m not claiming it is not a fork. It is.
That said, people expect certain things when you market something as a fork, so I’m a little careful in making that the first thing someone hears of the language.
Re: Gren – an Elm fork
#74Lead developer here.
I think it’s a little misleading that the title of this post is «Gren - an Elm fork».
While technically correct, I think there are many who will be dissapointed to find that Gren and Elm are incompatible languages.
In addition to some syntax changes and improvements, Gren adds the support of a NodeJS target. It’s still early, so we don’t support all of the builtin APIs yet, but we’ll slowly get there.
AMA
Re: Gren – an Elm fork
#75Did they get rid of the whitelist of projects allowed to use native code ( https://news.ycombinator.com/item?id=22821447 , https://news.ycombinator.com/item?id=17842400 , https://news.ycombinator.com/item?id=16510267 )?
No. In fact I added some code that still enforces this with the Git-based package manager.
I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls.
However.
The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce those things to the language, and my memory from the pre 0.19 days of Elm tells me that this made for a worse experience overall.
One of the problems with this limitation is the lack of bindings to core web api’s. We’re actively working on adding more APIs here. LocalStorage was contributed by an external contributor. Contributors are also working on a HttpServer and a WebSocket API now.
And that’s another «change» worth noting when comparing with Elm. We have scheduled releases (June and December) and are more open to contributions.
Re: Gren – an Elm fork
#76Earlier quoted context omitted.
There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.
Ah I see. So non-kernel packages do not have access to native modules at all? I believe in Elm native modules were still possible, just not publishing them to the package database. But in this case I guess you wouldn't be able to put a native module in a GitHub repository and then pull this in as a dependency, which is equally rubbish. Edit: EdwardDiego's answer clarified this for me
Elm doesn’t allow kernel code in externel packages. Gren is performing the exact same check, it’s just that Gren uses Git as a package manager and so has to do it in a different way.
Re: Gren – an Elm fork
#77Earlier quoted context omitted.
Even worse, it checks the git history to make sure that... - There are no changes since HEAD - The commit is signed by Robin himself ...and for those interested in the code that does this https://github.com/gren-lang/compiler/blob/main/builder/src/...
that stuff gets run on every compile (transpile?)? yet it seems that any would-be forker could easily remove it? surely this must all be an elaborate gag or something.
Only on the first compile. It doesn’t perform this check when loading a package from the build cache.
Re: Gren – an Elm fork
#78Does it support pattern matching with negative numbers?
Not sure if I got around to fix that bug. If I haven’t, a PR would be welcome :)
Re: Gren – an Elm fork
#79Did they get rid of the whitelist of projects allowed to use native code ( https://news.ycombinator.com/item?id=22821447 , https://news.ycombinator.com/item?id=17842400 , https://news.ycombinator.com/item?id=16510267 )?
No. In fact I added some code that still enforces this with the Git-based package manager. I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls. However. The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce…
Why couldn't you make it just a warning, or even require a command-line flag for it? As it is now, even trying to write and test a PR for any such code requires modifying the compiler.
Re: Gren – an Elm fork
#80Earlier quoted context omitted.
For one, it's been over 2 years without an Elm release. And there are many open bugs untracked in GitHub. https://github.com/elm/compiler/issues Unrelated to your question but for those curious, here's a comparison between Gren and Elm : https://gren-lang.org/book/faq.html#what-are-the-differences...
One boring and banal problem I ran in to was that it will output text in yellow and some other colours which are hard to read on my white terminal background, and this is hard-coded and you can't disable colours (doesn't even disable with isatty). IIRC Evan didn't really want to fix it because "just use a dark background then". This is basically why I never used elm: because the compiler is hard to use as I struggle…
Would you mind creating a github issue for it? I’ll try to get it fixed for the december release (0.3 is releasing next week, which doesn’t leave me with enough time to do it now).