Thanks for the comment Ashish. I did watch that video. I understand and agree with the vision for Elm -- Evan has created a beautiful vision. But how the vision is executed matters. It affects morale (both contributors and users) when "social shortcuts" are used to make the vision happen sooner. Shortcuts like not listening to feedback to the point of suppressing disagreement. Or insisting on idealistic choices for a future vision that don't address the practical reality of today. I don't want to use "native" code, for example, and I have used it as sparingly as possible. But until we get to the future where everything is available within Elm, it is the most practical option for some cases.
The post is not really about the specific choices, but about the signals that these choices are sending. Previously, I could (and did) just to isolate myself from the issues I mentioned by ceasing to participate in the community. But these last round of choices now affect my team's work. We can overcome these today, but based on the existing pattern, who knows what could be next?
I honestly hope that these issues will be addressed and Elm will come through stronger for it. But my current risk management strategy cannot be to hope.
I understand your dissatisfaction with the communication,I think forum posts lose a lot of intent but I'm not sure of the specifics.
I would also like to inquire if you have tried the port solutions as an alternative or posted about your specific cases where you have determined that native is the best solution to the slack. There's a ton of motivation to not have native modules with regards to the future and current optimization in addition to some other benefits. It is a definite trade off though. If you're looking for a more traditional FFI but less safe solution, I recommend you check out the ReasonML project.
We currently have only one case where native is the most practical way to accomplish what we need. You can read the full discussion of that with Robin here. Other use cases were mentioned in the linked reddit thread, and more could be found in other searches.
Regarding optimization, native modules are still usable by Elm package contributors, and are also subject to optimization. So I doubt optimization is a blocker to using them.
I don't have a problem with removing native access. But the timing was when the API is still known to be missing important cases. And Evan's post about it reads like a punitive decision. Between this and the community issues (which have the same root cause), the risk for us in using Elm has gone up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the comment Ashish. I did watch that video. I understand and agree with the vision for Elm -- Evan has created a beautiful vision. But how the vision is executed matters. It affects morale (both contributors and users) when "social shortcuts" are used to make the vision happen sooner. Shortcuts like not listening to feedback to the point of suppressing disagreement. Or insisting on idealistic choices for a future vision that don't address the practical reality of today. I don't want to use "native" code, for example, and I have used it as sparingly as possible. But until we get to the future where everything is available within Elm, it is the most practical option for some cases.
The post is not really about the specific choices, but about the signals that these choices are sending. Previously, I could (and did) just to isolate myself from the issues I mentioned by ceasing to participate in the community. But these last round of choices now affect my team's work. We can overcome these today, but based on the existing pattern, who knows what could be next?
I honestly hope that these issues will be addressed and Elm will come through stronger for it. But my current risk management strategy cannot be to hope.
I understand your dissatisfaction with the communication,I think forum posts lose a lot of intent but I'm not sure of the specifics.
I would also like to inquire if you have tried the port solutions as an alternative or posted about your specific cases where you have determined that native is the best solution to the slack. There's a ton of motivation to not have native modules with regards to the future and current optimization in addition to some other benefits. It is a definite trade off though. If you're looking for a more traditional FFI but less safe solution, I recommend you check out the ReasonML project.
We currently have only one case where native is the most practical way to accomplish what we need. You can read the full discussion of that with Robin here. Other use cases were mentioned in the linked reddit thread, and more could be found in other searches.
Regarding optimization, native modules are still usable by Elm package contributors, and are also subject to optimization. So I doubt optimization is a blocker to using them.
I don't have a problem with removing native access. But the timing was when the API is still known to be missing important cases. And Evan's post about it reads like a punitive decision. Between this and the community issues (which have the same root cause), the risk for us in using Elm has gone up.