Your stance to Elm

[ShalokShalom]

According to Elm 0.19 and its general approach of 'either you are for us, or we call you toxic' results in brutal domination and awkward 'community building', so a lot of people are sad with Elm.

What do you mean? How do you see the recent changes from a technical perspective?

Lots of people are quite unhappy with the solution currently and suggest a spin.

[wende]

Hey @ShalokShalom, thanks for reaching out. I already shared some of my stance in this reddit comment, so this would be a TL;DR https://www.reddit.com/r/elixir/comments/a9g0ar/elchemy_gleam_and_static_types/ecu3uob/?context=3

If you want an answer more in the context of Elchemy I'm generally much more in the crowd of people dissatisfied with Elm's developing. Especially that an undisclosed change in 0.19 made elm-github-install a.k.a Elchemy's official package manager obsolete and unusable. That's the main reason why Elchemy never upgraded from 0.18

And I would lie if I said that Elm 0.19 didn't shook this project. You can clearly see that after 0.19 release we generally went into radio-silence mode for at least half a year. We were waiting for some movement in the community. Whether It'd be a backlash, revolution or at least a viable replacement for elm-github-install (There is elm-git-install but it's still quite early in development and even more hacky than elm-github-install was)

But 6 months worth of thinking led me to an interesting conclusion which is quite untested till it happens. I believe we could use Elm 0.19's (and possibly all further versions') hermeticity to our advantage. The hard ban on Native modules ensures that the packages won't use JavaScript and will be purely Elm - which means purely Elchemy for that matter as well.

With that in mind we can use Elm's package whitelist as our blacklist ;) Whatever is allowed to have Native modules won't work in Elchemy.

And here's the plan for the experiment:

1. Remove the last Elm component of Elchemy, which is type inference. Currently developed under https://github.com/elchemy/elm-type-inference started by @joonazan (🙌) and currently developed by @MajronMan to fit Elchemy's needs.
2. Make Elchemy a super-set of Elm. In a similar way Elixir is Erlangs. Everything written in Elm will be compilable by Elchemy (for backend) at all times, but Elchemy will be free to extend the language to its needs (Needles to say having Elm compiler in Elm will be an awesome addition. From elchemy-live being a piece-of-cake to implement, to having a REPL without any use of Haskell runtime)
3. Augment Elchemy with Algebraic Effects (Or any other effect system suitable for Erlang VM environment). Currently I'm developing Elixir compiler extension that adds Algebraic Effects to Elixir to test if it is of practical use to this project
4. Ensure Elchemy's type-inference reliability is up to par with Elm's. And start a slow inevitable migration of tooling. Once Elchemy adds functionality over Elm, we'll be unable to use current editor plugins which is a huge commitment to make even. That's why adding anything on top has to be delayed as far as possible
5. ???
6. Elchemy as a stand-alone, type-safe, first class side-effects, distributed systems focused language for Erlang VM - hopefully 🎉

[wende]

@ShalokShalom since the Gitter appeared to be a flunk and Slack enabled invite link feel free to join out Slack for discussing future of Elchemy https://join.slack.com/t/elchemy-lang/shared_invite/enQtNjE0NDQzNDE4NTM0LWQwMDNiYjBiOTg4YWE4NGE0MjQ2ZDkzZThiMGRkYjIyZjExMTA4MjQyMTc3ZTYzMDUyOGE3ZjVkNmI1YWMzYTQ

[ShalokShalom]

So here is my purposal:

Based on 0.18, release a LTS version, which ensure for the people that they can build up on it.

Succeed then with your super set idea, that is great.

Forgive my noobish standpoint: Why do you like to develop an own type inference?

[realvictorprm]

@ShalokShalom Of course it depends on the overall requirements but in general writing a type inference isn't that a big deal as long as the language isn't mixed paradigma like e.g. F#.

[ShalokShalom]

Then I am wondering why the people say that type inference in Elm isnt as good as in Haskell or F#

[realvictorprm]

That's a very generic statement. I've already used Elm in production and cant complain about the type inference compared to F#