[erlang-questions] What can I only do in Erlang?

[zxq9]

Hi Curtis,

Anything can be done in any language, so the technical answer is "nothing". 
But the spirit of the question begs for an answer, especially in a company 
situation with deadlines.

My company does mostly business data systems and custom extensions to certain 
products of ours. Originally we used a mix of Python (probably 70%), PL/pgSQL 
(maybe 10%), Guile/Scheme (probably around 10%), C (5%ish) and a smattering of 
Bash, Perl, Scala or Java, etc. where necessary. I am extremely familiar with 
Python and Guile, and between those two a one-dimensional solution to any 
conceivable problem can be reduced to triviality. They are great languages. 
They have great libraries. They tie into the rest of the *nix world smoothly. 
Super tools, *vastly* superior in every way (for us) than more prolific tools 
such as Java.

But when it came time for us to deal with some new feature requests -- like 
internal chat + whiteboard utilities that tie directly into company 
dashboards, message systems that can't go down (outside of an earthquake or 
something), and meshing Android, iOS, Windows and Linux native clients 
together... Doing everything in the web wasn't cutting it for various reasons 
and most importantly: The way we wanted to solve our problems required that we 
write a service management layer.

A service management system is *not* something you just do over the weekend. 
Its a big deal. The APIs to it from various languages can be wonderful or they 
can infect every subordinate project with cancer. This stuff just isn't easy.

Luckily, pretty early on in the design phase I started looking around at 
alternatives and remembered Erlang and how easy it was to do certain things. I 
can back to it, toyed with it a bit, and in a few weeks wrote stub examples of 
the sort of things we wanted to do the way we had always wished were possible. 
And I didn't have to write any service layer. The Erlang environment is its 
own service layer. We *could* have been like Google and written our own at 
great expense, but it turns out that's simply not necessary.

We still do a lot of Python (client-side), Scala (Android) and Guile 
(internally), but almost the entire world of business logic, network services, 
messaging systems, and just about all other back-ends for anything that 
involves the network is either in Erlang or will soon be. Its just a lot 
easier.

Why?

Binaries: I can't explain how much easier it is to deal with binaries in 
Erlang than C. This alone is reason enough to swap all your network code. In 
particular, if you deal with sockets at all, Erlang is probably the right 
tool.

Sockets: In addition to the comments above about handling the data once you've 
received it, writing "from scratch" socket handling code in Erlang is easier 
than using any socket libraries I've dealt with. Especially with regard to 
cleanup when something goes wrong.

ASN.1: Cryptographically validated (signed, encrypted, whatever) data 
structures are usually easiest in ASN.1, and Erlang has *great* facilities 
here as well.

"Let it crash": Its not about being lazy or inviting instability, its about 
writing code that only deals with the problem, instead of inventing 50 other 
problems in the form of data validation everywhere. Here your error code and 
your core problem-solving code are clearly separated from one another, and 
that means you can identify and factor out similarities in them independent of 
one another. Once we understood this, our code got better and much smaller.

Supervision: Automatic restarts to a known state. Wow. Limiting how bad things 
can get is amazingly powerful. But you won't realize this until you screw 
something up really bad, and then realize how much worse it would have been 
without a supervision tree helping you.

Inspection: IBM's JVM has some pretty amazing tools for inspecting itself 
while running and great crash and debug tools. Awesome stuff. Erlang's are even 
better. This takes time to learn your way around, though, at least it has for 
me. At the very simplest end of things, though, go start an Erlang shell and 
type "observer:start()". If you guys write any server software at all, doing 
this during a presentation should be convincing enough to get other folks in 
your company curious (might not be strong enough to sell them on it unless you 
demonstrate monitoring of remote notes that are doing interesting things live, 
but it should definitely get them interested).

Messaging is not RPC: This is probably not an idea you can easily explain in a 
quick presentation to management, but the way Erlang enforces this distinction 
is important. It means you don't have to change the way you think when you're 
messaging between Erlang processes and when you're networking messaging over 
sockets to non-Erlang things. Because binary data is easy in Erlang the 
difference between network traffic and process-process traffic (which may involve 
the network, but its invisible to you) melts away because you don't get 
distracted for weeks writing heavy duty network code and then turning back to 
your comparatively trivial problem.

Dialyzer: I haven't seen a better middleground solution to type checking in a 
dynamically typed language than this. The real utility of it comes once you 
learn to concentrate your side-effecty code in small, specific areas, and mostly 
write purely functional code. You can't "verify" your programs, maybe, but you 
can verify a function at a time and have a very high degree of confidence in 
most of your code -- and almost never have to revisit large parts of it in 
maintenance.

...and a long list of other things. Oh yeah, concurrency... its really easy in 
Erlang, but I assume you've heard.

What can you *do* in it? You can avoid writing your own service framework. All 
the applications frameworks, service layer frameworks, and nearly anything 
else with the word "framework" in it are attempts to re-write OTP in other 
languages. We were doing this in Python without realizing it.

Handling binaries ("How can we make validation easy?"), handling sockets ("how 
can we make this easy?"), segregating failures ("how should be isolate these 
services as processes?"), isolating data ("where do we need to deep copy to 
make sure we're not screwing ourselves elsewhere?"), restarting components 
("we need a list of services and known states so we can restart stuff when it 
dies..."), multi-processing ("what approach to pooling do we need and how 
should the processes talk across each other?") and a slew of other service 
layer type issues are just non-issues in Erlang. These problems are usually 
harder to solve than the business problem that faces you to begin with. Having 
that taken care of is great.

So its not about what you can "only do in Erlang", its really more about what 
you don't have to do in Erlang.

This is my feeling based on my experience dealing with business software. I 
don't know what your case looks like, but for us it eliminated the need for a 
whole category of work, and that was a *big* win. It didn't eliminate all 
other languages, but it gave us the freedom to focus only on the problems 
those languages are good for once again.

OTOH, Erlang involves a longish learning process. As your development team 
learns you will notice a distinct change in coding style their first few weeks 
and a year later. There are several evolutions to understanding the natural 
way of solving certain problems in Erlang, and OTP is, in my view, its own 
distinct family of Erlang (and usually the right one). In any case, your 
early, naive implementations of services in Erlang will be at least as robust 
(from an external observer) as "proper" implementations in other languages 
would be, so there is no loss there. As you learn, though, things get better.

One parting thought: Erlang's VM can be used by several languages. My personal 
favorite is Erlang itself, but just like the JVM, Erlang it its own ecosystem 
and you don't have to marry just one language. Some types of problems may be 
ugly to read in Erlang but quiet elegantly expressed in Elixir or Lisp 
Flavored Erlang. I can't stand Java, but Scala is decent and Clojure is 
wonderful -- its not about the syntax, its about knowing your platform.

I didn't answer your question or give you a 10-line demonstration of how to 
solve the question of Life, the Universe and Everything. Hopefully this gives 
you some points to think over when discussing the issue with other developers 
and management.

As for encouraging adoption, I recommend you solve a problem in your spare 
time that your company has, in Erlang, and demonstrate how easy it is to 
maintain compared to whatever the accepted solution being worked on is. That's 
a lot safer thing to your management than "throwing money at a new toy, hoping 
for a payoff". Incidentally, this approach will yield a lot of insights about 
comparative software and personal revelations (perhaps not just to you) about 
how your company's leadership thinks and make decisions. If you pick your 
battle (and sample problem) wisely, it could turn an adversarial situation 
into an all-around win.

(from: "Must convince them! If they say yes I'm happy but panicked to make the 
pig fly and they are wary of anything smelling sour. If they say no I'm 
frustrated at how short-sighted The Man is and they are worried I'm looking 
for an early exit."
to: "If I can demonstrate a better solution that saves them on an ongoing 
development cost I look great, they save money, and we all appreciate a new 
tool.")

Just my $2.

-Craig

On Tuesday 04 November 2014 16:18:12 Curtis J Schofield wrote:
> I am working on getting Erlang/Elixir adopted into our company. I've
> been asked to provide a simple example of something that your can only
> do in erlang.
> 
> My reason for pushing to adopt this in our tech stack is that much of
> the system code I've written I feel I could write easier in Erlang and
> do it faster. I feel like one of the unique offerings of erlang
> relates to distributed computing or OTP reliable systems.
> 
> 
> Does anyone have thoughts on this question ? "What can I do in Erlang
> that I can't do in another language?"
> 
> Ideally it would be something small that I could use as a demonstration.