Guy Wiener

I’ve returned last week from EUC’2009. My conclusion: If programming languages were stocks, and if I were a market advisor, I would put a “strong buy” recommendation on Erlang. If you have some spare “programming language money” (that is, the time and patience to learn a new language), put it on Erlang. It would be worth your while. Here are some reasons why:

Continue Reading »

Mayer and mine work on self-application in Erlang is going to be presented on the Erlang User Conference 2009. Here is the full teaser:

Most servers and clients in Erlang are implemented as named procedures in named modules.  Similarly, processes communicate via named messages.  This exposes and fixes a great deal of information about an Erlang application: The names of the modules, procedures, messages between servers and clients, etc.  This talk explores how to gain anonymity through the use of anonymous higher-order procedures.

To spawn a process on a node, one must either to use a module name and a function, or to pass an anonymous procedure.  In order to use a function from a module, the module file must be available on the remote node.

For a server to receive many messages, the spawned function must be recursive. Recursive functions are typically implemented in Erlang via a name in a module. Running such a server requires that the client be aware of the names of the module, function, and messages.

Functional programming languages (such as LISP, Scheme, and Erlang), permit recursion to be replaced with self-application, which means functions that are applied to themselves.  This is a classical technique from functional programming.  In Erlang, this technique adds flexibility, anonymity and security.  Specifically, we demonstrate how to

• Spawn a fully-functional server without requiring shared modules or access to  the file system.
• Have client-server groups that take the message names as arguments.
• Use random and constantly-changing message names.

See you there!

I’m a programmer. As such, it always shock me to see something that just works. That was my feeling when I managed to run Erlang’s pool module. The setup requires some attention, but after that, it’s insultingly simple.

To run an Erlang nodes pool, you need the following:

Continue Reading »

After learning 15 or so programming languages, in different levels of proficiency, I don’t tend to get excited about a new programming language. Moshe occasionally sends me links to the project websites of new languages. I usually reply that “If you know you’re OOP, you don’t need 5 extra levels of fluff just to get things done”. One of his links, however, hit the bullseye: Erlang.

Erlang stands out in the landscape of new programming languages: It’s a pure functional language. Yes, you’ve read it right: Pure. No pointers, no shared memory, no side-effects. If you want something stateful in Erlang, you have to use special libraries.

Erlang, however, is not an academic language. That radical design derives from very practical reasons. Erlang was designed for a single purpose: To support concurrent, distributed, fault-tolerant systems. Anything else in Erlang derives from this goal. Since that many bugs in distributed systems are caused by shared resources and other mainstream-languages imperative features, the designers of Erlang simply threw them out. You can’t code a casting error in ML, and you can’t code a race condition in Erlang.

Continue Reading »