In topic What do you think should not be in OTP? pick up a good question. I suppose it make sense to divide it to should be and should not be 
. Let’s start about cache in OTP, already implemented ets, mnesia, persistent_term - we can ask, what else we need? Well, at least a simple cache where we can be totally sure about speed and about expiring data. Other point - integrate rebar3 into OTP. And of course add support of client/server for HTTP/1 ,HTTP2, WebSockets, SSE etc. What else you think should be in OTP?
4 Likes
JSON support.
For LTE telecoms applications, the GTP protocol would not be a bad thing to have.
Neither are hugely complex, so having them done right in OTP would be a boon.
Edit - for the former, it looks like this has come up before:
8 Likes
A few things off the top of my head :
-
rebar of course
-
an asciidoc lib or markdown lib in conjunction with moving docs into source code files in either markdown or asciidoc.
-
perhaps something akin to eex, though I’m not terribly sure how much use it would see in the erlang community. eex gets used a lot in the elixir community though. I can imagine how it would be used within the erlang community, but I think a survey might ought to be done.
-
a code formatter
… yes, yes, there’s erl_tidy, but it should be replaced and/or overhauled based on what the community has put out there such as rebar3_format, erlfmt, etc. I’d really love to see the community come together on this one and further OTP accept it 
A few years ago, I could think of a lot of things to add, but in retrospect… yeah. I’d need to think a good bit on other things that could be added.
9 Likes
- RADIUS protocol
- Profiling tool/functionality
- Benchmarks from box
- Load test from box
4 Likes
Aside from RADIUS, there’s already eprof, fprof, etc. are you thinking of improving those or some other type of profiling that doesn’t exist?
4 Likes
Ahh, a big one I forgot, observer for the command line similar to GitHub - zhongwencool/observer_cli: Visualize Erlang/Elixir Nodes On The Command Line
6 Likes
Yes. Plus better tracing stuff. Possibly a single tool that integrates all profiling functions.
2 Likes
Yeah, that’s what I was getting at with something like eex, but more general purpose … See @OvermindDL1’s thoughtful response here : What do we need for better BEAM interop? - #6 by OvermindDL1
3 Likes
- JSON-RPC
- BERT/BERT-RPC (Binary Erlang Term) protocol for communication by other clients(JavaScript, Lua, Python, Go, R etc.)
4 Likes
One problem with including rebar3 as it stands is that it has a number of dependencies which aren’t part of OTP and would also have to be supported. I don’t think something in OTP should be dependent on something which is not in OTP.
8 Likes
Totally agree. But if the main goal/issue is - stop use dependencies, I believe that the parts of it will be or can be rewrites. Maybe good start will be describe and create tasks in GitHub with deep description and with label eg - help wanted.
2 Likes
is BERT-RPC an alive protocol used? I’d love to see a protocol widely used by other languages, like gRPC.
4 Likes
I believe everything can be vendored in, some deps dropped as well. Definitely would not come with external dependencies from the conversations I caught, and I agree.
3 Likes
QUIC support would be nice, maybe also netconf
13 Likes
Ahh yeah, another thing I forgot to note. If erlang/otp had something akin to eex, that would mean bbmustache could be dropped. I mean, so long as Fred and Tristan would be for that of course. But that would be another reason to have such a thing in OTP. I think it still needs further justification around usage at large beyond just it’s potential use in rebar, but yeah.
3 Likes
I would say not specific protocols, but some common concurency/distribution primitives, say
- Distributed process register similar to gproc/syn (we have pg now which is kind of does that though)
- Some generic process/worker pool like pooler
- Some library of generic rate-limiters / overload control primitives similar to jobs or generic version of OTP logger’s overload protection
- Some small library to control timeouts / timers (some abstraction on top of erlang:send_after / erlang:cancel_timer etc) - with gen_statem it might be not that usefull, but I implemented a tons of gen_servers with boilerplace code around
send_after/cancel_timeretc)
But also some set of interfaces/behaviors (similar to the work that have been done for logging):
- Generic interface for exporting metrics, with pluggable backends (not sure it’s possible though, given the wide variety of different metrics formats)
- Interface for more advanced configuration formats, other than
sys.config/application:env(so, there is an interface to access the configuration and to handle configuration upgrades, but the syntax would depend on backend) - Maybe generic SQL database interface like Python’s DB-API - minimal set of interfaces each (SQL?) database driver should implement
- Maybe some HTTP client interface with swappable backends (so, library developers could write their libraries doing HTTP stuff through this interface and not forcing everyone to use some specific HTTP client)
- Maybe instead of specific JSON library, provide an interface each JSON library should implement, so concrete implementation can be swapped
- Probably some better API for timezone-aware date/time-based calculations, date/time formatting/parsing, similar to Python’s datetime. We have qdate, but it’s quite limited. But timezone database should be definitely shipped separately.
7 Likes
I think Lukas was talking about something similar here : Configuration of Erlang system
I think that might be a great thing, and it’s the little things that go a long way and have big impact!
Fully agree 
3 Likes
Having the shell extended to something similar to Kjell would be a nice addition for those of us who enjoy christmas tree modes.
“Why not just use Kjell?” - I never got it to work properly as a drop-in replacement. 
5 Likes