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

[Duan, Xiande]

Pretty great sharing! thanks.

-----Original Message-----
From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of zxq9
Sent: Wednesday, November 5, 2014 9:57 AM
To: erlang-questions@REDACTED
Subject: Re: [erlang-questions] What can I only do in Erlang?

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.

_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions