What can I only do in Erlang?

Funny, I recall some surprise in the community because Joe was asking some easy question about C for some glue code. It's been 5 years since I touched Erlang, only for learning, but is message passing style and the way you create functions like in prolog (or in Shen or picolisp) is unique and a great virtue. I know that tcl has secure interpreters, I wonder if there is such a think in erlang.

https://news.ycombinator.com/item?id=5451916

https://news.ycombinator.com/item?id=7943248

But there are more here and there if you hunt for them.

I think for things where they are sort of similar, Go will definitely be the more successful language because it looks so much more familiar and because it's moving faster with more momentum, at this point.

I'm using Erlang for a semi-embedded thing at the moment, though, where stability is more important.

That's not to say they can't inhabit a lot of the same areas, but Go's area of interests will probably remain somewhat separate from Erlang.

What I do see eating into Erlang is Scala and Akka, though.

On the other side of the coin, if I wanted to write a simple command line tool quickly that was easy to deploy to many servers, Go might be a great choice, where Erlang is a bit painful for small and simple programs.

Same as you'd likely do with Ruby or PHP or whatever.

Ruby is also slower than C++ & Go, But Ruby on Rails is not only popular but a very productive web framework which can help you build your app with a productivity that C++ or Go can't match.

When you write a high quality, fault tolerate system, the raw speed comes at the end. Erlang shines when you write a concurrent system plus its design is very unique. Erlang I would say isn't only a language but a whole philosophy of Software development. Once learned you can apply to many other platforms.

All in its a joy to work with functional languages and Erlang is perhaps the most commercially successful functional language.

I still haven't experienced a programming environment that replicates the Erlang/OTP environment. Period.

Haskell is amazing, I've built my company on it, but we're also building our company on Erlang - Haskell's tooling around distributed computing is much more immature than Erlang's (although Haskell's concurrency primitives and STM libraries are extremely mature and arguably better than Erlang's actor model).

Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for).

The decisions that went into C++ were for speed, and compatibility with C (and all that entails).

If you've got something truly resource intensive, yeah, you're going to need a lower level language. That's largely unavoidable. Erlang.org flat out states don't use it for number crunching.

I'd guess that 90% of what is programmed in the wild isn't that resource intensive. And given that, I'd go so far to say that most of what I've coded in Erlang is more performant than what I've coded in Java (haven't done enough C/C++ professionally to have useful data points). Why? Because the abstractions and conventions lead me to writing better code; the tooling lets me profile and find bottlenecks more easily, and even code I tweak for performance is oftentimes cleaner than it started, rather than more arcane.

Joe Armstrong, the founder of Erlang, is quoted in OTP in Action as (paraphrasing as I don't have it on hand) - "First, make it correct. Then, make it beautiful. Then, if you need to, make it performant. Chances are once you've made it beautiful you'll find it sufficiently performant". And that's been my experience with Erlang.

Try to look for something that works at scales you're interested in, break it down to its components and rearrange them into a simple architecture, then only can you consider performance. It turns out the lack of performance you feared at the beginning doesn't actually happen; in the meantime you'll have built a robust software (and, if you want to start the language, you'll have learnt a whole new way to program)

1) There are trade offs, sometimes you trade development time for execution time.

2) Erlang is "fast"/scales, ask whatsapp

3) A lot of people worry about execution but have enough spare CPU cycles to compute the universe.

4) Benchmarks mean nothing, you must figure out what is meaningful to you. You won't compare a ferrari and a minivan? Well, you could, but yet, find that a minivan is more practical for your daily needs.

damned lies and benchmarks. hipe enabled? VM tuned properly? attempt to use halfword emulator? comparing C++ the compiler optimized down to SSE2 instructions to an emulator VM loop?

How much slower is Ruby than C++? Ruby runs every startup in the world. This website is the home of "DO THINGS THAT DON'T SCALE" including using fast to write programming languages at all costs even if 3 months later their "we have modules for every occasion!" design will be inadequate (you are testing your _ideas_ after all, not programming language speed, at least of the majority of use cases for people on this site).

a good candidate for writing a distributed server

distributed means you need monitoring. monitoring means you need supervision. supervision means you need restart strategies or failover or other promotion mechanisms. all that is built into erlang for free. optimize for _reliability_ not for speed when creating distributed systems.

"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

One of the best kept secrets of Haskell, it can be very fast, supports multiple concurrency/parallelism options. The Yesod team does interesting performance work on the Warp server:

http://www.yesodweb.com/blog/2014/02/new-warp

That said, Erlang is really fast at things it was designed for. Try downloading Zotonic or some other Erlang app, get it running, and compare to others like Rails. Sharp, responsive, fast.

Erlang is not something you want to do for numerical crunching.

Erlang is for a very specific set of problems and it's concurrency.

For any numerical stuff you can off load it to other languages...

The fun fact is that most distributed systems don't really care about 7x slower too much. Those care about scalability, reliability and fault tolerance more. One of the most reliable software systems out there was written in Erlang and as far as I know, there are few system can match that sort of uptime[1]. There are few large scale systems in Erlang, including one Amazon AWS service[2], and bunch of others like WatsApp.

I also like to mention the VM that is pretty amazing. There is per process (not an OS process) garbage collection that enables Erlang to meet with super tight SLAs in terms of latency. Ideal for high scale websites, doing the routing, but also for moving data from A to B. The concurrency model is also one of the strongest features of Erlang. Message passing is very powerful and enables you writing asynchronous code that is still easy to read and follow. Go can match that probably with channels and go routines though.

If you care about single node performance you can either use NIFs[3] or if you not tied to Erlang chose a language that is focusing on that more.

1. http://ll2.ai.mit.edu/talks/armstrong.pdf 2. http://web.archive.org/web/20110623221347/http://www.satine.... 3. http://www.erlang.org/doc/tutorial/nif.html

C++ lets you write fast code.

Haskell is interesting.

If you want maintainable AND fast, have a look at Rust.

Just about any sort of web backend (that isn't having to do a whole lot of number crunching), any sort of interaction with hardware, handling/transport of binary data (as mentioned above), and of course any time you need reliability, it's worth considering.

But even in areas where there's not an obvious win, a lot of problems that are traditionally done in a single threaded manner can be made simpler in a concurrent language like Erlang.

An example I like to give is time based task scheduling. In a traditional language, you'd implement something like that with a priority queue. Which is fine, but you have a lot of work. First, what happens if timings change? You have to rejigger -everything-. What happens if you have multiple tasks at the same time? You need a threadpool or similar to dispatch these things onto. What happens if one task itself creates a new task for a later time? You'll have multiple people adding things onto the priority queue, so now you need to start locking. And of course, since you've got your dispatching process sleeping until the next task is to start, you have to make sure any time you modify the queue, you remember to notify that sleeping task, so it can update as necessary. There is a lot to get wrong.

In Erlang? You spin up a separate process for each task, with a timer. Done (with caveats; you likely will need to persist the task information and load it periodically into a task+timer process, but that's pretty trivial).

A similar case can be made for functional compared to a more procedural approach. That's a little too long winded for here, but even examples that seem -ideal- for OO, can oftentimes be described more simply in a functional, data-centric manner, and future refactorings are made simpler as well in doing so.

Even just a few seconds of network hiccup will throw it into a partitioned state, out of which you cannot reliably escape without manual intervention. There are also quite a few bugs that you tend to hit only when RMQ is exposed to network issues.

To use RMQ with bad networks, you need to use either the Shovel plugin or the Federation plugin. Both are somewhat awkward to use, and require manually setting up the different routes that copy messages across.

My advice is, if you like Erlang's architecture and need failure-tolerant IPC, just use Erlang directly. Don't use RabbitMQ for IPC if you need reliability.

I wish I could say better things about RabbitMQ, but it is easily the flakiest component of our stack. When you're used to rock solid server software like Postgres, HAProxy and Nginx, RabbitMQ is a big disappointment.

Another thing, tangentially related, which I've been thinking about lately: I'd love to do an apprenticeship with an old-school erlang hacker.. haskell hacker or lisp hacker who learnt the hard way in the field.

For me, this translates to: invest unpaid time for your employer to improve things, on the off chance that it will be accepted. I understand where he's coming from, but that borders on self-exploitation.

http://www.erlang.org/doc/efficiency_guide/binaryhandling.ht...

http://www.erlang.org/doc/programming_examples/bit_syntax.ht...

Erlang is really strong for that.

As to Java, sure, you can do anything with it, and do a decent job of it. But sometimes, as a startup, you are resource constrained, so if you can do more with less because you have a good grasp of a tool like Rails, or Erlang or Lua or whatever, that might make the difference. For a large company, Java is definitely a safe pick - no one ever got fired for choosing it: you'll be able to get whatever you need done, and "If we have to think a bit or throw some more kit at it, so be it." For a group like WhatsApp, Erlang seems to have been a good pick.

Not sure you read / understood what that point was about, due to its native binary types, tail recursion and pattern matching make dealing with binaries easier in erlang than most other languages

As far as most of the other points, you are mostly agreeing with the statement "nothing is impossible with other languages compared to erlang, but its better designed for this"

PHP does not so long process thread supervision (I mean it can but close to 0 people use it that way), Being able to inspect running processes is useful as well as the fact google is helpful, the JVM's entire ecosystem isnt based around a let it crash concurrent process isolation philosophy and java in particular is one of the worst offenders at having to ember error handling code at almost every point of your application logic

3. it's not only letting it crash, it's supervisors, restarts, cascading crashes when the parents retried enought times. Yes you can do it in other languages, but in erlang it's already done and battle tested.

4. that's not supervision

7. in erlang sending a message to a process in the same cpu and in another server has the same syntax and it's the common way of building software, in other languages calling a method and doing a jms message are two different things that you have to deal differently.

8. I would add quick check to the mix, but yes, dialyzer is just a kind of progressive typing

2. Apparently you haven't worked with Erlang. The point here is you don't write much networking, you write message handling exactly in the same manner as you would for communicating inside the application, without any networking. 0MQ, WCF and JMS don't even remotely resemble the operation model for network connectivity in Erlang.

3? (Let it crash) And you needed to specifically design your application, including supervision (you do have it, right?). Erlang provides all that already.

4. You didn't get what supervision is about. It's about restarting process when it crashes, crashing all the related processes and aborting when restarts are too frequent.

> It's easier to get staff,

It's easier to get some staff, but it may be much harder to get good staff. Signal-to-noise ratio is very bad among Java programmers. And it's quite hard to find bad Erlang programmer once you find somebody who can write in Erlang (or learn it quickly).

It's not that Erlang provides one specific killer feature that makes it great choice. It's that Erlang provides plenty of nice things already built in, and all that sums up to a platform that one would want to use every day. You don't have good binaries syntax on top of JVM. You don't have good logging framework in standard JVM. You still need external libraries for sensible network programming. You have to design your application specifically to handle thread failures. You can't just spawn a thread for every request running and be done with the job. You don't have a distributed soft real-time database. And the list goes on.

You just need to do much work before you even start programming, and then to manage all that (which is no easy task), just because your platform doesn't provide any of the mentioned things and its working model is less convenient for writing network services.

For example, having an receive expression and pattern-matching and simple typing (like everything is a term - self-evaluating or an expression or a list of terms) makes your code shorter, self-evident, easy testable.

Now let's look one level down. Pattern-matching on binary data (alternative to costly parsing) is so quick that in OTP they do matching on TCP packets in real-time.

Conversion from terms to binary and back is also quick. So the the "central idiom" - message-passing - is just sending and receiving a list of terms (atoms) on a language-level (guarded pattern-matching, like on function arguments) while messages will be encoded into efficient binary form and delivered by Erlang's runtime.

Again, almost everything in Erlang fits together pretty well because it is layered system founded on proper principles and design decisions. Immutable data, share-nothing process isolation, light-weight processes, common and simple data-representation format based on simple types, pattern-matching on everything, etc.

It is almost like industry-strength Lisp system - a few layers of DSLs, using which one describes the real-world abstractions on different levels on different sub-languages (based on special forms and function composition).

gen_server is the most common example of such kind of "vertical" decomposition. You have to write only "pattern-matching on receive", while lower layers of abstraction (encoding, protocols) and upper levels (process supervision) are clearly separated with proper abstraction barriers.

Of course, it is possible to code something like this in Java, but there are the subtleties. GC for mutable data could not be as efficient as one for immutable data. No mutable state, no sharing, no locking, no problem. These aren't just slogans.

So, Erlang is a small language designed around proper concepts. It "wins" not only in terms of lines of code, but in efficiency, resource usage (Erlang runs on 16Mb RAM).

I could go on, but I hope the idea is already clear. It is not a "list of features" what matters, but which ones we have and especially don't have, and how they are fit together. In small mostly-functional languages like Lisps or Erlang or ML-family they fit perfectly.

http://www.erlang.org/doc/man/gen_server.html

The difference between having such goals stated during the design phase and then keeping sight of them during all future development and say you forcing a thread to crash in the JVM is that in Erlang this is the way to do it, in Java you're going to have to re-implement your supervisor and clean-up yourself. And you'll probably get it subtly wrong.

Erlang is not a bunch of features that you can get elsewhere, it's an integrated whole on a very solid foundation with decades of proof of reliability behind it.

I would love to know your thoughts on this.

That comment is just about the exact definition of the blub paradox.

When presented with a more advanced idea, there's no underlying context to join the discussion, so the brain jumps to what it "already knows" instead of a more advanced concept of what's actually being talked about.

> 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.

In all spoken language (as well as computer language), context is king, so we all knew what the title meant, your sandpaper notwithstanding.

If the author was trying to ask "What does Erlang force me to do?" then he would have written that.

OTOH, the actual phrasing here, while awkward, doesn't, to me, present the interpretation you offer of "What does Erlang force me to do?" -- indeed, there's no simple way of keeping the basic structure and moving "only" in that sentence to get that meaning (the closest sentence I can see which can communicate that meaning is "What is/are the only thing/things I can do in Erlang?")

That's not to say its not both awkward and ambiguous -- "What can I only do in Erlang?" -- even absent context -- is hard for me to read as anything other than an awkward phrasing of either "What can only I do in Erlang?" or "What can I do only in Erlang?", the latter of which is apparently the intended meaning, the former of which asks about the authors unique strengths in Erlang that aren't equalled by any other programmer.

I would use Erlang for anything I would have used Node.js for and I haven't touched Node.js since I've learned Erlang (and Elixir).

- Erlang allows both CPU and IO concurrency.

- Like Node.js, all I/O in Erlang is non-blocking. The difference is that in Erlang your code looks synchronous. There is no callback/promise/whatever sewage all over your codebase, the Erlang VM and its schedulers take care of that for you.

- Messaging is built directly into Erlang, so communicating across OS processes, and within processes, is trivial. In Node.js you have to implement this yourself and will screw it up.

- Node.js doesn't give you any tools for fault-tolerance or distribution, Erlang is best in class for this.

- Erlang has pattern matching and tail recursion. This helps you create much more concise programs than JavaScript does.

- Because Erlang is CPU concurrent and Node.js only offers I/O concurrency, Erlang programs are incredibly consistent in their response times. In Node.js, as your programs grow and take up more CPU time (thus blocking the event loop) you will notice your 99th percentile response times are way above the average.

If I have to build a distributed system, I will pick Erlang/OTP over Haskell any day.

Everything in Haskell is wonderful, including concurrency. It does not have a built in DNS system (for node discovery and connection), inter-node RPC in Cloud Haskell is a joke compared to Erlang, and many other issues.

I've built systems where I used Erlang as the distributed "coordinator" and Haskell for on the machine computing.