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

[Karolis Petrauskas]

Hi,

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.
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.
With simple functions a macro approach is good enough, although it does not
work with the gen_fsm.

The deprecation of the erlang:get_stacktrace() feels similarly.

Karolis

On Fri, May 4, 2018 at 1:18 PM, Heinz N. Gies <heinz@REDACTED> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180504/088902bf/attachment.htm>