[erlang-questions] Erlang 21, Stability and the murder of an innocent Statemachine
Fred Hebert
mononcqc@REDACTED
Fri May 4 15:31:07 CEST 2018
Overall, I like some of the aggressiveness that we have seen lately on
introducing new useful features and seeing older ones get removed. I hate
that I'll have to adapt a bunch of projects to changes in logger
interfaces, but it will definitely be a more positive experience for users
joining the platform now. Similarly for Unicode support in the strings
module.
The thing that I'm a bit unsure about is that deprecation is used as a
warning to say something is:
a) no longer the favored mechanism to do something
b) will eventually be removed.
I can tolerate warnings for a) and ignore them, but I don't want to do it
for b) unless I do not know how long a thing will be deprecated for.
The thing is that if the warnings are used for a), you can have it
deprecated for 10 years and it won't be a big deal; gen_fsm and the old
string interface *might* fall into that category. Maybe get_stacktrace() as
well?
But for the case of b), if I don't have a straight timeline of when a
feature is going to disappear, then you bet your ass I want
warnings_as_errors and to tackle it ASAP. Because if I'm working on a big
project, there's no telling if a migration will take me 2 weeks or 2 years
(see how long Riak has been stuck on old ass versions), and the more
lenient you are as an organisation, the harder it is to stop being so.
I think I have something like 30-40 open-source libraries right now, most
of which are considered 'done' and no longer need changes. When the string
handling landed, I had to update dozens of them, and also had to shepherd
dozens of other ones from the community at large, sometimes because
maintainers have left, or sometimes because their upgrade schedule does not
align with mine.
If I know a deprecation means "something newer is being used but we're not
thinking of removing the old one" then fine. But right now I don't know
which it is I am getting, and that is where things get a bit frustrating. I
have to assume "Now is better than later": I don't want to be left out of a
critical SSL fix because I have a few thousand lines of non-critical code
that need patching up to get up there, delaying a deploy or a release by a
few precious days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180504/ed1ce957/attachment.htm>
More information about the erlang-questions
mailing list