alt Hacker NewsThis really overstates the problem and situation.
Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop.
But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port.
It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened.
It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
Replies
I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it.
And the problem isn't just that sync interop was removed. That would've been fine. It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong.
Breakage is totally fine, I never expected anything different from Elm. But community-killing permanent core feature removal is a bit much, is it not?
I luckily never invested too deeply into the ecosystem so there wasn't a lot dor me to "learn", but it sure ruined any chances of me - and with me I bet a lot of other people - ever looking at an Elm 1.0 or Elm++, and considering the valuable insights gained from TEA that really is a shame.
> It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
This gives flashbacks of the last time I discussed this 7 years ago: Even trying to bring it up would bring denial that it was a problem. It was your fault for using it wrong. If you could demonstrate the cases where it continued to be a problem, it was still your fault for using the project.
Even the pre-1.0 projects I use that have breaking changes will announce a transition period and gradually deprecate APIs over several releases. Community feedback is monitored and the deprecated API may be kept longer than originally planned until suitable alternatives can be produced. Elm wouldn't even consider any of these.
The direction of the argument also changes based on the situation. When Elm was dropping breaking changes in 0.19 the story was that it's a fast changing pre-1.0 project and it was our fault for not expecting breaking changes.
Then they went 7 years without a release and the argument became that Elm was so stable that it was our fault for expecting updates to a mature and stable project.