Gren – an Elm fork
gren-lang.org
gren-lang.org
- 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/...
Seems more like a check to make sure the version of the JS is compatible with the version of gren than anything else.
[1] https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
Edit: EdwardDiego's answer clarified this for me
And found a great bug where it broke their own code. [1]
[0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_...
In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.
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.
I will have to revisit kernel code at some point in the future, probably when looking into WASM (which will break all uses of kernel code), but I have other, more important, features to add first.
As in, I do get the reasoning, but there are valid situations where one might need to do this for their own reasons. So maybe there’s some way to make it clear that you shouldn’t be doing this, yet still narrowly allow it. A non-default CLI flag, a scary compilation warning, maybe needs to use some special keyword to use code like that. Like how you need to use ‘unsafe’ in Rust to interact with C code directly.
Otherwise, thank you for working on this! An Elm inspired language that’s open to community development is something the world needed :-D
It will be looked at pre 1.0.
My memory tells me that 0.19 literally killed the language.
The main problem with ports is that (1) it's an async API, which can be awkward for certain operations and (2) you cannot define a package that contains ports.
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
I did find a news post listing some differences, but it didn't really go into "why". A dedicated page outlining the differences / opinions on the changes would help me determine if this is a language I might use.
Having a NodeJS (server) target is definitely interesting.
I also improved pattern matching on records to make them more ergonomic.
No automatic record constructors: same as the above, but in my experience it also confused beginners.
I know of several that actively avoids it in their projects, even enforcing it with a linter rule.
No GLSL: never used it, and don’t know how it works. It also broke when I upgraded the version of the Haskell compiler (Gren’s compiler is written in Haskell). For those reasons, it was removed.
No reactor: never used it
Did you mean better refactoring?
I got a bit too ambitious with the type system, I think. At the very least, I got to a point where I got discouraged because the type system I wanted was difficult to implement, and I started to realize that there were a few problems with the design. At the same time, I was starting to feel that this may not actually be something I'd want to use in production.
On the flip side, I learned a whole lot about web assembly that I hope to put into Gren. I also felt a lot of pain with the lack of FileSystem APIs in Elm (which Stabel was implemented in). In a way, my work on Stabel triggered the work on Gren.
Contributions welcome.
It also targets good interop with typescript which is a big plus in current state of frontend ecosystem.
https://github.com/elm/compiler/pulse/monthly
https://github.com/elm/core/pulse/monthly
There's also [Elm on the Backend](https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend), a recent talk given by the creator of Elm, about his experiments in using Elm as a full-stack language. There are some notes and a few photos, but no video as far as I'm aware.
I'm not involved in the Elm community nor do I write it for a living though, so I'm only kind of aware of what's going on over in the Elm world.
"We are bringing the simplicity and friendliness of Elm to hosting. No configuration. Just press publish."
And from the About Page on elm.studio:
"The ultimate goal is to produce a fun and simple programming language, with the kind support and camaraderie of people who like what we do and how we do it."
Very little information about what is the next step in Elm's life, or even whether they've actually left it... I guess the upcoming talk on StrangeLoop[1] may clear things up... his description on that talk hints at what he's up to:
"He lives in Denmark, working alongside his wife at elm.studio to keep Elm independent and interesting."
Elm may still be alive, just not publically for now.
EDIT: just found this while looking for more information:
:D
[1] https://thestrangeloop.com/2023/the-economics-of-programming...
What an absolute clown car.
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...
What does this mean? I know what GLSL is but I don't understand what Elm or Gren have to do with it.
I imagins this is useful when writing shaders for WebGL apps that are written in Elm. I don't know why Gren removed them, though.
This is basically why I never used elm: because the compiler is hard to use as I struggle reading its output.
(Before anyone comments "why don't you change yellow in your terminal": then this will break applications such as pamix which hard-code to a black background and use yellow text on that, or applications which have a black statusbar or the like with yellow text on it – it's not so easy to choose colours that work in all scenarios and all things considered sticking to the default set is the "least broken" since almost everything has an option to just disable colours).
For 99% of things it's not really an issue so I never bothered: you can either configure the colours or you can just disable them fairly easily.
Windows Terminal has something like this, but finds a way to screw it up. I use Windows Terminal for development over SSH in my current job. It has a checkbox "Automatically adjust lightness of indistinguishable text" (non-adjustable), but it doesn't seem to change the cursor. Whatever colour I set the cursor to, whatever shape, and even with blinking, the cursor is nearly invisible in some of the terminal tools I use, when it is close to the background colour. Even ancient terminal emulators pick a contrasting colour for the cursor. It is an obvious requirement, and Windows Terminal does the opposite, so you can see text but not the cursor.
Maintaining a fork of Elm open to development is a big commitment. But one that will be well received by many.
I look forward to trying it.
Release branch basically means you get fixes. You won't get API changes, or new features. For a lot of people that stability is welcome.
[1] “the largest transport provider in Norway” https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
The FAQ has a similar description, but doesn't make the assertion that it's not a fork, which I disagree with:
> Gren started as a fork of Elm. This is mostly considered to be an implementation detail, a way to speed up initial development.
> It's not a goal of Gren to replace, or stay compatible in any way with, Elm.
https://gren-lang.org/book/faq.html#what-is-the-relationship...
The only interesting thing about Gren on HN is HN’s interest in Elm drama. I bet nobody here even mentions the language specifics but just meta discussion.
I mean Git by design, each commit is like a new .zip file. So "is technically a fork" and "is spiritually a fork" can be very different.
Most long-lived forks that I hear about are things that have developed into their own projects and have no intention of merging back to the original. Contrast with a short-term fork which will only live a few months and then will be hopefully be merged into the original; it will probably be so short-lived that people outside of the project won’t hear about it as a “fork” with its own distinct name.
A “fork” isn’t only making a GitHub fork so that you can make a PR against the original because you found a typo on the readme.
Seems like a fork to me.
Or maybe the thinking is that they'll rewrite it from scratch at some point which would make it not a fork from code perspective.
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.
Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on.
It’s very weird to me as someone who uses Elm daily. We get it. You don’t like it and everyone needs to know it.
That it’s some sort of cult is just HN drama begging fantasy.
But let's not pretend the project is actively maintained and there are no bugs. That's what klabb3 alludes to.
Elm has this "this is fine" phenomenon where people like to pretend its a one-of-a-kind software that has no bugs doesn't even need a patch with bug fixes.
I'm a regular user of the Elm ecosystem, like the Slack/Discord, and everyone talks casually about Elm's bugs. In the #beginner channel it's just "Yeah oops that's def a known issue, but you can work around that with X."
It's just that Elm is still a good tool despite its warts, and its bugs aren't catastrophic. Presumably that's the smoking gun for your "this is fine" phenomenon: that people still use it and dare to even enjoy it despite unfixed bugs.
> Elm’s release cycle is (very) slow on purpose. ...
> While the language doesn’t get frequent updates (and that’s a good thing!), ...
> Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time! It also means the language is very stable, because features are carefully thought out before being implemented.
I have no problem with people enjoying Elm and acknowledging the bugs. I really dislike that this site gets posted every time people point out that there hasn't been an update in four years. A four-year break between updates is not "all part of the plan". It's not a slow release cycle. It's a sign that the creator ran out of steam but didn't want to delegate to a successor.
You seem to be reasonable in your approach to Elm, and that's great. But there absolutely is a contingent that tries to pretend that this four-year hiatus is part of Evan's master plan for Elm and is "a good thing", and it's reasonable for the HN crowd to call that out as problematic.
Take a look at https://elm.studio/about.html, please read comparison there. Elm does not want to be mainstream, people should really understand that.
This is the part that bugs me. It confuses frequent changes with frequent updates.
A language that changes frequently is a PITA to use, and it's good for a language to find a place of stability to where there aren't breaking changes every year. However, if I'm going to use a language in production, I expect it to not go 4 years without a bugfix update. It's not like Elm doesn't have any bugs to fix [0].
I'm a PL hobbyist and don't have any problem with someone having a hobby language that they eventually abandon—I've abandoned plenty myself. I don't even have a problem with someone deciding that they're comfortable with the risk of using someone's abandoned hobby project. It's just weird to see people seriously trying to argue that a 4-year break between releases is totally normal and all according to some master plan.
[0] 290 issues and counting: https://github.com/elm/compiler/issues
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 dozen pull requests to fix it, they just nuked it instead and made it impossible to write the same wrapper yourself.
People keep talking about it not because they dislike it, but because they are grieving what could have been. Those tradeoffs and warnings weren't there when we first fell in love with the language.
Don’t forget those of us who worked at companies that tried adopting Elm and then got burned by it. Some of the changes were show-stoppers if you were actually using it in a way they didn’t like.
I don’t understand this desire to downplay and dismiss the critics as not having valid points. This is a textbook case of an open source project making some weird decisions, then grinding to a halt. It’s so weird to see people rush in to defend everything about it rather than admitting that, yeah, it kind of fizzled out and they didn’t really listen to the community and it came back to bite them.
Example 1: No typeclasses? Fine. But why is there comparable, which quacks like a typeclass and why can only kernel code use it? Practical implication: sorting, which is a bread and butter language/library feature is messy to code and inefficient at runtime.
Example 2: Why isn’t negative number pattern matching just fixed based the principle of least surprise and as a clear bug rather than gaslighting those who found 10 seperate examples of why pattern matching (which is a sugared if/switch) should blow up at compile time with negative numbers.
None of this makes sense. So I think it is good to warn people who are about to invest a lot of time. There will be edges where you wont have fun.
Finally; whether the api gets broken next month or there will be zero releases this decade is not clear. It is not a language where you can reason about it’s future, like maybe you can with JS, Java, Python, C# etc.
Elm is an experimental language. It is also production ready. That intersection is rare and I think that is what causes issues.
Haskell spent a long time as a toy before people made it a production language. And now it is no longer experimental on the whole. No benedict is going to do a 180 on Haskell. You are just gonna get more GHC language extensions for experimenting with ideas. I think this is better/more mature approach.
Stockholm Syndrome at work