What do you think should be in OTP?

How can I increase it to 2000? Code upgrade?

Code upgrade, indeed!
Another approach is to have official API to your gen_server, like gen_server:call(?MODULE, {set_capacity, 2000}).

  • Interactive documentation - where all examples of the code can be run in documentation web site and take a look to result.
  • Interactive tutor - e.g. as implemented for Golang - A Tour of Go.

2 posts were split to a new topic: Tryerlang.org - try Erlang in your browser!

Online Erlang customize builder - Imagine, you go to the official Erlang website, indicate in an online form under which OS and OS category to make the assembly, indicate which components you want to be in this assembly, press the assemble button and after a few seconds you will receive your own assembly without additional components that you do not use at all in your project :upside_down_face:. And something tells me that it is very closely related to Configuration of Erlang system :stuck_out_tongue_winking_eye:


Yeah. It’s something like that. But it still missing tools around an OTP. For example, a binary tool like erlang_ls. :wink:


Integration bootstrap into EDoc - for rebar3 projects already implemented few great plugins for build beautiful and convenient Erlang documentation


I believe will be provided also other similar plugins but what about Erlang.mk projects? The developers and team who use Erlang.mk instead of rebar3 will still experience inconvenience with the old style of documentation :frowning: … At the same time @garazdawi already did an amazing job with the integration of Bootstrap into official Erlang web site and we already know how positively the Erlang community reacted to this. I believe that it would be great if EDoc also will have Bootstrap HTML/CSS/JavaScript stuff for build cross-browser documentation for any existing project :upside_down_face:


I think edoc styles and so forth should be definitely be updated, but I don’t think it obviates the need for using ex_doc when publishing docs to hex. The docs generated by ex_doc are more than just pretty :slight_smile: It’s a standard format. One important aspect is a standardized way of generating links such that packages can link to each other (e.g., type links) on hexdocs.pm.

It’s possible you could have that all in edoc, but that requires edoc not only being hex aware but keeping up with ex_doc, moving target style.

Users of erlang.mk could use ex_doc right now, if they wanted to FWIW. The instructions in ex_doc reference rebar3 but could be applied to erlang.mk.


Agreed. Almost all languages that are considered batteries included end-up with unmaintained or outdated modules, which later are deprecated and removed anyway. Less is more!

The community will always be larger than the Erlang/OTP team and it should be on us to provide the missing pieces we find necessary. :slight_smile:


This is a really cool idea. Compared to most other ideas in this thread this doesn’t need changes in OTP itself (though OTP xcomp improvements would greatly help) so it’s a great candidate for a community project that maybe would become official one day.


Yeah, there was a reason I started a thread about what should NOT be in OTP :slight_smile:


I find the idea of adding javascript to edoc egregious. The new erlang.org looks comparatively worse on browsers like netsurf. If we’ll need spidermonkey or V8 to “properly” view the docs, I’d ask for a reevaluation.


With the customized build do you want them like with a package or src? rpm, Deb or just a tar ball or all combinations. :slight_smile:


All combinations or as minimum - as more as possible :upside_down_face:


Agree with essen.
We should better remove things or at least move high level applications out of Erlang (megaco, jinterface etc…).
But some things need to be added to Erlang MHO :

  • missing compression algorithms, in particular lzma
  • exec command for os with exit code
  • namespace concept to allow use of modules with same name but from two (or more) different sources.

+1 for having a proper “os:cmd” that returns exit code, stdin/stdout/stderr separately, and has somewhat more control. I have a dozen of those spread over various places in code.


3 new guards:

  • is_ip(IP): is_ipv4(IP) orelse is_ipv6(IP)
  • is_ipv4(IP)
  • is_ipv6(IP)

It can be easily implemented as a macro. And in fact it is implemented as macro in at least one place in ERTS.


yes what I’m looking for is a simple way to use that macro/guards without reimplementing it over and over


IMO, no, this should definitely not be among the collection of guards. Guard BIFs as such are supposed to be very low-level, close-to-the-language, general-purpose things, operating on the basic data types. IP addresses are a higher-level construct which is restricted to the inet context. I understand the wish, but those should not be guards.

What I would like to see, however, are functions in inet by which a term can be checked for IP-ish-ness. That wouldn’t be as convenient as guards, but much better than repeated manual reimplementations.

As for IP-checking macros… There are some in kernel/src/inet_int.hrl, namely ?ip/1 for IPv4 and ?ip6/1 for IPv6 address tuples. I wouldn’t encourage using them in user code, though, they are really meant for inet internals. As such, they also have a loophole in that they will happily result in true for tuple sizes equal to or greater than 4 (or 8 for IPv6), as long as the first 4 (8) elements are integers in the range 0..16#FF (0..16#FFFF).


Would a header file do? It’s quite common to have macros in header files. For example the ones for EUnit, for assertions, and for the logger.