From time to time the community talks about would should be added to OTP, but I’m quite curious about what the community, and perhaps the OTP team, thinks should be removed?
I often think of modules and apps that could be added, but I quickly try to remind myself that perhaps before trying to add in more, we should remove old parts that generally are not in use by the community at large. I think if you can make the code base smaller it’s beneficial for everyone as well.
Good topic. Perhaps some parts should be removed unambiguously, but as for the support of various protocols, they should be expanded, let’s imagine how it would be easier for everyone to live if the rebar was integrated into Erlang and fully supported by the development core team. As far as clients are concerned, it may be worth expanding them rather than deleting them. Suppose we take the DIAMETER for Erlang, which is used in the mobile network, at the same time there is no support for the RADIUS, which leads to the use of custom tools, but is it worth using them if they can be part of the OTP? Perhaps I would say that it would be great to have a configurator who says - I want to have only this functionality but without some other functionally etc. Some… maybe customizer will be better then deleting some existing functionally. You see, for some products some specific functionally is needed for others - any others etc. Also, do not forget that libraries are born and die, someone stops supporting them, etc. but if it is in the core of the language, it must at least be supported, which means, regardless of how the core is updated, we can be sure that the functionality will work as well or will be replaced with an analog.
I definitely agree on the point that erlang should ship with rebar3 (renamed to rebar for great good). Every modern language ships with a build tool.
I do agree with you on the protocols part in general, but that has to be discussed on a case by case basis, but let us not forget CORBA Let’s not also forget that when it was removed, everyone was quite happy to see it go.
What I don’t expect is for everything under the sun to be included simply because it must be supported by OTP. Then, it’s more documentation, more tests to run, more to support period.
That’s not good in many ways for the community and OTP team I’d much rather see OTP team work on say boosting performance, improving tooling, etc. than having to maintain decades old code that no one uses anymore. Definitely not trying to speak on their behalf here, but if I was in their shoes, just wouldn’t want to be burdened.
Libraries born and die indeed, but that’s where the community must rally, and perhaps more importantly companies and foundations must sponsor and support libraries and apps such that they don’t die, so long as it’s actively used by a good portion of the community. But also, if something dies in OSS, it was surely always meant to be. If a lib is useful and used, it will not die. That’s another discussion entirely though.
As for adding more to OTP in general, it’s easy to add it’s much harder to remove
Yep, make sense. About httpc/httpd they can be deleted at all or updated for support of HTTP/2, WebSockets, SEE etc. Since at the moment there are many libraries that are trying to implement this, I have seen projects in which several libraries are used for the same only because many of these libraries support or do not support certain protocols. Or those functionality can be removed at all. But in other hand I think it would be much easier if developers of well-known libraries joined the core team and were responsible for the same aspects only within the OTP team(of course, if these developers do not mind ). Let’s say, integration rebar3 into Erlang, after it the same team what is developed/supported rebar3 can be responsible for it in core team, same for, let’s say we have cowboy and gun, it would be more better if httpc/httpd will be removed/replaced by cowboy/gun and team of those libraries will join to Erlang core team etc. It seems to me that this approach would rally better, imagine of many developers should stop desperately developing something that already works fine, take it and use it out of the box and start focus on other more important issue/implementations ets.
One thing I will comment on is I don’t think httpc should be removed It very much has utility, for example rebar3 must use it to bootstrap and fetch deps.
I’d remove the entire implicit init sequence and replace it with just a main function in which trees are explicitly started. As it is I think it’s big source of confusion for newcomers, and all the implicit global mutable state is difficult to reason about or statically analyse.
I also think mnesia would be better as Hex package rather than being shipped with OTP itself.
Whereas I respectfully disagree. Rationale: I very much like my zero dependencies and it is handy to have a default database that is fine for quite a lot of applications.
I don’t think that you’re without dependencies if you’re using mnesia. There’s still an external team that you depend on, and you’ll still need to go through them if you want a bug fix.
The main difference here is the way the dependency is being distributed. With it being part of OTP you’re using the OS package manager or similar rather than Hex, and you probably have to wait for a new OTP release for any changes to land. Hex is really good, and waiting for releases sucks, so I much prefer to have deps decoupled from the runtime.
Also, httpc is a (circular) dependency of ssl, used to refresh CRLs and (hopefully) in the future OCSP responses and certificates referenced in AIA extensions.
It definitely should ship with some powerful build system (and honestly that something should be rebar3)!
But yeah, the standard library really should be slimmed down, a lot of it should be standalone libraries (that can be easily fetched via rebar(3)). I like Rusts’ stance on this, nothing should be in the standard library unless it is very well general, basically as perfect as it can get, and won’t need to be iterated on, because you can’t safely make backwards incompatible changes in the standard library, where you can with versioned dependencies (that can also be released out of sync with the comparatively slow standard library updates).
I’d detach diameter, megaco, eldap, odbc, ftp/tftp, and think really hard of snmp. Probably clean up stuff like “pool”, “global_groups”, and think hard of more modules (cleaning up common_test is what I really am after).
I don’t share the sentiment of most people here. I guess most people here want OTP to be more like Linux, a bare kernel, whereas I’d prefer something like a BSD, a full-fledged OS.
The multitude of OTP apps in the standard distribution is one of the main reasons why I fell in love with erlang/otp. Being able to simply erl -man MODULE at any time is very comfortable and I don’t trust random erlang libraries/otp apps to provide proper documentation.
Also from what I’ve seen, proglang-specific package managers incentivize installing dependencies locally for each source tree which doesn’t sit right with me.
Not to say you can’t download and build packages in .config/rebar3/ and then install them to /usr/local/lib/erlang/lib but I doubt there are many people other than me who do that.
I use a rolling release distro though so maybe I just haven’t felt the pain of having to wait for the new version of a program to be packaged to sympathize.
I think there is some merit in this idea - and along the same line of thought perhaps we could have OTP as well as OTPF, which would be a framework that contains many of the things needed to easily create applications in an idiomatic Erlang way. It could be the missing gateway that Erlang is, imo, in desperate need of: What is Erlang's gateway application?
I think there is some merit in this idea - and along the same line of thought perhaps we could have OTP as well as OTPF, which would be a framework that contains many of the things needed to easily create applications in an idiomatic Erlang way
I really like this idea
It could be the missing gateway that Erlang is, imo, in desperate need of: What is Erlang’s gateway application?
Have you read Ferd’s blog post on “killer apps” btw?
Let’s not also forget that when it was removed, everyone was quite happy to see it go.
). Let’s say, integration rebar3 into Erlang, after it the same team what is developed/supported rebar3 can be responsible for it in core team, same for, let’s say we have cowboy and gun, it would be more better if httpc/httpd will be removed/replaced by cowboy/gun and team of those libraries will join to Erlang core team etc. It seems to me that this approach would rally better, imagine of many developers should stop desperately developing something that already works fine, take it and use it out of the box and start focus on other more important issue/implementations ets.