
Ten Years of Erlang - iamd3vil
https://ferd.ca/ten-years-of-erlang.html
======
tombert
I love Erlang, and am one of the very few people who (in the past) managed to
find work doing it full time. The actor paradigm it provides is surprisingly
simple and elegant to write an app, even on a single node, and of course
making distributed apps is fairly straightforward as a result of it.

I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I
_still_ find the prolog-esque syntax a bit frustrating. I've been doing this
stuff for like 6 years, and I still occasionally get tripped up on when to do
a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2
semantics, overall I find the syntax for LFE to be a lot more consistent than
raw Erlang.

This isn't to crap all over regular Erlang though; Erlang was the first
language I had seen that fully embraced pattern-matching, and I find that kind
of pattern to be incredibly elegant.

If someone reading this hasn't tried out Erlang, do yourself a favor, download
and install it, and build a simple TCP chat server. I can virtually guarantee
you that it will be easier than anything you've built in C/C++, and it's
incredibly satisfying to have something you built in a few hours have the
ability to scale correctly.

~~~
unixhero
Not being facetious, but could the joy resemble the fun I associate with
developing with Ruby?

~~~
GuiA
If I understand you and OP correctly, it’s a kind of joy derived from doing
something for a while, being acutely aware of the limitations and frustrations
that come with it, and then discovering a brand new way of working that
doesn’t involve any of the slog you’d grown accustomed to.

Speaking purely personally, mathematics has consistently been the discipline
that’s delivered the most bang for my buck in that regard - learning a new
branch can let you solve problems that are just impossible to solve, or take
pages and pages of computation, in a few lines.

~~~
tombert
You did understand me correctly :).

I agree with mathematics; I came to the same conclusion about five years ago;
I realized understanding some basic type theory made a whole lot of
programming easier for me.

It's kind of dry reading, but I've been trying to get into different process
calculi lately; specifically the Pi Calculus and Join Calculus, since these
things feel like a cool hybrid of computer-science and mathematics.

~~~
dlcmh
Insightful! Any process calculus or type theory literature to recommend? Found
[https://pdfs.semanticscholar.org/12d9/eae1638729aeb237b5be44...](https://pdfs.semanticscholar.org/12d9/eae1638729aeb237b5be445ee91ecdd3c5d7.pdf)
while googling - would this be a good place to start?

~~~
tombert
I'm still learning, but I've really enjoyed this book [1]. It's pretty theory-
heavy, especially at first, but overall I have found it fairly approachable.

Also, Tony Hoare's book on CSP is actually a fairly interesting read;
certainly interesting if you like Go. You can actually download it legally
free here: [2]

In regards to type theory, I'd recommend starting by learning Haskell, just to
make the terminology a little less scary, then picking up the book "Basic
Simple Type Theory" by J Roger Hindley. Don't let the name fool you, it's
still pretty heavy stuff; there's no way I would have been able to get through
it if I hadn't learned Haskell beforehand. [3]

[1] [https://www.amazon.com/Programming-Distributed-Computing-
Sys...](https://www.amazon.com/Programming-Distributed-Computing-Systems-
Foundational/dp/0262018985/ref=sr_1_5?keywords=distributed+programming&qid=1562647746&s=gateway&sr=8-5)

[2] [http://usingcsp.com/](http://usingcsp.com/)

[3] [https://www.amazon.com/Simple-Cambridge-Theoretical-
Computer...](https://www.amazon.com/Simple-Cambridge-Theoretical-Computer-
Science/dp/0521054222/ref=sr_1_1?keywords=basic+simple+type+theory&qid=1562647997&s=gateway&sr=8-1)

------
niftich
It's a gem of an observation that newcomers to an environment often only make
it to the first few rungs of the system complexity / actualization ladder.
Once you look, you see this everywhere, and not just in IT but with any sort
of design exercise or institutional process, any complex system that's full of
Chesterton's fences, and people will either evolve to debate their rationale
from a position of experience, or be selected (or self-selected) away into
fresh environments where the novelty and discovery-until-discouragement can
begin again.

It also shows that the first few rungs matter a lot; this is the territory of
easy answers, where following a few simple rules leads to rapid productivity,
and there will always be people for whom that level is good enough, either
through carefully weighed decisions from limited information, or ignorance and
deferment of future problems and their solutions. You can't solve everyone's
problems for them, but you can try to evangelize, and you can try to build
your system in a way that best practices can be incrementally adopted from
existing fumblings. Anticipate that most of it will stay mediocre.

History is littered with systems that, in hindsight, seem to have offered
sensible solutions to complex problems, yet didn't survive in the end. Much
knowledge and wisdom is lost, and others independently discover it when trying
to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that
masquerades as a programming language yet asks questions at a much higher
conceptual level: what do we want systems as a whole to look like if we have
to maintain them indefinitely? Its architectural innovations have been copied
elsewhere, where they rarely form part of a coherent stack, but at least
expose people to the advantages of its model. This may also be the most viable
source of adopters of Erlang at higher levels: people who've sought out
similar model for its benefits, and could thrive with an offering that pays
attention to these concerns throughout.

~~~
chessturk
> people who've sought out similar model for its benefits, and could thrive
> with an offering that pays attention to these concerns throughout.

I discovered BEAM while looking into a way to run concurrent, distributed
Golang/gRPC services in a supervisor-worker set up. I've continued tinkering
with OTP ever since.

Edit: added quoted portion.

~~~
Jailbird
Did you find anything for the golang part?

~~~
dnautics
Kubernetes?

------
derefr
Re: those infrastructure components written in Erlang not attracting Erlang
users in any permanent way—it’s not so much that they have more users than
contributors, but rather just the bare fact of them being infrastructure
components. A black-box infrastructure component can’t be a “killer app” for a
language.

Rails is a killer-app for Ruby because it’s a _framework_ ; a developer who
uses Rails in their project is inherently a Ruby developer. People learned
Ruby to use Rails.

But you don’t need to write a single line of Erlang to use CouchDB or Riak or
Ejabberd. They’re self-contained. (And, in fact, scriptable in not-Erlang
languages; CouchDB for example spawns and manages a JavaScript engine to run
its “design documents” on.)

Thus, these infra components becoming popular doesn’t cause there to be any
more Erlang programmers than there were before.

In that sense, I would say that Erlang has _never_ had a true “killer app”
yet. (Outside of a few specialized domains, like telecom and fintech, where
the OTP platform itself is Erlang’s killer app.)

And even in the places where Erlang itself is a “killer app”, it’s also not so
much a viral thing that the whole industry gets excited about; rather, Erlang
is more of a “secret sauce.” Nobody’s learning Erlang in their basement
because their friend told them it’d be the next big thing in their industry.

How does anyone learn Erlang, then? Well, usually, engineers are _forced_ to
learn Erlang at one job (where the system architect there decided on it); they
get to liking it; and then, when they later become a system architect
themselves in another job, and choose a stack, they choose Erlang, thus
forcing a new wave of engineers to learn it.

~~~
brightball
Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir
based ones.

Nerves, which is already being heavily used for embedded systems and only
getting stronger thanks to the likes of Scenic.

And Phoenix LiveView (not released yet), which I personally think pulls the
strengths of Phoenix together in a way that can truly disrupt web development.
It’s very difficult to do what LiveView is doing on other tech stacks.

The combination of those two will likely fuel things long term.

~~~
porker
> And Phoenix LiveView (not released yet), which I personally think pulls the
> strengths of Phoenix together in a way that can truly disrupt web
> development. It’s very difficult to do what LiveView is doing on other tech
> stacks.

LiveView cannot avoid latency. When I've experimented it's great for something
running on my local network; less good when it's in a datacentre in another
country. It's laggy.

And unless you replicate to many locations, or can deploy it to edge compute
nodes (no idea) then this will always be a problem compared to 'true' client-
side development.

I want it to work but I don't see how it can beat the laws of physics.

~~~
nickjj
> LiveView cannot avoid latency. When I've experimented it's great for
> something running on my local network; less good when it's in a datacentre
> in another country. It's laggy.

If you built a traditional SPA, aren't you still making loads of calls to your
server?

I don't see how LiveView would be more laggy than that. In both cases you're
making network calls from the user's machine, to your server, getting a
response from the server and then rendering output on the client when it's
received.

Of course you can cheat and do optimistic rendering on the client (like
outputting what you wrote instantly in some DOM element instead of waiting for
a response and validating it after the fact) but I believe that enhancement
could be done with both techs.

The only place where LiveView falls short is a true offline / fully client
side app, but those are such a rare breed and way out of the norm for a
typical web app. In 20 years of web dev as a freelancer, I've been asked 0
times to build an offline / client side JS app.

~~~
porker
> If you built a traditional SPA, aren't you still making loads of calls to
> your server?

For data loading, yes. But here's a few random thoughts:

* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.

* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.

My testing suggested that client-side validation still gave better results,
because it was instant. Moving forward & back through a wizard was better if
client-side rather than each screen rendered server-side.

I experimented early May so am a little hazy on details (and can't find which
PIM I put my notes in, _sigh_ ) and look forward to seeing other people's
experiments. Particularly when not run on their local machine.

~~~
nickjj
> My testing suggested that client-side validation still gave better results,
> because it was instant.

In some cases yes, but I don't think you can get away with client side
validation for a lot of things because they depend on the state of your
database to return the correct result.

For example, how would you validate an email or username on the client when
the availability of the name depends on you making a database call to see if a
user exists already? You have to make a network call, get the result and then
update your validation errors on the client based on that server side result.

But for validating something like a phone number or twitter handle, sure,
client side works all the way but I don't think having even 200ms of delay for
that validation is going to make for a bad user experience. 200ms is a lot
too. That's about what it takes to ping a server in Tokyo from New York.

Your other points are valid tho. I guess we'll see where LiveView ends up
going.

------
mrdoops
I find the key point to language adoption is that self-selection that occurs.
What type of person and their personality does an ecosystem attract and what
is that type of person good at?

The BEAM ecosystem is all about fault-tolerance, distribution, and
concurrency. These BEAM concepts could be described as "upper ladder" ideas:
they require more prerequisite understanding of systems engineering to
appreciate. Despite being a fallacy of composition, to compare a given Erlang
vs Ruby/Rails developer may be useful to consider.

A person who invests in learning Ruby/Rails might be motivated to do so
because of that bootstrapping mindset of MVP's and failing fast. Our average
Rails developer might be rolling the dice for that "killer app" opportunity
more often than our Erlang developer prioritizing concurrency and reliability.
This may be because those BEAM features are more useful at a later stage of
product development. So while the BEAM features are uniquely powerful if they
require an upper-ladder understanding our MVP-developer doesn't yet have -
they're unlikely to pick Erlang as tool-set to invest in.

If we accept that the BEAM is good at infrastructure and that doesn't result
in as many opportunities for these hype-cycle-causing-killer-apps, than what
could be changed in the ecosystem to support this goal? Can we get both the
later stage benefits of reliability and concurrency in addition to the early-
stage productivity benefits? Maybe this early-stage development focus is where
Elixir will break out of the infrastructure-niche Erlang seems to be in. Can
Elixir's tooling reach a short enough new-product feedback loop more potential
killer-apps get deployed into production? I think as Elixir brings in some
different personalities to the ecosystem we could see more killer apps but
that idea -> production feedback loop seems to be the key component.

~~~
reallydude
> what could be changed in the ecosystem to support this goal?

1\. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't
need to know, so we have a chicken-egg problem of people entrenched don't want
to spend time that will help the language and underlying strategies become
more widely adopted. Perhaps this was the production feedback loop you were
referencing. We still don't have a good methodology for measuring all sorts of
things in software dev. 10 years, 20 years, the language may just never do
more than incremental changes (like elixir).

2\. Handling text is still awful in these languages.

~~~
justin66
> Handling text is still awful in these languages.

In contrast to what? Honestly just curious.

~~~
ch4s3
You can do really cool stuff with SNOBOL[1] or TRAC. Really any homoiconic
Lang or lisp will do great things with text. But I think Elixir handles text
just fine if it’s UTF-8.

[1][https://en.m.wikipedia.org/wiki/SNOBOL](https://en.m.wikipedia.org/wiki/SNOBOL)

~~~
justin66
> SNOBOL

Oh dear.

~~~
ch4s3
Yeah, I'm not really serious about that one.

------
sergiotapia
Here's to another 10 years of Erlang/Elixir. The programming stack for the
boring software developer that wants to clock out at 5 sharp. It's fantastic I
tell ya. I have been blessed with opportunities to work with Elixir fulltime
and it's hands down the best experience I've had. Compared to C#, Rails,
Nodejs, it's miles ahead. (Although C# with dotnet is coming up fast and
_crazy_ compared to what it was 9 years ago).

This ladder is a great blueprint, great article:

    
    
        functional programming
        isolated processes and concurrency
        reliable concurrency (links, monitors, timeouts)
        OTP behaviours and other system abstractions
        How to structure OTP systems
        How to build releases and handle their life cycle
        How to never take the system down, and how to operate it

~~~
saberience
I think you should add to this comment "in my opinion."

Because in my opinion C# is miles ahead of Erlang. If I want to create an
application, back-end, front-end, running on a wide variety of platforms, Mac,
Linux, PC, IOS, etc, I would use C# 1000 times over versus Erlang.

The tools available, documentation, huge amount of libraries and support mean
that developer efficiency in C# land is light-years ahead of Erlang. I could
make a website + backend + IOS/Android app with all shared code while using
tons of pre-existing OSS frameworks / packages and get it all up and running
and prod/enterprise ready in no time at all and have it ready for enterprise
load and scalability. Try that with Erlang!

~~~
verttii
Wouldn't this logic make Java by far the greatest language ever invented?

~~~
askl56
That's not already self evident?

------
animesh
This is how the page looked when Erlang posts caused HN to become slow.

[http://www.waybackhn.com/?date=2009-03-11](http://www.waybackhn.com/?date=2009-03-11)

~~~
dmix
That was my favourite moment in HN history. I believe it was even pg who
started the whole “post erlang articles so HN appears boring” thing.

Edit: yes of course, he mentioned it in the text post in your link but as a
joke:
[https://news.ycombinator.com/item?id=512145](https://news.ycombinator.com/item?id=512145)

------
davidw
Good observations.

'Getting' OTP, and especially how to structure an application the right way is
definitely tough, because there's not a lot out there like it if you come from
the world of C or scripting languages. It's not just code organization, but
thinking about how to structure all the processes so that things fail in a
'good' way, and you have everything talking in the right way.

A big thanks to Fred for his book, and the many hours he has spent helping
people on the mailing list, IRC and elsewhere.

I miss my time working with Erlang. I think it's still an indicator of an
environment willing to try new things, but like he writes, you have to be wary
of the places that are 'serial early adopters' too; I've encountered a few of
those in my Erlang career.

------
alberth
Fantastic article; it paints a great picture of the journey taken &
accomplished achieved.

My personal take is that the next major milestone for Erlang/Elixir will be a
significantly more performance BEAM. Be it JIT or reworked Hipe.

Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only
remaining aspect that would keep a Ruby developer using Ruby is the perf vs
Erlang. Today, for many raw perf task there isn’t a meaningful difference in
speed (note I’m not taking scalability). As soon as the speed difference
becomes meaningful, Erlang will get another wave of people.

~~~
Jedi72
I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently
added functionality to display response times in microseconds, partially as a
showcase for its good performance. I dont doubt you can get more performance
in C++ or something but its still lighting compared to Ruby.

~~~
hartator
Phoenix is faster than Rails, however Ruby is faster than Elixir when doing
CPU intensive tasks. Like parsing text.

~~~
nickjj
> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing
> CPU intensive tasks. Like parsing text.

What is your definition of slow or fast?

For example with Elixir it was possible to generate 5,000x random 19 character
codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how
long it would take with Ruby but for such a text / CPU intensive task, I'm
quite happy with the performance.

Also parsing templates with EEx is ridiculously fast, because it's not treated
as a string.

~~~
hartator

          spec-builder git:(master)  ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }"
        0.005459   0.000009   0.005468 (  0.005464)
    

I am at 5ms on a MacBook. Can you share your iex code?

~~~
nickjj
Here's a couple of versions of the code:
[https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...](https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce8030c)

It would be interesting if you wanted to come up with a Ruby version that
adheres to the random code spec which should be able to be determined from
looking at the first 2 versions. It's basically only a subset of characters
that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.

I personally use the 25ms version because I find it to be the best one if you
factor in both speed and readability. I'm sure there's better ways but I'm
only an Elixir beginner.

Also for the record I didn't write the 2nd or 3rd versions of that gist. I
asked around in the community and that's what others have put together.

------
giancarlostoro
As someone who loves servers and back-end work, Erlang is amazing to me. I too
read that book by Joe Armstrong, but I never really got to use Erlang for much
since I don't get paid to use it. Recently I was trying out Elixir and going
through the documentation and was pleasantly surprised how much of it is
Erlang-like.

I wish the industry was much more Erlang friendly.

~~~
di4na
Well elixir explicitly try to not move away from the erlang paradigm and to be
fully and "naturally" inter-operable with it. It is far more integrated with
erlang than Scala is with Java as an example.

It is basically erlang with better tooling and still an easy use of erlang.

~~~
mononcqc
We probably had our discussions about this before, tooling definitions diverge
at times, and I have a vested interest in some of them, but I will just state
my disagreement on the better tooling side of things ;)

~~~
strmpnk
To say a few things that Fred isn't saying here (these are my opinions not
his):

\- Early Erlang tools had a lot of issues when Elixir showed up but rebar3
made quick progress and is a very good set of tools integrated into one
command-line interface

\- rebar3 has supported creating releases for a very long time which Elixir's
mix tool is just catching up to (sure distillery supported things but so did
relx and half a dozen other Erlang tools)

\- rebar3 has built-in support for things like dialyzer which still require
extra work to use from mix

\- rebar3's _checkouts feature is very nice and has no good mix equivalent

\- rebar3 offers a declarative configuration setup which makes it easier for
other tools to integrate their data and read other data w/o requiring plugins
to be loaded everywhere (and this is to say it still supports scripting where
needed, which will still result in a declarative output)

\- rebar3's version resolution system is more practical and puts the final
control of version selection in the developer's hands rather than strictly
package manager metadata which can lag or suffer unfortunate problems from
version operators and unfortunate problems that come up from blind-semver
adoption (this is a longer topic so I apologize for the poor summary here but
I do think there is a good argument for rebar3's approach)

\- rebar3 works and upgrades independently from Erlang/OTP releases allowing
more fluid iteration whereas mix is very much locked to Elixir

I participate in the Elixir community and every time I hear the tooling story
I think about all of the things I miss from Erlang tools when using Elixir.
It'd be more accurate to say that Elixir has revitalized Erlang with a bit of
competition and some diversity in background.

Either way, there is room for improvements in both camps. I hope Elixir's mix
catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore
some of the caveats that are still around as given facts of life (perhaps
getting better support for the wider set of BEAM languages would be a start so
each doesn't need its own tool).

~~~
josevalim
Very good summary!

One quick correction: the equivalent to _checkouts in Mix is to use path
dependencies. I often use environment variables to control when to use one or
the other and I like the fine grained control more. Here is an example:
[https://github.com/elixir-
ecto/ecto_sql/blob/master/mix.exs#...](https://github.com/elixir-
ecto/ecto_sql/blob/master/mix.exs#L67)

But in general yes, we are glad to borrow ideas from each other and we should
continue doing it!

~~~
strmpnk
Thanks for this tip. I find myself a little more reluctant to rely on
environment variables for this sort of thing but it'd be fair to say the same
about filesystem state.

My only problem with this solution is that it changes the mix configuration
itself (which is version controlled) which is fine if others are in need of
similar overrides when working on the project. For one-off/local things, it
can be a bit heavy for temporary overrides.

Still, it's a fair trade-off since it's a lot easier to code up logic like
this with mix compared to rebar3.

------
bfrog
Interestingly enough I started using Erlang around the same time and while
I've continued to use it for the project I started then on and off, I've not
had a lot of reason to use it on other projects. I don't ever think it'll be
as wide spread or as popular for many of the reasons listed. I do think it
will continue to be a tool used to create great projects with very few hands.
In the right hands and for the right projects it is an incredibly productive
tool.

~~~
melling
If you search HN history, it appears Elixir seems to get much more buzz. Saw
this from a few days ago:

[https://news.ycombinator.com/item?id=20357055](https://news.ycombinator.com/item?id=20357055)

Elixir is just a slightly changed Erlang syntax?

~~~
yawaramin
Elixir has a homoiconic syntax and hygienic macros, like a Lisp. In fact much
of the user-facing syntax of Elixir is just macro definitions. You can do a
lot of things with it at compile time, and people take advantage of it to do
really cool things like compile Phoenix routes down into a single static
dispatching function so that requests can be routed quickly.

~~~
grzm
Could you expand on what you mean by Elixir being homoiconic? That doesn’t
seem readily apparent to me, and is contradicted by posts such as
[http://www.petecorey.com/blog/2017/08/07/what-if-elixir-
were...](http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were-
homoiconic/)

~~~
yawaramin
Yup you're right, my bad–I mixed up homoiconicity and hygienic
macros–apparently like many before me!

------
strikelaserclaw
"But the vast majority of them will be a continuous flow of serial early
adopters who surf from tech to tech, sniffing the best opportunity to gain a
competitive advantage by being first to use a type of framework, language, or
toolkit." \- Oh god, that hit me so hard.

~~~
tabtab
What's the common slang for that? "Buzzword Surfer"?

~~~
strikelaserclaw
middle manager?

~~~
tabtab
Most buzzword pushers are architects or similar in my experience. I suppose
that's arguably "middle manager".

------
loxs
I was there. Had a full time Erlang job even before the line numbers in stack
traces. Later migrated to more enterprise-y languages... and for me, the big
missing thing in Erlang is the IDE. And a company (or a big community) that is
dedicated to catering to the developers. This was never a thing in Erlang.

------
peterwwillis
Riak convinced me that any language pretending that it could magically create
better products was full of shit.

Riak is not great. It performs well, but doesn't scale well. It has tons of
operational overhead, a lot of bugs (and it didn't help that a slowly
disintegrating company left less time to fix those bugs "until next release"),
and any changes to the cluster while it's being used heavily leads to
instability/unavailability. And many of its features were not implemented
great; the SOLR functionality is a pig, for example, and "enterprise"
replication is flaky.

On our team, we had a few engineers who could write Erlang, but they slowly
moved to other teams, so troubleshooting production issues became a black box
of pain. I'm so glad the product we had using it was sunset.

~~~
ulkesh
Agreed, mostly. Riak was used in one of the first implementations of AT&T
Messages (Web) as a secondary-index and key-value store. It performed so
horribly that the whole thing ended up being rewritten using Oracle. The truth
is, Riak was designed for basic key-value storage. Everything else they added
on worked pretty badly, especially their javascript integration.

All that being said, I do not blame Erlang for Riak. I blame Basho. Their
support was clueless, and their platform simply didn't perform as advertised.

------
parentheses
This is a fantastic article.

A question for rubyists out there: what does the "ladder of ideas" for ruby
look like?

------
butterisgood
Was a bit more than 10 years for me. I had coworkers struggling with netsnmp
to build out a mock control plane for a new and exciting data center
management platform. I whipped up a mocked out version with OTP in a really
short time and eventually the mocked version was good enough to plug into the
real backend so we shipped it.

It was elegant and clear!

------
sam0x17
For what it's worth, I decided to pick up Elixir based on this post.

------
arendtio
I have never written a single line of Erlang, but I run my own ejabberd.
However, looking at the package build scripts and build instruction, I have
the impression that compiling a project like ejabberd can be complicated.

Does someone know if this is an inherent Erlang problem or just due to some
weird project setup in this case?

~~~
mononcqc
Ejabberd runs with a lot of legacy. Essentially the first build tool that
could pull deps in Erlang dates from 2007-2009, and it took another few years
before more modern tools came to be in what their current form is.

All these bigger projects tend to have a bit weirder idiomatic build setups
because they had to haphazardly reimplement bits of (at the time) yet non-
existing build systems by hand.

~~~
arendtio
Okay, but if I would start a project today, there would be better tools? Are
those documented in the Erlang documentation or are there any recommendations
on which tool I should use?

~~~
mononcqc
As one of its maintainers I’m partial to rebar3
([http://www.rebar3.org/](http://www.rebar3.org/))

It’s become near-official for OSS Erlang work and the OTP team has moved the
repo under their GitHub organisation
([https://github.com/erlang/rebar3](https://github.com/erlang/rebar3))

Erlang.mk tends to be the other option otherwise.

------
maddy1512
I started learning erlang and was stuck at 2nd rung, problem with erlang
is(at-least for me) that there are not enough projects/use cases to
learn/build for practice.

------
perlgeek
So, what's the quickest way to get into OTP?

To me it looks like Erlang itself isn't all that interesting, and OTP is where
all the fun and magic is.

~~~
andrenth
There are some books focused on OTP:

* Erlang and OTP in Action;

* Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems;

* Designing Elixir Systems with OTP (in beta).

------
msie
RIP Joe Armstrong

------
tabtab
Functional programming has too long of a learning curve to the average
programmer. A language should be judged by how long it takes _average_
programmers to become proficient in it, not the "Sheldon Cooper" types. In
typical medium and large organizations, it's difficult keep being selective
about programmer hiring. (There are org structural/political reasons that
would take several paragraphs to explain.)

This problem existed since Lisp was invented. The benefits would have to be
large to overcome the downsides of this learning curve, and so far they are
not, except in certain niches.

I hate the rain the functional parade, but it's been tried and retried for
many decades, but will just _not_ fly in the majority of the real world. I'm
just the messenger. The jet-powered chainsaw works wonderful in the lab, but
actual lumberjacks either can't figure out how to start it or blow their arms
off.

If you disagree, please reply instead of negativate me. I would greatly
appreciate that.

~~~
carapace
Hi there,

I sometimes try to help normals relate to me by asking, "You know Sheldon
Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot
Sheldon Cooper."

I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we
do it because we like it. There are a few perks but it mostly sucks. Also,
it's like living in "Idiocracy". I can't watch that movie because it's too
painful. _That 's my life._ From my point of view y'all are running around
pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's
getting seriously scary now IRL too: _where the fuck are all the fucking
insects!?_ We should all be fucking _terrified_ right now.)

Anyhow, from my POV the "average" programmers should GTFO and stop peeing in
the pool. I would fire 90% of working programmers. They're not needed and
actively counter-productive.

Also, FP is coming on stronger today than ever before. You are in actual fact
just wrong.

~~~
tabtab
Re: _" Anyhow, from my POV the "average" programmers should GTFO and stop
peeing in the pool. I would fire 90% of working programmers. They're not
needed and actively counter-productive."_

This is the theory that the elite are so productive that they can replace say
10 non-elites. The main problem with this is that most problems to be
automated (or upgraded) are not well-defined. It takes iterative interaction
with analysts, users, testers etc., and this is where probably 2/3 of the
effort takes place. Communication and teamwork is more of a bottleneck than
raw coding, and the Sheldon Cooper types rarely do well on that.

If the requirements were clearly defined, the 10x-Elite Theory would possibly
work in practice. But it's a rare day in May one gets a clearly-defined
specification that doesn't shift around a lot.

If you could find a domain having clearly-defined specs, then you could
implement that 10x Elite Theory and crush the competition by cranking out
software for a fraction of the traditional competitions' price. For example,
make an office suite fully compatible with MS-Office, and charge 1/2 of what
Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently
compatible, which may be a tall order because one has to mirror bugs in MS's
software to be so.)

~~~
carapace
I upvoted you because you're making good points, and graciously. Well met,
sorry for being cranky.

> This is the theory that the elite are so productive that they can replace
> say 10 non-elites.

No no no, I'm saying that the non-elites are counter-productive, that they
contribute _negative_ productivity.

(FWIW, I've met at least one "10x" in real life. He made his mark out of Uni
by co-founding a company that made their own self-configuring ("Autonomous
OS") box that really worked. Sold to IBM.)

> If you could find a domain having clearly-defined specs, then you could
> implement that 10x Elite Theory and crush the competition by cranking out
> software for a fraction of the traditional competitions' price.

People do that. Have you heard of Kdb?
[https://en.wikipedia.org/wiki/Kdb%2B](https://en.wikipedia.org/wiki/Kdb%2B)

Now check out arcfide's "AMA: Explaining my 750 line compiler+runtime designed
to GPU self-host APL"
[https://news.ycombinator.com/item?id=13797797](https://news.ycombinator.com/item?id=13797797)

Reflect that that was _two years_ ago.

Try to imagine what the world would be like if all core software was written
by ~100 people like Arthur Whitney or arcfide.

The whole "Trusted Compute Base" could fit in ~100 pages of code or less.
Crystalline _mathematical_ purity...

The rest of us would be writing macros. Sad? Maybe. But the machines would
work.

~~~
TimTheTinker
> I'm saying that the non-elites are counter-productive, that they contribute
> _negative_ productivity.

You may have concrete examples of that, but I couldn't agree based on my own
perspective/experience. I've worked on a team with an elite programmer (in
terms of actual 10x productivity) for nearly 3 years now. I know they're not
all the same, but this guy isn't particularly sophisticated or cerebral in his
approach; in fact, he wouldn't want to take on architectural concerns,
refactoring, or really complex problems - I and another dev take care of that.
He's just incredibly _productive_ , by any measure you'd like to use -- LOC
contributed, modules written, features implemented, issues closed. I've
sometimes wondered if he's a front for an entire team behind him.

That doesn't mean the rest of us aren't worth having on the team. We are
definitely contributing positively. In fact, he couldn't work anywhere close
to the rate he does if he had to take care of the stuff the rest of us do.

~~~
carapace
FWIW your coworker doesn't sound better than you, only faster. I wouldn't call
him a 10x programmer based on your description.

The kind of people I'm talking about are not necessarily fast and they tend to
leverage other people's abilities rather than shut them out.

Like Fabrice Bellard:
[https://en.wikipedia.org/wiki/Fabrice_Bellard](https://en.wikipedia.org/wiki/Fabrice_Bellard)

Ridiculously sharp guy, and his work has enabled so much other stuff and so
many other people, eh?

\- - - -

No team of ten people could do what arcfide does, eh? It would all get bogged
down in intercommunication, etc. We pay a _price_ for programming with sub-
elite programmers. Metaphorically, I'm trying to say that teams dragging stone
blocks are hindering the adoption of the wheel. (I'm not trying to make stone-
block-draggers feel bad, FWIW.)

