compiler

Haha we may have worked together. Equatable has been a theoretically huge, actually OK hole in my opinion because it _can_ lead to runtime crashes but never has in any code I've written (\_ -> () == \_ -> () is a runtime crash). So I'm glad to see something more robust than "just don't do that." And "hashable" as the real thing you need to implement Set/Dict is a good idea imo. I'm sympathetic to keeping "comparable" closed and even smaller than it is for the reasons in this discussion [0]. In my perfect world, String would not be comparable as-is because string comparison should be locale dependent. Right now string comparison just ends up using JS's < operator which compares as a list of code units. So I'd like to be able to have a Set of Strings or a Dict with String keys without having the footgun of being able to think that I've alph

> It appears the last commits on GitHub are from mid 2024 That's not what I see. The last commits for elm/compiler were minor fixes in 2023. Last substantial changes were in 2021. See https://github.com/elm/compiler/commits/master/ The last commits for elm/core were in the first months of 2021. See https://github.com/elm/core/commits/master/ > It appears the main developer is working on a new thing? One of the problems is that the developer said several times, even in a recent interview, that he was still working on elm, with a focus on the long term. He gave a few vague hints about his private roadmap. After 4 years without any real public activity, I find it hard to believe there's some private activity.

mentioned in this thread: C * Lua https://www.lua.org/source/ * Redis https://github.com/redis/redis (mentioned twice) * Ruby https://github.com/ruby/ruby * SQLite https://sqlite.org/src/dir?ci=trunk C++ * Botan https://github.com/randombit/botan * ClickHouse https://github.com/ClickHouse/ClickHouse Go * Go's standard library https://cs.opensource.google/go/go * HashiCorp repos, particular those by Mitchell https://github.com/hashicorp F# * jet.com repos https://github.com/jet?language=f%23 Haskell * Elm compiler https://github.com/elm/compiler Lisp * CL-PPCRE https://github.com/edicl/cl-ppcre/ * Mezzano USB driver https://github.com/froggey/Mezzano/blob/master/drivers/usb/m... PHP * Carbon https://github.com/briannesbitt/Carbon * Laravel https://github.com/laravel/laravel Python * pytudes (notebooks) https://github.com/norvig/pytudes R *

> 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

You'll see people arguing that it's not, but I'll let you be the judge. https://elm-lang.org/news https://github.com/elm/compiler/pulse/monthly https://github.com/elm/core/pulse/monthly https://github.com/elm/compiler/commits/master https://github.com/elm/core/commits/master

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...

Quintessential experience of talking to Elm core team: https://github.com/elm/compiler/issues/1773#issuecomment-418... What's funny, rtfeldman uses case expression with numbers in his (in OP's blogpost) praised library elm-hex, so it's not the problem of numbers vs variants. Only negative numbers are the problem.

The core team refuses to fix straightforward bugs: https://github.com/elm/compiler/issues/1773

> It is clear that Elm is understaffed, to say the least. The core team treat bug reports as insults: https://github.com/elm/compiler/issues/1773

It's not rock-solid nor complete. The authors refused to fix a parser error related to negative literals: https://github.com/elm/compiler/issues/1773

Looking at the number of opened bugs and lack of releases, I wouldn't call it rock solid. https://github.com/elm/compiler/issues

Evan will be giving a talk about "Elm on the Backend" later this month. [1] https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend The video will not be published online. > NOTE: My goal is to get some early feedback from the in-person audience, so the video will be held back for now. I am not announcing a release, and the roadmap and this status update are still the primary documents for long-time Elm users to set expectations about this work. [2] https://github.com/elm/compiler/blob/master/roadmap.md [3] https://discourse.elm-lang.org/t/status-update-3-nov-2021/78... EDIT: In the second link, Evan says the following: > As I allude to in the roadmap 410, nearly ten years of working in constant interaction with “silicon valley mindset” had taken a toll on me in many ways. Within the dominant value system, there are specific rewards