New EEP draft: Pinning operator ^ in patterns
Sat Jan 23 10:24:55 CET 2021
On 2021-01-23 17:36, zxq9 wrote:
> For example: The continued and *exclusive* focus on making everything be a
> release is damaging to adoption. It is just one more hurdle for newcomers
> and makes some things nearly impossible to do. Releases are very important
> for certain environments, but not a good fit for general programming.
It is a bit off-topic, but I believe there is such a focus on releases because
there is nothing else.
Looking back at my experience with Erlang, and watching friends starting with
it, the most painful part was never the syntax, it was always about the tooling.
There is no standard way to handle projects, dependencies, simple program
builds (not releases, single executables, i.e. "rebar3 escriptize"). Rebar3
can do part of it, but it still is a third party tool, and good luck if you
want, for example, a couple applications with a set of escripts depending on
them in the same repository.
Heck, even releases are insanely complex, I am not touching them without
rebar3/relx doing all the work. But the alternative is compiling each Erlang
file and running erl -pa.
And of course everything is still based on the environment loaded from the sys
config file which has to be bundled in the release (and yes I know you can now
use environment variables, and no they are no substitute to configuration
files loaded at runtime). I get it, releases where a solution to the kind of
software that was written at the time. But it is still a problem for every
developer out there.
I like to joke about Go, but for all its faults, basic tooling is there and it
There are tons of ways to make sure that Erlang does not become Cobol, and it
is all about tooling and libraries (do not get me started on calendar for
example), before touching the syntax. Of course one could put syntax
modifications first and create Erlang 2; It did not end up well for Perl.
More information about the erlang-questions