
Why Not Erlang? The Lack of Onramps - ibgeek
http://discretestates.blogspot.com/2014/06/why-not-erlang-lack-of-onramps.html
======
88trh
Is anyone else extremely bored of the "why you/I shouldn't use Language x"
blog posts.

If people spent as much time contributing to their programming language of
choice, rather than writing about why they don't use competing languages -
well, that sounds like time better spent to me?

------
jw2013
While I do agree there should be less "activation energy" for the newbies to
enter the Erlang community
([https://www.youtube.com/watch?v=Djv4C9H9yz4](https://www.youtube.com/watch?v=Djv4C9H9yz4)),
I don't think "identify ways to expand the scope of Erlang and Elixir to other
potential use cases" is the way to go. Each language has its strength and
weakness, being highly concurrent and fault-concurrent is the design goal of
erlang/elixir, and erlang/elixir achieves that. Making them a general-purpose
language seems a bad idea to me (think message-passing a large size of message
in a non-concurrent situation where the shared-memory should be used. it just
deteriorate the performance of the general-purpose program). Being able to
built a great concurrent system is enough to make a language become popular in
industry, the problem is really not about more use cases, but is how to make
the barrier of entry lower. Also, it does matter to have a warming community,
like most of Ruby communities I know.

~~~
jacquesm
The last thing Erlang needs is to be overrun by a million wanna-be
hotshots/ninjas/cut-and-paste programmers. Erlang has a reputation and that
reputation is in part because by the time people discover Erlang they actually
need it.

~~~
thinkpad20
> The last thing Erlang needs is to be overrun by a million wanna-be
> hotshots/ninjas/cut-and-paste programmers.

If the message you're going for is "don't sacrifice the goals of the language
to appeal to a broader audience," I agree. But I don't think there's much
value to be found in that kind of elitist attitude. Python, ruby, JavaScript
etc are powerful, fun, easy to learn, and _useful_ , and their wide adoption
has lead to them being higher-performance, having boatloads of useful
libraries, and improved them as languages. A language is not hurt by more
people using it, even if those people are "wanna-bes" (whatever that means).

~~~
davidw
"Languages have positive network externalities":

[http://www.welton.it/articles/programming_language_economics](http://www.welton.it/articles/programming_language_economics)

------
jtmoulia
> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to
> support general-purpose tasks.

After doing quite a bit of work with Erlang lately, this sentence jumped out
at me. Specifically, I think Erlang does have a breadth of libraries, but
they're not easy to find. I've had to pluck lone source files out of larger
projects, or depend on an obscure github fork since the original was
unmaintained. epgsql was a great example of this, though no longer thanks to
davidw's yeoman work [1]

Maybe not the right place to ask this, but would anyone be interested in
something like the Clojure Toolbox [2] for Erlang? I've always found having
that reference of libraries organized by task to be super handy when working
with Clojure.

[1] [http://journal.dedasys.com/2014/04/27/an-erlang-postgres-
dri...](http://journal.dedasys.com/2014/04/27/an-erlang-postgres-driver-
refurbishing-open-source/)

[2] [http://www.clojure-toolbox.com/](http://www.clojure-toolbox.com/)

------
optimiz3
Erlang doesn't look like it Just Works on Windows and Visual Studio. No
Intellisense? Productivity--. No MSVC build? Productivity--. It better be that
much better to sacrifice that much engineering productivity relative to it's
competitors.

In contrast...Node.js? Works. C/C++? Works. MongoDB? Works. etc. At least they
could pretend to make an effort.

EDIT: It's 2014, serious tools need to integrate into IDEs and support inline
development, debugging, and testing. It's ridiculous to be coding in simple
text editors that lack the ability to deploy and debug code on the fly. Save
that slog for live environments.

~~~
zaphar
So here's the thing. I keep hearing this over an over. And I recently started
a job where Visual Studio is is the IDE of choice working on C# code.

So of course I thought. I'll give VS a try. I don't know a whole lot of C# yet
so it'll be nice to have a tool helping me get to know the language and
stdlib. It only took me half a day to discover that VS which is arguably one
of the best IDE's out there beating out Eclipse and IntilliJ for useability
and responsiveness still suffers from the same problem all IDE's suffer from.

Poor isolation. I like to build my code and run tests frequently. VS locks the
whole UI when I do that. Building and running tests should be a background
task.

Say what you want about those of us who prefer our "simple" text editors with
our simple tools. But those editors and tools are composable in ways that get
out of the way and still gives us that lauded ability to deploy and debug code
on the fly you mention.

After my experience I immediately abandoned VS and set up OmniSharp with
emacs. Now I get code completion, error reporting, and even style issues
highlighted in my editor without interrupting my state of flow.

I'm still waiting for the IDE that can do that.

~~~
robin_reala
I’m with you on this one. I’m having to use VS for a current build and it
forces you down a one-way-or-the-highway approach. Sure, you can find
extensions that alter how it works a bit, but I don’t have the time to learn
how to write a VS extension. I’d much prefer the flexibility of a bunch of
small tools, each of which works well in isolation. I find VS extremely heavy
in resource utilisation.

I expect I’d be much happier if I could swap out the code editor for Sublime
as a minimum, but as I’m writing a bunch of LESS code I keep on having to jump
back into VS anyway to trigger a recompile.

------
mattdeboard
It's not fair to speak about Elixir & Erlang as a single piece of tech any
more than it is to speak about Scala & Java that way. Elixir targets BEAM, but
that doesn't mean it's anywhere near as mature as Erlang.

Elixir is on v0.14 or something. Far sub-1.0. It's a really beautiful
language, but it's not surprising to me it doesn't have a Rails/Django analog
when they're still introducing backward incompatible changes to the core
language.

Also I really have no interest in learning a language just to write yet
another website in.

~~~
chrismccord
We're working on full-featured Elixir web framework:
[https://github.com/phoenixframework/phoenix](https://github.com/phoenixframework/phoenix)

> Also I really have no interest in learning a language just to write yet
> another website in.

It depends on what you mean by website and what your goals are. What
Erlang/Elixir provide is distribution, fault tolerance, and concurrency in the
most straight forward way I've experienced coming from any other language. If
you're making brochure sites, it's not a compelling cost tradeoff, but if your
target is a highly concurrent, fault tolerant service that can be easily
distributed across 100s of servers, then it's going to be much harder to find
an alternative. Elixir 1.0 should be out later this summer. It should be a
smoother ride after that.

~~~
mattdeboard
By no means did I mean the version being sub-1.0 is a negative, just it should
serve as a signal to people about what their expectations should be like.

By web application, I mean, you know, I've got a full toolkit for putting &
serving stuff on the web. BEAM seems like it's better suited for web server
software, vice the db read/write/template rendering/etc. part.

~~~
chrismccord
Elixir/BEAM is a fantastic target for a full web application toolkit. We're
building just that with Phoenix. The ecosystem has a ways to go, but as a
community, we're just getting started.

------
donn
My biggest gripes:

• No public bug tracker. The erlang-bugs mailing list is not a substitute.

• Questionable releases — stuff like
[https://gist.github.com/chewbranca/07d9a6eed3da7b490b47](https://gist.github.com/chewbranca/07d9a6eed3da7b490b47)

These two things combined with a small community make me uncomfortable
depending on Erlang.

------
jsnell
It's not clear to me what "onramp" actually means here, since it's not defined
anywhere. Given the examples it appears to be something as generic as "a
reason to use the language", and the whole argument becomes pretty much a
tautology. Yes, of course most people will only use the language if they have
a reason to use it. Unfortunately that's not a very actionable insight.

Incidentally, I'm not finding some of those examples of "onramps" very
convincing. For example I would be stunned if a large proportion of current Go
users said that they're using Go because it comes from Google. That (and the
pedigree of the authors) might have gotten it some early buzz, but that's
unlikely to carry the project very far by itself. The trail of failed or
failing development tools from Google should be proof enough of that.

~~~
SoftwareMaven
People aren't _using_ Go because of Google, but Go gained a lot of attention,
and therefore a lot of people _looked_ at Go, because of Google. Google also
did a good job with developer outreach, which, IMO, is what keeps Erlang from
moving to the next level,

~~~
lazyjones
> _People aren 't using Go because of Google, but Go gained a lot of
> attention, and therefore a lot of people looked at Go, because of Google._

I chose to ignore Go initially because I thought it'd be yet another soon-to-
be-abandoned Google project and because I felt that a programming language
created by a large (unfocused) corporation doesn't have the best chances to
develop in the direction I'd like (yes, I know how C started...).

What got me interested in the end was a) well-known (to me anyway) developers
using Go and writing about it, b) the purported ease of learning, simplicity,
standardized formatting and resulting "fun", c) concurrency features (lacking
in many older languages).

Conclusion: it actually works to look at the needs / interests of influential
developers and create something that fits for them. As far as Erlang is
concerned, I believe too many of them have been put off by the syntax. Or it
mostly attracts people who do not talk about it much, for some obscure reason.

------
csmattryder
I know it's not full-on adoption, but one thing I noticed is that Erlang.org
lacks an interactive REPL on their website, instead opting to just post a
factorial demo[1] without really explaining it (akin to tryruby.org et al.)

A quick Google found TryErlang.org, which doesn't seem to be linked to the
official Erlang website.

I'm a lot more inclined to learn about a language if I can try it in my
browser without a download required. TryRuby.org was my first taster in Ruby
and here I am 2 years later.

[1]
[http://www.erlang.org/static/getting_started_quickly.html](http://www.erlang.org/static/getting_started_quickly.html)

~~~
colanderman
Erlang-the-language, as in what you can do from the REPL, is wholly non-
interesting. It's a very basic functional language with message passing and
process linking. The message passing and process linking are rather awkward to
use from the REPL, leaving you with just a basic functional language.

Erlang-the-platform (i.e. OTP) is what's interesting. You can't really make
OTP applications in the REPL, they consist of several modules with actual code
requiring a modicum of forethought and design.

(Something more-than-a-REPL could be interesting, which helps you create an
OTP tree complete with skeleton code. But at that point you're pretty much
asking for a web-based IDE, and the prospective developer still needs to
understand how to structure an application as processes.)

------
dschiptsov
Not Erlang? Facebook? Whatsapp? Leave alone all that Ericsson GSM hardware..

~~~
general_failure
Are you saying Erlang is as successful as rails, node or django?

The notion of success is quite relative anyway when it comes to subjective
things.

~~~
dschiptsov
Comparing to PHP Rails is an enormous success, but comparing to J2EE it still
has something to catch up.

As for node, I doubt that it is a "success". _For me_ it is just a product of
Javascript "sectarian hype" along with cumbersome design decisions.)

The principles and desing decisions behind Erlang are well-researched and
"robust". Details are in armstrong-thesis-2003.pdf

~~~
general_failure
That's interesting. To me, J2EE is a pic failure in turns of developer
enthusiasm (might be considered successful because of usage). I am yet to meet
a developer who likes to code in J2EE and they would take every opportunity to
jump ship to just about anything. That said, mine is a startup world and
nobody I know writes new code in J2EE.

------
CmonDev
It is simply not a general purpose language (practically speaking,
theoretically of course it is). How many hoops do you need to jump to build a
native feel mobile app on major mobile platforms? Scala might be not perfect
for this as well, but somehow feels more realistic.

------
616c
I am curious why iPython-like tools are not possible in Erlang. As far as long
you have a REPL, is that not a solid base to start an iPython like project in
any language?

(Notice I said base, not the whole enchilada; I recognize that would be going
too far.)

~~~
rdtsc
The first hurdle is that Erlang works on modules by default. Those are
expected to be compiled from a file. Now Elixir fixed that problem. For
Erlang, it is probably doable via a compile-reload cycle hack. I guess it just
hasn't been a priority. Maybe it should be...

~~~
derefr
Modules don't need to be compiled from files; there's just no batteries-
included "eval these lines into a module" by default. But it's not hard:

    
    
        parse_form(Form) when is_list(Form) ->
          {ok, Tokens, _} = erl_scan:string(Form),
          {ok, AST} = erl_parse:parse_form(Tokens),
          AST.
    
        load_module(FormStrs) ->
          FormASTs = lists:map(fun parse_form/1, FormStrs),
          {ok, ModName, ModBin} = compile:forms(FormASTs),
          {module, ModName} = code:load_binary(ModName, "nofile", ModBin),
          {ok, ModName}.
    

Note that even an "anonymous" module must have a name, to serve as a handle
for the VM. But you can do something like:

    
    
        gensym() ->
          {MT, T, UT} = erlang:now(),
          io_lib:format("~p_~p.~p.~p", [node(), MT, T, UT]).
    
        load_anonymous_module(FormStrs) ->
          ModNameFormStr = lists:flatten("-module(", gensym(), ")."),
          load_module([ModNameFormStr | FormStrs]).

------
rdtsc
> The Erlang/Elixir language is not ideal for projects requiring lots of data
> manipulation, math, graphics, or low-latency performance (games).

It is not. Erlang is not the best tool for fast math and data crunching. Now
it could supervise and feed data to a specialized data cruncher.

There is Wings3D, a subdivision 3D modeler, but that is kind of an exception.

> Python is easy to get started with, [...] especially due to its ability to
> easily integrate with C.

Erlang can also integrate with C. Granted not in ctypes or ffi type way, but
with Python C-extension like way. It is not that bad. There are good examples
of c libraries integrated that way (LevelDB for example, JSON parsers, etc).

> None of these are strong areas for Erlang/Elixir, but they are for Python.

Python is a great language. Use Python, why try to force yourself to not use
it if you know and it works great.

> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to
> support general-purpose tasks.

Erlang has been used for a wide variety of tasks. From messaging systems, to
databases, to controlling hardware, to running websites, streaming video,
real-time bidding systems, very large file storage back-ends, message brokers,
chat systems, presence systems, game "lobby" services. Payment systems. The
list goes on. In this sort of "concurrent and reliable backend systems" domain
it solve quite a bit of general tasks if you wish. It can certainly open
files, match patterns on binary data, talk to databases, send data over the
networks.

> I'm starting to become interested in Scala. Why? My new job at Red Hat
> involves working with and hacking on software built in Java and Scala

Well presumably could have interviewed with Baho, Tail-f, Klarna. It sounds
the author wants an excuse to use Erlang or Elixir, it seems applying for jobs
that will lead to using those technologies might help with that.

> In my mind, if Erlang and Elixir want to grow, the community needs to
> identify ways to expand the scope of Erlang and Elixir to other potential
> use cases so that there are a larger number of natural onramps.

Agree with that. It seems there is repeated mention of ipython. Wonder if that
is what is needed. Some kind of a shell with easy commands for saving and
sharing modules and code. A lot of stuff ipython does recently with
distribution and connecting to other nodes and so on is already baked in.

Heck someone even started one such project not too long ago (I just found it
via a quick search).

[https://github.com/robbielynch/ierlang](https://github.com/robbielynch/ierlang)

Maybe that is what's needed?

~~~
derefr
> It is not. Erlang is not the best tool for fast math and data crunching. Now
> it could supervise and feed data to a specialized data cruncher.

This needs to be emphasized further. Erlang is a platform for building
distributed systems. In a distributed system, you don't have your state
management and your heavy IO/computation occurring in the same process. They
aren't usually even co-located on the same _machine_ , where there would be
any chance of them competing for resources.

Instead, in a well-engineered distributed system, you have a _control plane_
which makes lots of branchy decisions based on command/query-like input, and a
_data plane_ that sits working on long tasks (e.g. computing results,
streaming IO) until the control plane tells it to stop.

Erlang is a platform for writing control-plane software. It gives you plenty
of tools (NIFs, ports, C-nodes, simple binary protocol parsing) to write data-
plane software to integrate with it, but it always implicitly expects the
control-plane/data-plane separation.

What does this mean for using Erlang to power, say, a GUI client application,
or a 3D game? It means that you don't try to cram your fancy GUI rendering
into the Erlang emulator's process-space, or vice-versa. Rather, the GUI acts
as a client, Erlang acts as a (local) server, they communicate over a socket,
and each process gets to keep its event loop in a sane state.

My "secret weapon" in rapid native-client application prototyping right now is
an atom-shell client that ships with an embedded Elixir node. Node.js starts
up, spawns the Erlang VM, connects to it with plain TCP, and then opens a
webview which connects to it again over HTTP. The web-view becomes basically
an extremely fancy, scriptable TTY for the Erlang VM to read from and write
to, while Node.js is doing more high-level non-sandboxed interactions over the
regular TCP socket.

~~~
MartinMond
That Elixir / atom-shell integration sounds awesome. Any chance of open
sourcing (parts of) it?

~~~
daniel-levin
Seconded. I'd also like to get my hands on it.

------
AceJohnny2
s/onramps/killer app/

But I guess the latter is overused and diluted, and the former is the new cool
term.

~~~
mononcqc
Killer Apps may include: CouchDB, Riak, Whatsapp, RabbitMQ, Amazon SimpleDB,
etc. You can also go for specific companies that are using it like telco stuff
(Ericsson, T-Mobile, Motorola), Yahoo, OpenX, Huffington Post, Amazon, and so
on.

~~~
general_failure
I just picked a random file in RabbitMQ to see how erlang looks like -
[https://github.com/rabbitmq/rabbitmq-
server/blob/master/src/...](https://github.com/rabbitmq/rabbitmq-
server/blob/master/src/file_handle_cache.erl)

Then I thought of looking into something I might understand:
[https://github.com/apache/couchdb/blob/master/src/couchdb/co...](https://github.com/apache/couchdb/blob/master/src/couchdb/couch_btree.erl)

The syntax is indeed scary. Unless erlang provides features that are
overwhelmingly compelling that I just cannot live without, I cannot imagine
coding in it. Go seems more approachable.

~~~
SoftwareMaven
s/understandable/familiar/

Go is based on C, so of course it is more familiar to many people, as most
popular languages share that root (something for language designers to at
least ponder). Lisps are hard to follow, too, if you aren't familiar with
s-exp languages. If you had a prolog background, Erlang wouldn't feel nearly
as overwhelming.

The hardest parts about understanding Erlang programs, IMO, are understanding
message passing (already there with Go), supervisors, and managing state in a
stateless system (the latter two aren't what I'd consider common idioms in
other languages (though supervisors are easy to reason about due to operating
systems). Understanding the syntax is something a short afternoon can resolve.

~~~
forgottenpass
No idea at all why you're downvoted. I came to erlang after spending years
working on a C++, actor model, message passing codebase. Unsurprisingly
(although it was to me at the time) I felt quite at home.

The difficulty came from the new syntax and Erlang-style control flow. And as
you say, those are entirely a matter of familiarity. I still find python to be
more readable and writable, but by no means does that imply Erlang is not
understandable.

------
mantraxC
People who need Erlang, know about Erlang and don't need "onramps". Dumbing it
down hasn't been necessary for Amazon and Facebook to adopt it, among many.

Not every bicycle is intended to be driven by toddlers, so not every bicycle
needs mounts where you attach the training wheels.

