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

[Oliver Korpilla]

Ah yes, dependencies! I see your problem now. 

We're using gen_statem for a test framework written in elixir for telecoms. The FSM has been the least of our problems.

I'm always amazed at the range of Erlang versions still in use. I keep forgetting that.

Oliver 


On May 4, 2018 8:25:35 AM EDT, "Heinz N. Gies" <heinz@REDACTED> wrote:
>Hi Oliver,
>I am not advocating to forbid migrating code to gen_statem when the
>maintainer feels it is an improvement for their code. I’m advocating
>for not forcing maintainers doing so for no reason.
>
>Karolis brought up another very good point I didn’t even think about.
>Code written with gen_statem will not be able to run on older erlang
>releases. While that’s probably not a issue on your own code where you
>control the releases completely it’s a nightmare for open source and
>libraries.
>
>
>> On 4. May 2018, at 14:12, Oliver Korpilla <Oliver.Korpilla@REDACTED>
>wrote:
>> 
>> Except for the init bug in 19.0 (which our infrastructure was fixed
>on for a long time) we found migrating to gen_statem a painless
>experience with decent improvements. But maybe we simply use a
>different or limited feature set?
>> 
>> Oliver
>> 
>> On May 4, 2018 8:03:11 AM EDT, "Heinz N. Gies" <heinz@REDACTED>
>wrote:
>> I have thought of that but I don’t think that’s a real option.
>Deprication warnings are important, this would turn all of them off
>which doesn’t help code quality. I want to know if something is
>deprecated and fix it in most cases. But as Karolis pointed out, it’s
>easy for a function or two but for a whole behaviour it’s nearly
>impossible.
>> 
>> It basically creates two erlang worlds, pre-statem and post-statem.
>> 
>> The stack trace is not great but it’s not as bad, it’s somewhat
>possible to just wrap the whole function calling it into a ifdef and
>call it a day. Not great it still is a decent amount of code
>duplication but it’s possible.
>https://github.com/Kyorai/clique/commit/b0e89de3cbb56396b59a1023903c7259ec2ef145#diff-7a19efbe2afedfb64aa7ec6690e9a13e
><https://github.com/Kyorai/clique/commit/b0e89de3cbb56396b59a1023903c7259ec2ef145#diff-7a19efbe2afedfb64aa7ec6690e9a13e>
>would be an example. It’s more annoying then other changes but not
>nearly as bad as the gen_fsm
>> 
>>> On 4. May 2018, at 13:58, Roger Lipscombe <roger@REDACTED
><mailto:roger@REDACTED>> wrote:
>>> 
>>> On 4 May 2018 at 12:07, Karolis Petrauskas <k.petrauskas@REDACTED
><mailto:k.petrauskas@REDACTED>> wrote:
>>> 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.
>>> 
>>> We upgraded successfully to OTP 20 (and compiled against OTP 21) by
>simply adding the following to the top of our gen_fsm modules:
>>> 
>>> -compile([nowarn_deprecated_function]).  % gen_fsm is deprecated;
>use gen_statem
>>> 
>>> It'll be a problem when gen_fsm is *removed*, but until then, we'll
>stick with this.
>> 
>> 
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180504/bbd9ccf7/attachment.htm>