Ah nice, and that’s very interesting to me because I always thought there was Erlang and a std lib (like most languages) and then OTP was on top of that. If OTP is indeed just the standard library and is always likely to be, then I think there is merit in considering dropping the OTP name and it just being classed as the standard library.
Not sure whether there’s anything that would prevent that or be a potential blocker but I think it could be useful in helping ‘modernise’ Erlang (by making it that little bit more accessible by removing potential points of confusion).
I agree with Jose on it simply being stdlib by another name. I also agree that it’s probably about time to drop OTP, but it’s not a hill I’m going to die on either
At the very least the docs could better clarify as to what OTP is exactly. You’ll find in the docs mention of ERTS being part of OTP iirc. That doesn’t jive with my mental model. To make matters worse, we have a stdlib application, but that doesn’t encompass all of OTP.
You could say OTP I suppose is stdlib + all the other applications and tools that ship with Erlang/OTP. This ranges from mnesia to dbg, etc. etc. In that sense, it’s really more than just stdlib, it’s an entire framework for building systems in Erlang on top of ERTS and the BEAM with conventions and design principles to boot.
Of course, you could also say OTP is all that + ERTS
Glad I’m not the only one who thinks this is worth exploring and I wonder whether this could be a good opportunity to take a fresh look at everything.
Perhaps to begin with OTP as it is today simply becomes part of the standard library, then over time parts of it are extracted out and they, perhaps with other things, are then moved into an additional layer. Maybe it could be called something like:
Open Erlang Platform > Erlang Platform > Platform (taking ‘open’ and ‘platform’ from OTP)
Open Erlang Framework > Erlang Framework > Framework
Or just call it the Extended Standard Library - which is my favourite as most people will have a good idea of what it may be (or specifically, feel less confused).
So the most crucial parts of OTP would become part of the Standard Library, and the ESL would include everything else and perhaps also what might be needed to make interop between BEAM languages easier as well. Could be a way to kill multiple birds with one stone
That makes sense to me. Of course, the first step would be simply dropping OTP from documentation, etc. I know there’s books coming out soon that reference OTP But also, there would never be a perfect time to do it.
I definitely like that idea, and I think it’s worth exploring, but OTP team would have to be open to it first of course… and I guess they might become the erlang team if so
ERTS + kernel + stdlib (they are really not separable) - “language runtime”. I would really like to slim it down though (by cleaning up bits that shouldn’t be there anyway, like pool module)
standard libraries - ssl, crypto, public_key and their dependencies
In the ideal world there would’ve been a build tool and a package manager included into the language runtime, me choose which applications to fetch in my release. But at soon as I think of any “package manager” I hear “versioning” and my excitement fades. If anyone asks me, versioning is the hardest problem to solve after the “too many abstraction layers”.
At the time when corba was removed from Erlang/OTP we had a vision that the erlang/otp repository should only contain erts, stdlib, kernel and compiler. And then all other applications should me moved out just like corba.
However, this is the exact problem we hit. Or rather that all of our infrastructure for testing/versioning/patching has been geared towards everything being in one repository that it would take a lot of work to make it all work. We still have not managed to make testing and patching corba as easy as any other application.
As a side note, i keep thinking of how we could keep it all in one repo and still make the output of a build modular. It should be possible to build an OTP without a lot of these apps and add them modularly. Even if not dealing with version managers.
But that would need a lot of work on the configure and build system and the test system that come with it. Something like Jigsaw did for the JDK.
It should be possible and is on my own todo list if i ever get time (fund me) to work on the build system, because it come out of having a nice build system. But the current one work “good enough” and changing it is a big task.
But i still think there is nothing right now in how the code work that force to build a monolithic OTP from the OTP monorepo. It is just that the configure and build and test system are not adapted… and they all go hand in hand.
That said, if people are interested in helping the community and funding that kind of work, please come talk to me. I have been working on ideas around that for the past 2 or 3 years
I think OTP has always been more than the standard libraries and included applications. To my understanding, OTP is the whole concept of how to build an Erlang application using supervisor trees
process behaviors and releases, possibly providing a soft upgrade and making your design fault-tolerant and scalable by using the building blocks wisely. I think you should think of OTP as a brand and the original meaning of the abbreviation is historical and no longer relevant.
That’s definitely fair It’s never been a personal concern of mine, I simply try to put my self in other peoples shoes, specifically either trying to learn it all or interested in at all. There can be a tendency to be overly concerned in this regard.
Let’s face it though, there are bigger problems to solve and besides, it doesn’t matter what tech you’re interested in and/or starting to learn, there’s always going to be a concept that’s foreign and initially hard to wrap your head around.
