The implementation for these things are known, there's just no pressing need to introduce them to the compiler. There's also no consensus on what the right implementation would be.
I write Elm full time, and don't miss these things. There have been times where it would be nice to implement comparable for one of my types, but I'm not convinced that type classes is the right approach for ad-hoc polymorphism in Elm.
I think it's telling that less than 5 years later than this comment was made Elm has stagnated almost completely and is experiencing an almost constant exodus of users not just because of the language evolution being inflexible and impractical, but because of the "party line" behavior that can be observed in these comments.
Perhaps, but the author of that comment also started a project called Gren which tries to address many issues with Elm which indeed seems to have stopped evolving. Although some of the design decisions seem to double down on controversial decisions in Elm (e.g. locking down the "kernel" code, banning custom operators etc).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The implementation for these things are known, there's just no pressing need to introduce them to the compiler. There's also no consensus on what the right implementation would be.
I write Elm full time, and don't miss these things. There have been times where it would be nice to implement
comparablefor one of my types, but I'm not convinced that type classes is the right approach for ad-hoc polymorphism in Elm.I think it's telling that less than 5 years later than this comment was made Elm has stagnated almost completely and is experiencing an almost constant exodus of users not just because of the language evolution being inflexible and impractical, but because of the "party line" behavior that can be observed in these comments.
Perhaps, but the author of that comment also started a project called Gren which tries to address many issues with Elm which indeed seems to have stopped evolving. Although some of the design decisions seem to double down on controversial decisions in Elm (e.g. locking down the "kernel" code, banning custom operators etc).