State of Elm 2016 Result

The reason it is in Elixir Chat is because in the section of:

Which one of the following languages would you choose to power your backend?

Elixir is highest! ^.^


The image seems to be broken in your post? Hotlinking to it is not allowed.

EDIT: You fixed it, yay!

Damn I want to believe this is great news for Elixir but there’s way too much selection bias in this survey. An Elm survey asking about the backend you’re going to get mostly Elixir since it seems to be the most popular pairing for Elm.

Anyway, bias or not, I think any realm or domain that holds Elixir in high regard is good news :smiley:

1 Like

Always makes me laugh that the people who go on about how types, no side effects, and strong static checking are great to have end up using a dynamic, side effect-allowing language for the backend (the part that actually handles all their data).

Nope I did not touch it. ^.^

Is very true, there is a lot of bias there (I’ve pointed many in their mailing list to Elixir/Phoenix personally).

Heh, well I at least have my reasons, the OTP and BEAM. :wink:

True, but this came out recently:

I’ve been keeping a close eye on mlfe for almost a year now, however they’ve made a few questionable design decisions in my opinion. The biggest of which is their choice to type the mailbox of a pid, which may initially make sense so you only send it messages it understands, but what it understands can change with every function call (just calling a function that does a GenServer call changes it, even ignoring potentially calling out to an unknown modules function that may have its own receive loop). In my opinion they should have PID’s be an opaque type, and from receive you should be able to pass in matching structures and/or get a blackbox back out (a generic ‘Erlang type’ or something) of which you could match out the useful information that you’d want. I spoke of how that should be done elsewhere (bucklescript thread?) and how I’d do it. Recently they’ve been tossing around the idea to remove the actor/pid/receive stuff entirely from mlfe due to the impossible problem they left themselves in, and just use erlang binding code to do that stuff (just calling in to mlfe immutable functions).

Really, the same effort could have been put forth toward an OCaml ppx anyway, even less work, have the full OCaml power in erlang then. ^.^