<div dir="ltr"><div><div>Hi,<br><br></div>I agree with Heinz. The deprecation of gen_fsm forced me to stuck on OTP 19 and I dont see any reasonable path to upgrade.<br></div><div>There are a lot of dependencies using gen_fsm and I don't see, how one can make code be compatible between releases not providing gen_statem and deprecating gen_fsm.<br></div><div>With simple functions a macro approach is good enough, although it does not work with the gen_fsm.<br><br></div><div>The deprecation of the erlang:get_stacktrace() feels similarly.<br></div><div><br></div>Karolis<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 4, 2018 at 1:18 PM, Heinz N. Gies <span dir="ltr"><<a href="mailto:heinz@licenser.net" target="_blank">heinz@licenser.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Since this might get long I want to start with an anecdote.<div><br></div><div>When talking to people about Erlang and why it is great one of the things I mention is stability. I’m not talking about systems not crashing but rather about the fact that change are slow, gentle and breaking changes are rare or nearly unheard off. The example I use is a non trivial toy program I wrote back in 2012 and that it took me a whole of 20 minutes to get code form 2012 working 4 and a half years later  (most of the time spent on updating dependencies).</div><div><br></div><div>Having used other languages and the constant catch up game with changes I always found that impressive  and it gives me a warm and fuzzy feeling inside that the code I finish will be finished and don’t require a endless cat and mouse with the language.</div><div><br></div><div>Even changes that happen like random vs rand are well based with reason - security and performance in that case, and the changes are minor enough that for the most case changing a single function call here and there is enough to even keep complex programs as long as they’re not (ab)using internal knowledge of the implementation (I’m looking at you riak_core).</div><div><br></div><div>This stability has always be a core value of the Erlang eco system to me, and an important one.</div><div><br></div><div>While I have the feeling the frequency of deprivations and breaking cross version compatibility has increased over the last releases for most of them I can, as said before, see the reason and the tradeoff made.</div><div><br></div><div>Now lets talk about senseless murder of gen_fsm.</div><div><br></div><div>I understand that gen_statem is nicer, and more user friendly, and I don’t want to advocate against it at all, it’s great that we have it and I see forward to useing it for the next state machine I have to write!</div><div><br></div><div>The <b>next</b> one. I see forward using it <b>for the next one</b>, not the last 100, or even last 15 not even for the last two. I don’t see forward to being forced to go through all libraries that have perfectly fine working gen_fsm without problems or troubles and have to change them.</div><div><br></div><div>Ripping out a widely used and not broken behaviour just because there is a more fancy one goes against everything I value in erlang as an eco system. It forces developers to do the kind of busy work I detest in other platforms.</div><div><br></div><div>Worst of all forcing people to fundamentally re-write perfectly good code means bugs, bugs we wouldn’t have had if we would just have left the code alone. Bugs that are probably non obvious as differences are subtile. And in the end for absolutely no benefit.</div><div><br></div><div>Now it’s just a rant without a proposal. And I detest whining without constructive criticism as much as I detest platforms forcing changes that are not required. So here is what I’d like to suggest:</div><div><br></div><div>- Keep gem_fsm around, it has been a friend to many for a long time and there is a lot of code using it that shouldn’t have to change to use newer erlang versions.</div><div>- Encourage people to use gen_statm for new code, and if it is really that much better then gen_fsm that it’d warrant to rip it out that should happen on it’s own.</div><div><br></div><div>Heinz - member of team gen_fsm 😂</div><div><br></div><div>PS: I’m not just writing this out of no-where I’ve been fighting subtile bugs on gen_fsm -> gem_statem code that was ported by people a lot smarter then me and I see no chance in hell that if they can’t pull that off on simple code I will ever be able to do that on complex code.</div><div><br></div><div>PPS: if the this plea falls on deaf ears (which I really hope it does’t) here is a plan-b for team gen_fsm <a href="https://gitlab.com/Project-FiFo/gen_fsm_compat" target="_blank">https://gitlab.com/<wbr>Project-FiFo/gen_fsm_compat</a></div></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>