I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days.
Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."
Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).
I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.
One thing is that it wasn’t communicated that well, but other (and that’s what made me feel really uncomfortable) is that it felt like „This feature is not allowed anymore - except for some dudes, they’re cool enough and can use it” (e.g. native modules, operators). Either keep or drop feature
Kernel code and custom operators are only allowed under elm/ and elm-explorations/, so only 7 core packages can use them. The core developers cannot use those features in projects like everyone else.
And who can contribute to `elm` and `elm-explorations`? The 7 cool dudes.
The Elm contributor circle is a clique that you literally have to be a strong contact with one of the contributors to get into it. It goes against everything open source stands for.
> It goes against everything open source stands for
Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.
The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!
And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.
The problem is there are some reasonable features that cannot be implemented with the current ports system that _should_ fit into the expected design. Specifically, I feel you should be able to replicate the `Http` module using ports or some other available system. However, you cannot properly dispatch a task and then tie together the result with a curried `Msg`, as you might expect or hope [unless you store a complex state object in your model]. These types of issues are the frustrations that, I believe, cause some discontent in the community. I feel more people understand why you should not, per se, make random FFI calls in the middle of pure code (e.g. since it would break dead code elimination and require evaluation order guarantees), but other restrictions seem arbitrary.
The thing I found unsettling wasn’t that something was disabled (fair design decission), but the mindset that considers some features harmful , but is happy enough to use it in its own „special case projects/packages”. It doesn’t really matter for how many packages its available, since it can be changed on a whim. I can only speak for myself, but I found it unfair and patronizing
I don't think that's fair. If elm ever wants to replace js it only needs to rewrite the kernel modules, they govern. Otherwise the whole ecosystem would break in that case and yes, that would be a harmful feature.
I didn’t mean locking features, especially native modules - didn’t write a single one, so personally I won’t miss it. I meant „some repos are more equal then other” mindset. It’s clearer in case of custom operators - they are considered confusing, unless you mean parsing and by parsing you mean elm/json or elm/url, then it’s cool.
By all means, I’m not saying those are crucial features or that they don’t have right to do whatever they want with their language. They can and they do. I just find this kind of atitude and reasoning patronizing.
I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days.
Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."
Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).
I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.