But yeah, I get that it's frustrating that a feature you use is removed.
I use this feature in Elm almost not at all, currently. I could easily get by without it. (But I have needed it in F#, so view it as useful and a mistake to remove.) As mentioned in the original post, it's the overall message that we're getting from Elm that has me reeling. Not just this one piece.
People have been suggesting countless of things, type classes, SYTC, HKT, etc etc... those issues get closed with comments such as "use another language then" or "almost nobody uses this".
I am actually suspecting that nobody really knows how to implement these features on a theoretical level and that's why...
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.
I use this feature in Elm almost not at all, currently. I could easily get by without it. (But I have needed it in F#, so view it as useful and a mistake to remove.) As mentioned in the original post, it's the overall message that we're getting from Elm that has me reeling. Not just this one piece.
I wholeheartedly agree with this.
People have been suggesting countless of things, type classes, SYTC, HKT, etc etc... those issues get closed with comments such as "use another language then" or "almost nobody uses this".
I am actually suspecting that nobody really knows how to implement these features on a theoretical level and that's why...
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).