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.
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.
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.
Meet the new boss same as the old boss.
Its a shame really. Elm seemed so promising a few years ago. I still like the ideas behind the project but the history of Elm is not confidence inspiring.
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.
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.
As the sibling commenter says, maybe it’s worth reconsidering the approach somewhat?
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
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.
The kernel code API is quite… unfinished. It isn’t documented, it performs no validation and it crashes the compiler when written incorrectly. It really isn’t ready for general use. It’s also expected to break in the next few releases.
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.
Regardless of the details here: Thank you so much for taking the time to come here and explain your decisions, without getting offended or overly defensive.
Those links you provided seem to have nothing to do with "whitelist of projects allowed to use native code". Can you be more specific about what you're referring to?
The articles linked by each of those posts contain numerous references to "native modules" and "kernel code". In this context, those things mean the ability to call back into JavaScript from Elm. The ability to do this exists in Elm, but it's locked down so you can't use it.
To be fair: you can definitely call JS from Elm/Gren using ports, which exposes the JS world as an async service you can call. This seperation means you lose none of the guarantees of the language, while being able to communicate with the outside world. Kernel code is completely unprotected, and would allow mutations, exceptions and side-effects in "Elm world".
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.
As someone who uses and is generally pleased with Elm (a large part of my product's UI is Elm) I could use more detail on what is different and especially why it is different.
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.
No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t).
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.
I've long moved beyond Elm, but I'd be surprised is anyone really used reactor. It seemed so completely unfit for purpose and was almost immediately useless if your project was more than a single file. elm-live was simply a requirement no matter how much I tried to avoid adding in extra tooling.
> No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t).
Unrelated to Gren, but what happened to Stabel? It seemed like a very cool and interesting project yet when I wanted to read more about it, all the resources were down
Nice to see that people were interested in Stabel :D
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.
For folks who don't care as much about iron-clad protection against mutability and side-effects, but want an elm-ish language that prioritizes functional code, derw is an interesting upcoming alternative.
It also targets good interop with typescript which is a big plus in current state of frontend ecosystem.
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 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).
Fellow light theme user here. Forced terminal colors are the bane of my existence. I would kill for a contrast-aware terminal emulator that forces every character to have a minimum contrast with its background.
You can probably hack suckless' st terminal to do this without too much effort (just checking for \x1b[41m and \x1b[100m and the reverse attribute is probably enough, not many use the 256 colours or true colours to set the background, although you can make it as complex as you want).
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.
iTerm2 on the Mac has this. It's a "minimum contrast" slider from 0 to 100% which does what you'd expect. It's nice that it's adjustable.
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.
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).
No tuples?! What if you want a function to return, say, a number and a string? Are lists heterogeneous? That defeats a lot of the safety a type system can offer.
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?
There's more to the story in that Elm is a stable, high-quality frontend language that works as well as its creator wants it to for now. There are a lot of happy Elm users over on the Elm Slack, and it's being used in production at various companies.
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.
But bugs have to be fixed. You can't claim that popular non-trivial project is alive without constant commits. Even if no new features are added. I can see many issues about compiler crashes, etc. Sounds like not mature project.
That’s fine, but that’s just your opinion. A lot of people use Elm in production and don’t have issues with it. I’m neutral on Elm. I think it’s a cool language but I don’t use it. I’m not convinced that “constant commits” signal the life of a project though.
I saw the Elm on the Backend presentation. Evan would like ELM to be a full stack language. If it will work properly, you will not have to manage the message passing (JSON, XML). Seems like very interesting topic. Evan looked really psyched about.
"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:
> 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.
Actually I think that's a reasonable stance. Not everyone wants to use the newest and greatest JavaScript framework which is will be completely reworked in six months because there's a need for a newer and greatester version. The speed of evolution of JavaScript frameworks is amazing, yet they're all still worse thought out than Elm.
On the other hand, this comment shows the clown car of HN discourse: everything that doesn’t make the trade offs that you want is a literal dumpster fire end of discussion.
Meh, it only happened to fork Elm to bootstrap early development and had no plans to carry on with Elm’s development nor trajectory. People in these comments are already confused.
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.
It usually isn't the best way to introduce it, but if you value clear communication it makes sense to say that it is a fork of Elm if someone wonders whether or not it is one. Otherwise you're venturing into territory where the meaning of words is arbitrary and only your favorite words to describe something are valid.
That would be throwing out the meaning of the word "fork" similarly but in a different way to denying how Gren started as a fork and thus is still one (though it's not the best way to quickly introduce Gren to its intended audience as a whole). There aren't simple algorithms to determine these things. It's the sort of job an LLM would be good for.
A fork where you diverge from the original is still a fork.
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.
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 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.
Yes, Microsoft have made lots of updates but your 16 bit DOS game will still run. (Elm cannot run old Elm programs but to be fair Elm is on a prerelease alpha < 1.0 version)
I don't know of this is meant to be sarcasm or earnest. In either case, it's wrong. Modern Windows will not run 16-bit DOS applications. But they did run (in various levels of compatibility) until 32-bit Windows was fully sunset (Feb 2020, Win10).
Yeah sad. I appreciate the philosophy with slow careful releases and I also believe that people should be allowed to make unorthodox design choices in order to stay focused (or at least I’m not sure qualified to critique their choices). But, it seems like there’s a culture of taboo/fear/fanboyism which is clearly not healthy.
I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning.
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.
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.
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.
> While the language doesn’t get frequent updates (and that’s a good thing!)
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.
> 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.
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.
I think some negative fanboyism is because Elm promises a lot, and also delivers a lot of promises but there are some choices that sort of rub against our intuitions about software. Principle of least surprise.
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.
It's totally fine to run the project (or don't run) as the owner see fits and use it however one wants.
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.
Do people pretend that? Or is it just an HN circlejerk that reports it be so?
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.
People absolutely pretend that! This whole subthread spun of from a discussion of https://iselmdead.info/, which says (emphasis added):
> 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.
This is what I don't like about it. Other then that Even is running things differently and maybe it's not for you, but some people really like it and maybe some more will.
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.
Elm has a total toxic waste dump of a community, despite being IMO a pretty good language, so I'm leery of these offshoots and forks (there are a few others as well) especially because it seems like they're created by members of Elm's core team which is the epicenter of why the community is like it is.
