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.
