What do you think should be in OTP?

[maxlapshin]

Using application:get_env is just a global variable.

We use language with best-in-class isolation and then jump to global variables.

[max-au]

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}).

[vkatsuba]

• 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.
  

[vkatsuba]

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 . And something tells me that it is very closely related to Configuration of Erlang system

[wingyplus]

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

[vkatsuba]

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

A rebar3_edoc_extensions - for build documentation with awesome style!

Foreword Few days ago we was meet online with @dumbbell to discuss awesome CSS/JavaScript style what he made for amazing library khepri(here this documentation The khepri application). I’m ask if he don’t mind if will be created a rebar plugin where any project which uses this plugin can be able to use the same styles - and yey, he wasn’t mind . Meet new plugin rebar3_edoc_extensions! Usage Add into rebar.config: {project_plugins, [rebar3_edoc_extensions]}. Run command for bu…

and

Rebar3_ex_doc - a rebar3 plugin for generating documentation using ex_doc

rebar3_ex_doc - A rebar3 plugin for generating documentation using ex_doc This plugin uses edoc to generate doc chunks and ex_doc to craft both html and epub outputs. It should be duly noted that this functionality is thanks to many peoples efforts around EEP-48 and not the plugin. In the EEF build and packaging working group we have been planning to make said functionality, which has existed for a while now, available via a rebar3 plugin. rebar3_ex_doc makes it easy to get up and going. Per…

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 … 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

[starbelly]

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 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.

[josevalim]

@dumbbell

When more things are bundled together inside Erlang, we would all have to make compromises somewhere between the ease and speed of maintenance/updates to various components and the release engineering of Erlang/OTP. It also adds new commitments and support load on the Erlang/OTP team.

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.

[wojtekmach]

@vkatsuba

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 (…)

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.

[starbelly]

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

[Hanabi]

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.

[Taure]

@vkatsuba

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 . And something tells me that it is very closely related to Configuration of Erlang system

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

[vkatsuba]

@Taure

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

All combinations or as minimum - as more as possible

[crownedgrouse]

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.

[max-au]

+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.

[meox]

3 new guards:

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

[hauleth]

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

[meox]

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

[juhlig]

@meox

3 new guards:

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

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).