[erlang-questions] Erlang 21, Stability and the murder of an innocent Statemachine

[Loïc Hoguin]

What's the issue exactly? Is there plans to remove gen_fsm already, or 
is it just about its deprecation?

On 05/04/2018 12:18 PM, Heinz N. Gies wrote:
> Since this might get long I want to start with an anecdote.
> 
> 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).
> 
> 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.
> 
> 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).
> 
> This stability has always be a core value of the Erlang eco system to 
> me, and an important one.
> 
> 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.
> 
> Now lets talk about senseless murder of gen_fsm.
> 
> 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!
> 
> The *next* one. I see forward using it *for the next one*, 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> - 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.
> - 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.
> 
> Heinz - member of team gen_fsm ��
> 
> 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.
> 
> 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 
> https://gitlab.com/Project-FiFo/gen_fsm_compat
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 

-- 
Loïc Hoguin
https://ninenines.eu