4 ms·

Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.

by Igelau 5y ago

adregan 5y ago
I agree. Assuming this article is about the author’s experiences in early 2019, Elm has only had one release since then. They wouldn’t have missed out on much at all by shipping with a forked compiler but would have gained a lot of time to migrate. The fork wouldn’t necessarily need to be public either.
sam0x17 5y ago
Yeah I was literally expecting the next paragraph to be "and that's how elixir was born!"
PragmaticPulp 5y ago
> Really I think the mistake there was not forking Elm. Forking a framework and trying to maintain a new, separate open source project is a huge burden. There is no way that would have fixed their problems of being behind schedule, but it definitely would have permanently worsened their maintenance overhead. They needed to scrap the alternate language/framework plans and return to something safe and proven as soon as it became obvious that they were too far off track. Continuing to double down on commitments to unpopular frameworks (or worse, creating your own niche fork to maintain) would only worsen the problem.
dimator 5y ago
Rather than forking elm, there's purescript, which is unlike elm in all the restrictive ways. It seems to have regular releases and plenty of packages as well. https://www.purescript.org/ https://www.purescript.org/ https://pursuit.purescript.org/ https://pursuit.purescript.org/
- yawaramin 5y ago
  Or port over to bucklescript-tea (a port of the Elm architecture to the OCaml-to-JS compiler BuckleScript) using the Philip2 migration tool, which was announced almost a year before OP was published: https://medium.com/darklang/philip2-an-elm-to-reasonml-compiler-a210aaa6cd04 https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...

Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.

by Igelau 5y ago

Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.

adregan 5y ago

I agree. Assuming this article is about the author’s experiences in early 2019, Elm has only had one release since then. They wouldn’t have missed out on much at all by shipping with a forked compiler but would have gained a lot of time to migrate. The fork wouldn’t necessarily need to be public either.

sam0x17 5y ago

Yeah I was literally expecting the next paragraph to be "and that's how elixir was born!"

PragmaticPulp 5y ago

> Really I think the mistake there was not forking Elm. Forking a framework and trying to maintain a new, separate open source project is a huge burden. There is no way that would have fixed their problems of being behind schedule, but it definitely would have permanently worsened their maintenance overhead. They needed to scrap the alternate language/framework plans and return to something safe and proven as soon as it became obvious that they were too far off track. Continuing to double down on commitments to unpopular frameworks (or worse, creating your own niche fork to maintain) would only worsen the problem.

dimator 5y ago

Rather than forking elm, there's purescript, which is unlike elm in all the restrictive ways. It seems to have regular releases and plenty of packages as well. https://www.purescript.org/ https://www.purescript.org/ https://pursuit.purescript.org/ https://pursuit.purescript.org/

yawaramin 5y ago
Or port over to bucklescript-tea (a port of the Elm architecture to the OCaml-to-JS compiler BuckleScript) using the Philip2 migration tool, which was announced almost a year before OP was published: https://medium.com/darklang/philip2-an-elm-to-reasonml-compiler-a210aaa6cd04 https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...