Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programming Erlang

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

Book Reviews 314

gnalre writes "Every day it seems there is a new publication of a book on perl/python/ruby. Some languages however do not seem to get that sort of attention. One of those under-represented languages is Erlang, however for the first time in 10 years a new Erlang book has been published. As someone who had a brief flirtation with Erlang long ago, I was interested to see how the language had evolved in the intervening decade. I was also curious to re-evaluate Erlang to see what solutions it offered to the present day issues of writing reliable distributed applications." Read on for the rest of Tony's review.

Programming Erlang — Software For A Concurrent World (ISBN 10193435600X) is part of the pragmatic programmer series. As with all the books in this series, it is available in paperback or for a reduced cost you can directly download it in PDF format (which is always useful if you spend a lot of time on the move and you do not like carrying around a dead tree with you). The book's format and layout as with all the books of this series are clear and logical.

The book is written by Joe Armstrong, who co-authored the first Erlang book a decade ago. He was also one of the originators of the Erlang language and has been directly connected to its development ever since. We can therefore be assured about the author's knowledge and insight into the language, if not his impartiality.

The book itself can be roughly split into three main sections: Getting started and Sequential programming, Concurrent Programming and Erlang libraries and advanced Erlang techniques.

In Chapter 1 the author sets out his stall of why Erlang is worthy of your attention. It's clear from this chapter that the author feels Erlang's strength lies in applications requiring an element concurrency and fault tolerance. Another emphasis is made of running Erlang on modern multi-core processors, something that was only a glint in a hardware designer's eye 10 years ago, but is rapidly becoming an issue in all areas of programming. From this chapter you also get a feel on how the author approaches his programming in that he states that he wants the reader to have fun with the language, which is a refreshing change to some language text books whose main purpose appears to be as a cure for insomnia.

Chapter 2 goes through installing Erlang and the Erlang shell (a command line environment similar to ones with languages such as perl). The chapter also starts us into the strange world of functional programming, where variables can only be given a value once (e.g you cannot do i=i+1), recursion replace loops and pattern matching replaces assignments. Fortunately the Erlang language is remarkably concise. For example there are only 4 data types. However to those coming from a purely procedural programming background the learning curve could be a steep one. Saying that the Author does a good job of leading you through the languages intricacies with examples being compared to code from languages such as Java to help keep your feet on solid programming ground.

The next 3 chapters move on to writing simple Erlang programs. As a quick aside, for anyone new to Erlang it is well worth examining the quicksort implementation described in chapter 3. Its conciseness and simplicity was one of the reasons the language won me over when I first met the language.

These chapters also cover error detection and handling. It's worth noting that Erlang has a philosophy of ensuring programs fail hard, so that bugs can be weeded out at an early stage. This idea very much defines how Erlang error handling is defined.

One criticism of the first section is Chapter 6, which describes compiling and running an Erlang program. I would have preferred that this information be covered earlier in the book or be placed in an appendix because it is probably an area you will want to reference repeatedly.

Chapter 7 is where things really get interesting and the true power of Erlang starts to come to the fore. This is where Erlang's concurrency credentials are explained. This chapter begins by providing some useful metaphors of the Erlang concurrent model, but chapter 8 is where the fun begins by describing the Erlang concurrency primitives that allow the creation of processes and the process communication methods. The author here highlights one of the language features, the Erlang light weight process. These are true processes (not threads) but take up very little in the way of resources. Indeed it is not unusual to have 1000's of such processes running in an application.

The next few chapters expand on the available concurrency primitives and how to move from concurrency on your local processor to concurrency utilizing the resources of multiple machines either on a local network or across the web. It finishes the section off by showing the example of a simple IRC application.

Chapter 12 starts the next section by looking at how to interact with the world outside the Erlang environment. First it examines how to interface an Erlang program to applications written in other languages such as C. It then goes onto to look at file and socket handling in Erlang. Chapter 15 looks at two important Erlang storage primitives ETS and DETS before we get to the OTP Erlang libraries in Chapter 16.

The OTP libraries are the standard Erlang libraries and tools. In fact the OTP libraries are worthy of a book in itself. The author highlights the section on the generic Server module as the most important section in the whole book and one to be reread until its importance has sunk in. This is because here are encapsulated many of the lessons learned in writing industrial fault-tolerant applications, such the updating of a running applications code without causing that application to miss a beat. The section is finished off by describing the Erlang distributed database (humorously named Mnesia) and then finishing it off with the example of a simple server application.

The book finishes off by looking at Erlang on multicore systems including its support for SMP. As the author states this is the leading edge of present day Erlang and is still under development.

I would like to thank the pragmatic programmers for publishing this book. Erlang's profile has been in need of highlighting for many years and hopefully this book will help. The book definitely provides a great starting point for anyone who wants to get to grips with the language and takes them to the point where they can start writing useful applications. This book is a worthy successor to the last book published and does a good job of both updating the material and explaining some of the later developments such as SMP. Anyone who has a need for writing fault tolerant applications should at least look at this book. If nothing else you will never be afraid of dealing with recursion ever again.

In many ways the book cuts off just when things are getting interesting. There are hints in the book about real world Erlang's applications and it would have been good if some of these experiences could have been expanded. Hopefully this book is the start of increased exposure for Erlang. If so then someone may get around to writing another Erlang book describing some of the advanced issues about generating robust applications. I just hope it won't take another 10 years this time.

Tony Pedley is a senior engineer specializing in real-time embedded systems. In his spare time he likes to tease windows programmers and confuse managers by telling them it would be a lot easier if we wrote it in Erlang.


You can purchase Programming Erlang - Software For A Concurrent World from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

314 comments

Sorry! There are no comments related to the filter you selected.

Can you say (0, Offtopic)

hax0r_this (1073148) | more than 6 years ago | (#20483279)

Dupe?

Re:Can you say (0, Offtopic)

hax0r_this (1073148) | more than 6 years ago | (#20483321)

Ok, I can't find it, but I would swear to my nonexistant god that this was posted about a week and a half ago.

Re:Can you say (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#20483433)

I thought the same thing.

Maybe it was something I saw in the firehose as I don't remember reading any comments.

Darn firehose (0, Offtopic)

zeromorph (1009305) | more than 6 years ago | (#20483645)

Me, too.

...usually a glitch in the google grid. It happens when they change something.

Try it out (5, Informative)

romiz (757548) | more than 6 years ago | (#20483307)

The first chapter [pragmaticprogrammer.com] is avalable online to get a taste of the book (and the language).

Re:Try it out (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#20483475)

A PDF version on the book is also available on http://www.mininova.org/get/808452 [mininova.org]

I downloaded it last weekend, and I must concur with the reviewer.

apropos erlang (Go Sweden!) (2, Informative)

Jhan (542783) | more than 6 years ago | (#20483481)

The Ericsson Language, for those who have not been exposed to it, is a programming language meant to make concurrent (multi-process, multi-processor, multi-machine) programming really simple. It's used on many AXE telephone base stations world-wide. It has great message-passing support, and a pretty nice library. It is actually not a functional language, but a logical one. Basically a perverted version of Prolog.

Re:apropos erlang (Go Sweden!) (1)

MenTaLguY (5483) | more than 6 years ago | (#20483599)

Erlang is a functional language with prolog-style unification for pattern matching, just like one sees in ML or Haskell.

Re:apropos erlang (Go Sweden!) (1)

poopdeville (841677) | more than 6 years ago | (#20483723)

The distinction between a functional and logic programming language is merely syntactical, due to the trivial characterization of functions in terms of truth functions (and truth functions in terms of functions).

Re:apropos erlang (Go Sweden!) (1)

Jhan (542783) | more than 6 years ago | (#20484977)

...trivial characterization of functions in terms of truth functions (and truth functions in terms of functions)

First: I was completely wrong, Erlang is not a logical language. Prolog is.

Second: Really? How about this example (Prolog pseudo-code, inc() and dec() increase/decrease a positive integer by one):

add(X, 0, Sum) :- Sum = X.
add(0, Y, Sum) :- Sum = Y.
add(X, Y, Sum) :- dec(X, 1, X2), inc(Y, 1, Y2), add(X2, Y2, Sum).

(at prompt)
> add(2, 3, Sum)
Sum = 5
(as you say, trivially reproduceable in any functional language.)
> add(X, 3, 5)
X = 2
(How do you "trivially" reproduce this in a functional language?)
> add(X, Y, 2)
X = 0, Y = 2
X = 1, Y = 1
X = 2, Y = 0
(Likewise?)

Re:apropos erlang (Go Sweden!) (1)

bakuun (976228) | more than 6 years ago | (#20484451)

"It is actually not a functional language, but a logical one."

Why not a functional language? I took an erlang course, and one of the speakers was one of the guys developing it at Ericsson. He specifically spoke of its qualities as a functional language.

Re:apropos erlang (Go Sweden!) (1)

Jhan (542783) | more than 6 years ago | (#20484589)

I regretted that almost as soon as I had posted it :-) Looks like Prolog != works like Prolog.

Re:Try it out (0)

aminorex (141494) | more than 6 years ago | (#20484019)

The article reads

> This book is a worthy successor to the last book published

which would imply that this book should *never* be published. Yet now I learn that [the first chapter
of [the successor of [the last book]]] is already available as a pre-print? Methinks my Peano is out of tune.

Re:Try it out (0, Redundant)

suv4x4 (956391) | more than 6 years ago | (#20484125)

The first chapter is avalable online to get a taste of the book (and the language).

Right.. sot he first chapter goes on an on how hot it is that once you assign a value to a variable, it can no longer be changed. You see, that's super hot, since you can assign Pi = 3.14 and then you can't change it.

But unlike constants those single-assignment vars can't be optimized at compile time, and still can't replace normal variables.

All in all, no wonder the language isn't popular. We're way way past drastic differences in the languages we'll use. We're stuck with C/Java like syntax, OOP and anything new regarding concurrency will be rolled up on top of it, versus replace it.

There are mountains of code out there in C-like languages that needs to be reused.

I believe concurrency will in the end be most implemented via RAM transactions, which proves a simple and effective model for handling race conditions, while retaining the look of the separate procedures as imperative sequential code as we know it today.

Listen up, chappies (0)

Anonymous Coward | more than 6 years ago | (#20483327)

When the only books about a language are written by the inventor of the language, there is probably a reason. And that reason is: No One Cares.

Re:Listen up, chappies (1)

Skinkie (815924) | more than 6 years ago | (#20483555)

One of the first alternatives as for the 'normal' jabber server implementation was written in erlang. Resulting in ejabberd [jabber.ru] people care :)

Great book creation process (3, Informative)

DoofusOfDeath (636671) | more than 6 years ago | (#20483403)

I bought the book while it was still being written. I was able to download drafts, and (if I had the time) submit bug reports. When it was finally done, I got a printed copy in the mail.

I haven't had much time to play with Erlang (or the book) yet, but it was a really nice feeling to be able to get early access as long as I was willing to see unpolished content. Bravo, publisher.

If only "Pro Django" had gone with PP (1)

ubikkibu (544498) | more than 6 years ago | (#20485273)

The "download PDF first, get dead tree later" approach is a huge winner for tech books. I did the same with "Programming Erlang," and it allowed me to get through the first few chapters on my iPhone (Safari does some magic that renders PDF very well), then read the rest on paper. Then I read Chapter 8 online again because I'd left the book home. Very convenient, and closer to Instant Gratification.

I'm probably not the only one waiting (and waiting...) for djangobook.com to get published finally, but a 2/3 finished PDF would have made me 2/3 happy in the interim.

What's missing from Erlang... (4, Interesting)

SanityInAnarchy (655584) | more than 6 years ago | (#20483437)

Last I checked, there was an implementation issue and a design issue.

The design issue, for me, was a lack of namespaces. I think it might have been that I can't have an atom with a namespace, beyond prefixing, which is a hack for languages that don't support namespaces.

The implementation issue was that you had to choose between performance and being able to reload functions later. I would very much like it to be able to JIT or even compile down to binary (x86_64 too, pretty please?), then be able to just leave it running, and have it reload functions as needed.

I'll have to think of what else I didn't like, but I don't think there was much, aside from some odd syntax. I don't actually have a problem with the somewhat functional nature of it, just certain syntax that looks ugly, but that's a matter of opinion, and something I can live with.

Re:What's missing from Erlang... (0)

Anonymous Coward | more than 6 years ago | (#20483613)

Erlang has had modules (namespaces) forever. What are you talking about?

Check out the HIPE project for a JIT.

I like Erlang and spent a couple years programming for an OSS Erlang project but my main problem with Erlang is the performance. It's basically crappy enough that you might as well using an even higher level scripting language like Lua or whatever.

Re:What's missing from Erlang... (1)

SanityInAnarchy (655584) | more than 6 years ago | (#20484227)

Erlang has had modules (namespaces) forever. What are you talking about?

Atoms. They're used for some things I might use constants for in another language, I think. I'll have to get back to you with some code examples.

Check out the HIPE project for a JIT.

HIPE is sort of what I was looking for -- I remember BEAM being bad. But I still don't see whether I can dynamically reload HIPE the way I can dynamically reload straight-interpreted stuff.

As for performance, well, it'll at least thread, without you having to think about it, and as I understand it, they are real threads, which is a big win over Python, for example. But that's what I'm holding out for, is a high-level language with good performance that at least approaches C.

Re:What's missing from Erlang... (4, Informative)

be-fan (61476) | more than 6 years ago | (#20484613)

But that's what I'm holding out for, is a high-level language with good performance that at least approaches C.

There's basically a handful of languages that would meet your needs here. On the dynamic side, you've got Common Lisp. On the static side, you've got ML, O'Caml, or Haskell.

After that, your options trail-off significantly. The other dynamic languages are all much slower than Lisp (more in the league of Python than in the league of C), and the other static languages (C#, Java), are much lower-level/less productive.

Lisp, you say? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#20485095)

I'll have to check it out again.

What are the options for compilation? Anything beyond simply distributing source code?

Name mixup? (1)

Hoppelainen (969375) | more than 6 years ago | (#20483439)

Perhaps it should have been given another name than a common statistical probability distribution (for some reason people who explore new programming languages are often interested in math and may therefore mix things up)

http://en.wikipedia.org/wiki/Erlang_distribution [wikipedia.org]

Re:Name mixup? (1)

lederhosen (612610) | more than 6 years ago | (#20483533)

It was created by Ericsson :-)

At the bookstore (0, Flamebait)

CaffeineAddict2001 (518485) | more than 6 years ago | (#20483441)

It shares half a shelf with the Standard ML and Haskell books. The other half taken up by the shrink wrapped "The Art of Computer Programming" that has been sitting on there since the store opened.

The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20483477)

Contrary opinion: The Seven Deadly Sins of Erlang [blogspot.com]

Re:The Seven Deadly Sins of Erlang (4, Insightful)

Anonymous Coward | more than 6 years ago | (#20483641)

Lets look at these "sins":
1. Not a sin, not needed and shows you don't know what you're talking about wrt reliability. hard real time is irrelevant.
2. More FUD based on your lack of understanding of programming.
3. is a downright lie
4. Contradicts three!
5. Ok, now I'm thinking you're not just a troll but verifiably insane. Show us a language (one that exists outside your head) thats not "alkorithmic"
6. Contradicts itself- is it based on english or is it cryptic?
7. Asinine in the extreme, and of course contradicted by the other 6 points. erlang is not logo

Bottom line- you are just making assertions that make no sense. If you ever were a programmer, you never learned much about programming... and your constant bashing of erlang is just an attempt to get attention. COSA doesn't exist, except in your head, where it can be magical and change as is needed for you to make whatever "point" you want to make.

I guess its a sign that erlang is becomming mainstream that it has attracted a loon such as yourself.

Re:The Seven Deadly Sins of Erlang (4, Insightful)

Wesley Felter (138342) | more than 6 years ago | (#20483707)

Summary: "Erlang isn't based on my fringe pet theory, so it sucks".

Re:The Seven Deadly Sins of Erlang (0)

Anonymous Coward | more than 6 years ago | (#20483729)

Did you post that contrarian link in order to add more evidence to my thesis that 99% of blog posts fall in the "worthless or worse" category?

Disclaimer: I have next to no knowledge regarding Erlang, period, but the "seven deadly sins" were either poorly explained or just plain nonsensical. The algorithmic sin, in particular, made me wonder whether the blog author was involved in the development of INTERCAL.

Re:The Seven Deadly Sins of Erlang (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#20483801)

Did you actually read that bloke's site? He's a total wacko!

Re:The Seven Deadly Sins of Erlang (4, Insightful)

jguthrie (57467) | more than 6 years ago | (#20483813)

I often judge the quality of something by looking at the quality of the criticisms of it. If that's the best criticism of Erlang that you can find (or come up with) then Erlang looks pretty damn good. Of course, if you could see your way clear to describing how to write programs without implementing algorithms instead of simply explaining in great detail that algorithmic software is bad, maybe I would find it easier to embrace your view of programming.

Re:The Seven Deadly Sins of Erlang (2, Informative)

ibullard (312377) | more than 6 years ago | (#20483821)

That is the same guy who says you can get artificial intelligence from the bible [rebelscience.org] . He's a loon with a large vocabulary.

Postblablurb (1)

zeromorph (1009305) | more than 6 years ago | (#20484401)

He's a loon with a large vocabulary.
Or a loon with a recursive network [monash.edu.au] . I recommend this [elsewhere.org] instead.

Re:The Seven Deadly Sins of Erlang (0)

Anonymous Coward | more than 6 years ago | (#20483833)

[insert picture of a cracked pot here]

Re:The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20484107)

[insert picture of a cracked pot here]

ahahaha... Funny. This is one crackpot that you're gonna be hearing a lot about from now on. By the way, Erlang has many more sins than the ones listed, though. Did you know that Erlang cannot do fine-grain parallelism? That's right. There is no parallel quicksort algorithm in Erlang. Ooops. It cannot do it. What good is an algorithmic language in a computing world that's moving full speed toward massive parallelism? I just thought I'd mention these things, just to piss off my detractors. ahahaha....

Re:The Seven Deadly Sins of Erlang (0)

Anonymous Coward | more than 6 years ago | (#20484373)

Well, the nutty description of parallel qsort you have on your site doesn't exist in the real world, so why don't you STFU?

Re:The Seven Deadly Sins of Erlang (1)

iggymanz (596061) | more than 6 years ago | (#20484385)

your detractors are merely laughing at your complete ignorance of computation and your silly worthless pet project, it's doubtful you could do anything to get them actually mad, though your straw man argument about sorts is vaguely annoying.

Re:The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20484507)

it's doubtful you could do anything to get them actually mad

ahahaha... Are you kidding? You guys have been jumping up and down and foaming at the mouth ever since I started writing about how crappy Erlang is. ahahaha... It's entertaining (in an anthropological sort of way), that's for sure. ahahaha...

Re:The Seven Deadly Sins of Erlang (0)

Anonymous Coward | more than 6 years ago | (#20484535)

ahahaha

I am totally convinced by your eloquent arguments.

Re:The Seven Deadly Sins of Erlang (2, Funny)

Rakishi (759894) | more than 6 years ago | (#20485399)

Foaming at the mouth? No, you;re misunderstanding. we're either on the floor laughing at your stupidity or starting dumbfounded at our screens wondering how someone as stupid as you can possibly exist.

Please do continue posting as it's endlessly amusing, people like you are like digital clowns. After all every society needs a town idiot to make everyone else feel better about themselves.

Re:The Seven Deadly Sins of Erlang (4, Insightful)

rk (6314) | more than 6 years ago | (#20484587)

See, here's the thing: I can download Erlang and start to learn it right now. Where can I find COSA? That's right, it's vaporware.

Who knows, you may be on to something. I'd suggest writing fewer white papers and less name-calling of your detractors and get busy implementing your vision. Nothing will shut them up faster when you've got something that lets people develop systems that are more reliable for no extra cost.

Until then, you're in the same category as people who promise us perpetual motion machines and anti-gravity levitation.

Re:The Seven Deadly Sins of Erlang (-1, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20484723)

Who knows, you may be on to something. I'd suggest writing fewer white papers and less name-calling of your detractors and get busy implementing your vision.

Yeah, I'll do that as soon as you fork up a few millions to start a project. Until then, you Erlang fanatics will keep getting reminded of how crappy Erlang is. Big time crappy too. ahahaha...

Re:The Seven Deadly Sins of Erlang (0)

Anonymous Coward | more than 6 years ago | (#20484779)

Ladies and Gentlemen, what we have here is truly a master of discourse. His typing of "ahahaha..." sure convinced me.

Re:The Seven Deadly Sins of Erlang (1)

Surt (22457) | more than 6 years ago | (#20484945)

Yep, it's definitely all the millions poured into Erlang development and publicity that made it the COSA killer it is today.

Re:The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20485079)

Yep, it's definitely all the millions poured into Erlang development and publicity that made it the COSA killer it is today.

LOL. Yep. that's it. If COSA had the backing of a company like Ericsson (ask Joe Armstrong, he'll tell you), it would not only kill crappy Erlang, it would kill every other language else as well, being that they all suck. ahahaha...

Re:The Seven Deadly Sins of Erlang (1)

sskang (567081) | more than 6 years ago | (#20484979)

From what I understand through a cursory look at your COSA web pages, I get the impression that you are pushing a graphical language that is somewhat like National Instruments' LabVIEW. Have you used LabVIEW? If so, how is it similar/different to your COSA "ideal"?

Re:The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20485129)

Have you used LabVIEW? If so, how is it similar/different to your COSA "ideal"?

There are similarities but COSA takes parallelism and deterministic timing to an extreme. COSA is 100% reactive, that is, it is based on change.

Re:The Seven Deadly Sins of Erlang (1)

rk (6314) | more than 6 years ago | (#20485197)

Yes, that's right. I'm completely fanatical for a language I've never used. I'm rolling my eyes now... just in case the sarcasm went totally over your head.

Why do I have to fork up the money? You're the one with the extraordinary claims of dramatic reliability increases. If you're so much more brilliant than the rest of us, it shouldn't be terribly difficult for you to at least create something a little more sophisticated than something that looks like an OmniGraffle demo on stupid pills [sundman.infa.fi] in a few weekends. I just want to know: Will COSA let us reprogram the Time Cube [timecube.com] ?

Before you replied, I wasn't sure if you were a complete crackpot. Thank you for resolving the question.

Re:The Seven Deadly Sins of Erlang (-1, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20485275)

[snip public maturbation]

Did I mention that Erlang was crap? Oh yeah. Sorry. ahahaha...

Re:The Seven Deadly Sins of Erlang (1)

webfiend (112579) | more than 6 years ago | (#20483843)

It's just another angry rant, quick to denounce anybody that disagrees. I can get those from deranged street people or by staying on slashdot.

Re:The Seven Deadly Sins of Erlang (1)

imsabbel (611519) | more than 6 years ago | (#20483967)

Well, thats it.

The blog you link (especially the authors reactions to criticism in the comments) show that he should really have been aborted when it was still possible.

Re:The Seven Deadly Sins of Erlang (1)

rubycodez (864176) | more than 6 years ago | (#20484155)

and his mother shot in the face during the procedure; you just can't be too careful in cases like this

Re:The Seven Deadly Sins of Erlang (0, Troll)

MOBE2001 (263700) | more than 6 years ago | (#20484411)

and his mother shot in the face during the procedure; you just can't be too careful in cases like this

The rabid fanaticism of Erlang followers is unparalleled. But hey, Erlang is not parallel either, it just pretends to be. ahahaha... You people remind me of FORTH programmers. Needless to say, both languages suck. ahahaha...

That's a joke, right? (1)

ubikkibu (544498) | more than 6 years ago | (#20485203)

Seriously, is it? Because those criticisms are pathetic, and two contradict each other.

I'd actually like to read a serious criticism of Erlang. I finished "Programming Erlang" on Sunday, and like many folks, I'm mildly jazzed about Erlang. The syntax hurts somewhat, but then again I spend all day coding Python. And while I can think functionally somewhat, I have a hard time imagining larger systems without OOP, but that's probably my lack of experience.

I'm ready to do something good with Erlang, but I'd like more contrary opinions before I do so.

(The book was outstanding--a pleasure to read.)

Possibly the greatest programming book I've read (4, Insightful)

ikewillis (586793) | more than 6 years ago | (#20483511)

This book is written by the language's creator, Joe Armstrong, and provides one of the best introductions to a programming language I've ever seen. The entire approach is nicely bottom up, with the idiosyncrasies of the syntax presented immediately so they are not confusing later. More powerful features are introduced, such as the tools for concurrent and distributed programming, with the book finishing off with the immensely powerful Open Telcom Platform and its associated tools, such as the "one server to rule them all" gen_server implementation and Erlang's distributed database, Mnesia.

All in all this is an excellent book about an excellent language and I would highly recommend it to any programmer, especially those concerned with the multicore future which will increasingly demand concurrent programming languages.

Re:Possibly the greatest programming book I've rea (3, Interesting)

BrewerDude (716509) | more than 6 years ago | (#20483737)

My vote for best introduction-to-programming book goes to Structure and Interpretation of Computer Programs [mit.edu] (a.k.a. The Wizard Book) by Hal Abelson, Jerry Sussman, and Julie Sussman.

Re:Possibly the greatest programming book I've rea (2, Insightful)

BitGeek (19506) | more than 6 years ago | (#20484055)

Programming Erlang is the best intro-to-new-programming language book I've ever read. By far. While erlang is radically different than previous languages I've learned, this book goes a long way to making the transition smooth.

I'm still struggling, but I read the book with an application in mind, and have found its coverage is excellent... it brings you right up to the point that is needed for the other erlang documentation to be readable. (There are 60 some odd books on all the major components of erlang and OTP, including the major modules and APIs... they are downloadable from erlang.org)

So, this book accomplishes its goal and really well. ITs not a shallow marketing piece about the language (as most books written by writers rather than programmers are) its a real how-to-program in erlang book and it does a great job of showing how you solve very difficult problems in erlang. It even has as examples things like full text indexing and map reduce.

I think every programmer worth his salt should buy this and learn erlang-- the days of single core computing are over, and thus concurrency oriented programming is a critical skill to pick up, and erlang is the best language for it.

Wings3D (4, Informative)

UglyMike (639031) | more than 6 years ago | (#20483535)

Strange that I didn't see Wings3D mentioned yet. ( http://www.wings3d.com/ [wings3d.com] )
It's an open-source subdivision surface modeler held to great esteem in the modeling scene

It is also an Erlang application....

Re:Wings3D (0)

Anonymous Coward | more than 6 years ago | (#20485223)

Luckily Wings3d is relatively feature complete.

Its development is pretty slow because there are very few developers who know Erlang.

Hopefully a few /.ers will read this book, and need a pet project to want to throws their skills at and Wings3D will get a developmental shot in the arm.

Review worth a +1 karma! (5, Informative)

Z00L00K (682162) | more than 6 years ago | (#20483573)

The review is well written, and even though Erlang is a programming language that not everyone is used to program in it's well worth to mention that a large number of telecommunication devices from Ericsson are running software written in Erlang, so most people has probably been using it without knowing it.

And in my opinion; If you are familiar with more common languages like C and Java you should take a deeper look into Erlang unless you prefer to study Prolog or Cobol. Just take a dip or a deep plunge, you never know when you end up in a project where knowing Erlang may prove useful - it is actually developed to be used in real applications and not as a theoretical study object.

And Erlang is designed to handle concurrent programming from the bottom, which is a real problem in large multi-user systems. You can of course use C or Java and solve concurrency problems with semaphores or synchronization, but the solution in Erlang may be much more elegant.

And for all of you that are familiar with the Eclipse development environment; There is a plugin called Erlide [sourceforge.net] .

Any .Net Versions? (1)

Crazy Taco (1083423) | more than 6 years ago | (#20483807)

And for all of you that are familiar with the Eclipse development environment; There is a plugin called Erlide.

That's cool. Are there any .Net versions of the language? In fact, is that even possible given that Erlang is developed to be parallel from the bottom up, as opposed to other .Net languages?

I know why it's been 10 years (1)

lib3rtarian (1050840) | more than 6 years ago | (#20483695)

I just looked up Functional Programming in Wikipedia. Wow, I thought assembly was bad. Albeit, I didn't spend more than fifteen minutes on it, but, after reading this review, and looking at some examples, I'm totally confused.
I pulled this example from Wikipedia:

# imperative style
target = [] # create empty list
for item in source_list: # iterate over each thing in source
trans1 = G(item) # transform the item with the G() function
trans2 = F(trans1) # second transform with the F() function
target.append(trans2) # add transformed item to target

A functional version has a different feel to it:

# functional style
# FP-oriented languages often have standard compose()
compose2 = lambda F, G: lambda x: (F(G(x))
target = map(compose2(F,G), source_list)

The first block of code is easy to understand. The second block, whoah, I guess I just have to take your word that it does the same thing as the first block. Can someone give me an introduction/explanation to Erlang / functional programming that I can understand? At this point, I don't even understand what situations this could be usefully applied to.
It seems interesting though...

Re:I know why it's been 10 years (1)

stormcoder (564750) | more than 6 years ago | (#20483891)

Wow you must be new here. Expecting the /. community to do something constructive like teaching programming...

map is a higher order function that takes a list and iterates over the elements calling a function, that is also passed in, on each element. The results are returned from map as another list. lambda creates anonymous functions. So an anonymous function is created and passed into map along with a list. It's a common functional idiom. Functional programming style is well worth knowing.

Re:I know why it's been 10 years (0)

Anonymous Coward | more than 6 years ago | (#20483927)

Very informal explanation here, but anyway.

compose2 is declared as a function that given some value X, returns F(G(x)). That is, first runs G(x) and then runs its return value through Y. To make it more general, compose2 is further "initialized" with the two functions that are going to be used (think function pointers).

So in pseudo C-style (sorry, don't remember the correct syntax):

void * compose2(&F, &G, void *x) {
      return F(G(x));
}


Later, the "magic" map-function, which given a function and a list, runs that function on every item in the list and inserts the items into a new list.

Simple, short, elegant.

Re:I know why it's been 10 years (0)

AuMatar (183847) | more than 6 years ago | (#20484177)

Also next to impossible to maintain, debug, or understand. You can look at the first function and understand it piece by piece almost instantly. You can easily run through it in a debugger, log it, and change it at a later date. The second requires deep though to understand, can't be easily debugged (unless you want to dive into a predefined function), can't be changed easily. So its short, but it is NOT simple or elegant. I'd call version one far more simple and more elegant.

Re:I know why it's been 10 years (1)

MenTaLguY (5483) | more than 6 years ago | (#20485151)

The second one doesn't require particularly deep thought to understand, but it does require a very different way of thinking about code.

Re:I know why it's been 10 years (2, Insightful)

ForumTroll (900233) | more than 6 years ago | (#20485251)

I agree partly with your sentiments on debugging - although I don't think it would be a huge problem. However, I don't think that the second piece of code is more difficult to understand than the first. I'm able to look at the second piece of code and easily understand exactly what's happening almost instantly. It largely depends on what you're used to. If you're used to writing only in an imperative style, obviously a functional style is going to take some time getting used to. The vice versa is also true. This doesn't mean that one is inherently superior to the other.

Re:I know why it's been 10 years (4, Insightful)

be-fan (61476) | more than 6 years ago | (#20485407)

Also next to impossible to maintain, debug, or understand.

Uh, if you don't know functional programming, then yeah. If you do, it's instant to understand, and can be maintained more easily because there is less of it to maintain.

Your argument basically amounts to "stuff I don't know is hard to understand". No shit. New notation and concepts have to be learned, yes, but there is a point to learning them. It makes things simpler and easier once you have learned them. Consider, why do people in signal processing do all sorts of Z transforms and Fourier transforms and whatnot on data? Surely it's _easier_ to just think of a sound signal as a series of amplitudes at discrete time intervals? The thing is --- it isn't. Once you learn all that math, you can do stuff with signals by hand that you couldn't even have dreamed off if you'd used a less powerful technique.

Re:I know why it's been 10 years (1)

BitGeek (19506) | more than 6 years ago | (#20484275)


IF you consider yourself a serious programmer, you would do well to go download the free chapters of this book from the pragmatic programmers site and read up a bit.

I too had an advers reaction after 20 years of OO programming.... but I stuck with it and now I see the light.

Its worth the effort.

Re:I know why it's been 10 years (4, Insightful)

J.R. Random (801334) | more than 6 years ago | (#20484441)

There is nothing in the second example that isn't completely familiar to anyone who has ever programmed in LISP, one the world's oldest programming languages.

Newbies, feh!

Re:I know why it's been 10 years (1)

curri (107175) | more than 6 years ago | (#20484455)

You probably want to check Wikipedia or something like that for the intro :) Many functional languages are relatively similar, so you may want to go with Haskel or even scheme (although scheme has completely different syntax).

The functional block is about as easy to understand, once you know FP :), the first one is easier for you because it looks closer to what you know.

So, let me try to explain:
compose2 = lambda F, G: lambda x: (F(G(x))

This makes compose2 denote a new function (lambda creates new functions), this function takes two arguments, F and G (which are functions by the way !) and returns a new function. This new function takes one argument, x and returns the result of applying F to G(x)

This is actually incredibly nifty, since it lets you compose ANY functions of one argument! Compare that with function pointers in C or all the extra stuff we add in OO (say to add an event handler).

Now, second line; map is a function that takes two arguments, a list and another function, and returns a new list containing the result of applying that other function to all elements of the original list.

So
target = map(compose2(F,G), source_list)

means make target denote the result of applying the composition of F and G to all elements in the source_list. Isn't that beautiful ?

Actually, this is really nifty but may be hard to get the first time (or the first ten :), OTOH, procedural programming is also hard at first :) if you actually have time, google for 'the little haskeller' or 'Structure and Interpretation of Computer Programs (for scheme)

Re:I know why it's been 10 years (1)

poopdeville (841677) | more than 6 years ago | (#20484817)

If you know perl, you can learn functional programming in about a day. You can learn the concepts involved in about an hour. See http://perl.plover.com/lambda/ [plover.com] .

As far as your example goes, note that if you allow yourself mathematical syntax, since trans1 = G(item), F(trans1) = F ( G(item) ). Indeed, since F and G are functions, we can create a new function (F o G) given by the rule (F o G)(x) = F( G(x) ). This is called functional composition. Lambda is a function constructor, as it is in the lambda calculus.

The functional program says:

1. create a function called 'compose2' which takes two arbitrary functions (which for the purposes of the definition will be called F and G) as arguments. Define compose2 as F ( G ( x) ).

2. Let "target" be the result of applying (F o G)(x) (as described above) to each element in a list called source_list. (The semantics of map mean that target is a list such that target[i] = (F o G)(source_list[i])

Way simpler, once you get it.

Re:I know why it's been 10 years (1)

k8to (9046) | more than 6 years ago | (#20485097)

To rephrase your observation: "Hey, I've been programming in imperative languages for decades, and this functional stuff is not familiar!"

That's right, it's not easy for you to understand because you do not have experience with it. That doesn't mean it's somehow intrinsically more difficult to understand.

Re:I know why it's been 10 years (2, Informative)

be-fan (61476) | more than 6 years ago | (#20485201)

So, think, what are you actually trying to accomplish in the first block of code, in terms of the end-result.

You're computing a list, target, where each item is computed by F(G(x)), where x is an item from source_list, taken in order.

Note that stuff like "iterating over source_list", and "appending to target" are not really important. They are certain necessary steps in one possible implementation of what you're trying to accomplish, but they're just incidental --- they're not part of the end result.

Now, map is a function that takes two arguments: a function that takes one parameter and a list. It constructs a new list equal in length to the source list, with each element obtained by calling the function on one element of the source list. Ie: if you do map(square_number, [1, 2, 3]) you get [1 4 9].

Now, let's look at the functional code. The first line is a function definition for the function compose2.

compose2 = lambda F, G: lambda x: (F(G(x))

lambda is a way of introducing a literal function, much like "1" is a literal integer. lambda F, G: ... means a function that takes two parameters, F and G, and returns ... (note the return is implicit. In this case, the compose2 variable is assigned to a lambda that takes two functions F and G, and returns a third function that takes a value x and computes F(G(x)). Note that this is exactly the function we want to use to compute our list.

Now let's look at the second line:

target = map(compose2(F,G), source_list)

The code first calls compose2 with parameters F and G to get a function that computes F(G(x)). Note that this function is exactly in the form expected by map. Then it calls map with that function, and the source list. Map will internally apply F(G(x)) to each x in source_list, and retrn a list containing the results.

Note that usually stuff like compose2 will be a standard library function, because this sort of thing is so common. In that case, your original five lines of code, becomes a single line, that expresses exactly the end result you want, without being cluttered with incidental details like iterating over or appending to a list.

I should point out that I don't know Erlang, or whatever language that snippet is in. The second example is nonetheless easy for someone used to functional programs to understand, much like the first example is easy for an imperative programmer to understand, even one that doesn't know Python.

Re:I know why it's been 10 years (2, Informative)

Just Some Guy (3352) | more than 6 years ago | (#20485231)

At this point, I don't even understand what situations this could be usefully applied to.

Well, functional programs have a lot of other restrictions, but it boils down to this: with very rare exceptions (such as file or socket handling), functions don't have side effects. That is, they don't modify a program's global state, and they don't depend on global state. You can call foo(args) 100 times in a row and each time the output will be identical. My C++ is rusty, but imagine something like:

int foo(int &bar, int &baz) { return bar++ * baz++; }

Any code that calls foo() will find its internal state changed - both bar and baz have been altered. In comparison, this is almost impossible to do accidentally in functional languages.

So, great, what does that buy you? Well, the map() function in you example knows that it's supposed to call compose2() on each item in source_list. Because it's impossible for compose2() to have strange global side effects and it doesn't depend on external state, map() is free to fork() 10 times and let each child process munch through independent subsets of source_list. In the case of Erlang, map() is also free to hand off chunks of source_list to other machines and coalesce the results from all of those hosts at the end. As long as compose2() gets called on each item at some point, the order (and indeed the physical location) of each call doesn't matter a lick.

Imagine that you have 20 quad-core systems in a cluster. Replacing the imperative example above with the functional example gives your code an 80x performance boost, minus a little network overhead. Does that sound more interesting now?

Have you ever written a loop? (4, Informative)

Estanislao Martnez (203477) | more than 6 years ago | (#20485325)

It's very different, but the big advantage is that it's higher level than the stuff you confess to understanding better.

The code in question (in Python? not a great choice for doing an example!) uses two very common higher-order operations in functional programming: map and compose. A map operation takes a complex data structure (most common example: a list), and a function that applies to elements of that data structure, and returns another structure, with the same "shape," where each element in the result is related to its corresponding element in the original structure by being the result of apply the function. Thus, if you have a list [2, 3, 5, 7], and a function inc that increments a number by one, map(inc, [2, 3, 5, 7]) evaluates to [3, 4, 6, 8].

In the case of a list, map is can be implemented by creating a new list of the same length as the original, looping over the list, applying the function to each value, and storing the result in the result list. This is a kind of task that imperative programmers find themselves doing all the time. The problem with this, however, is that if you're writing code like this all the time, you're writing at a much too low level, with the all the disadvantages of that:

  1. It takes you longer to write code. Instead of writing just result = map(fn, myList), you have to write a loop.
  2. Your code is specifying the mechanism to convert the input list into the output list over and over, instead of describing the relation between the lists. Suppose you want to change the mechanism for doing this sort of operation, e.g., to parallelize it. In functional style, you can just rewrite map to do its work in parallel. In imperative programming, you have to work harder.
  3. The concept of mapping a function over a structure, to produce a new structure with values related to the original by the function, applies to many kinds of data structure, not just sequences. You can write equivalents of maps for any container data function you like, even though the mechanics are different; e.g., to implement a map function over a tree you typically use recursion. This means that in the imperative style, the code for "increment all the values of this list by 1" looks very different from the code for "increment all values in this tree by 1"; in functional programming, they will at least look very similar, if not completely the same.
  4. There are many, many other common progamming blocks that you can abstract into a function in functional programming, but not in imperative programming. For example, filtering a list to only keep the elements that satisfy a boolean function, which in functional programming is usually just a function called something like filter. For example, if you have a function called even, that returns true only for even numbers, here's how you get the even numbers in myList: filter(even, myList)
  5. Functional programming solutions often compose more easily than imperative ones; i.e., it is easier to put them together to solve more complex tasks. For example, if you need to increment a list of numbers by one each, and only keep the ones that are even in the result, you can do that easily and transparently: filter(even, map(inc, myList)). In the imperative style, the patterns for mapping and for filtering don't combine this straightforwardly.
  6. Functional code is usually easier to read. When I read a piece of imperative code and come across a loop, I normally have to work the steps a bit in my mind in order to see what it is that it does: "Hmm, we create a new list at the beginning, then we loop through the elements of this other list, and as we go through each one, we apply a function to it, and put the result in the list we first created. Ah, we're mapping over the list." In functional programming, these common patterns find immediate expression in a higher-order function, and this higher order function, essentially, describes the relationship between the input and the output directly: "Ah, he's using map, so the result will be a list, with the same number of elements as the original, and each element in the result will be related to exactly one in the original, and in this way."

Thus, in short, functional programming is useful nearly every time that you write a loop or a recursive algorithm today, because it replaces the explicit looping or recursive mechanics that you use today, with an application of a higher order function that describes how the input relates to the output; and in addition, it allows you to write your own such custom functions, and rewrite them at will to change how they do what they do.

Huh? (1)

homer_s (799572) | more than 6 years ago | (#20483795)

Saying that the Author does a good job of leading you through the languages intricacies with examples being compared to code from languages such as Java to help keep your feet on solid programming ground.

Glad to see Erlang finally getting some attention (1)

Cultural Sublimation (884893) | more than 6 years ago | (#20483877)

I had my first encounter with Erlang at a Ericsson presentation back in 1994. It's amazing that more than ten years have passed since then, and only now is the language becoming more mainstream! This new-found attention is well-deserved, however: Erlang will feel right at home in those +80 CPU cores on the horizon...

As for other less conventional languages, OCaml also definitely deserves a look. It is functional, though also allows imperative features; it has a powerful module system, but also supports object-oriented programming; it has a certain academic feel, but real-world performance (check the shootout if you want: it's among the fastest ones, comparable to C++) and a very good and comprehensive repository of libraries (even for low-level stuff!). Definitely one of the best things to come out of France in recent memory!

Erlang... (1)

tomq123 (194265) | more than 6 years ago | (#20483919)

the new programming language du jour.

I bought the book early in PDF form (1)

MarkWatson (189759) | more than 6 years ago | (#20483993)

Overall, the book is very good: the examples are clear and useful, and for an old Prolog programmer like me, Erlang has a natural feel to it.

I have been disappointed that none of my customers seem to be interested in Erlang development - I proposed using it for one application where 'share nothing' asynchronous communication seemed like a very good fit.

Be careful (0, Troll)

roman_mir (125474) | more than 6 years ago | (#20484015)

If you program in Erlang you will look like these guys. [youtube.com] (Oh, and I think these people actually believe that it is a good idea to allow modification of code directly in production environment. I think a library can be written explaining why this is a dumb idea.)

Re:Be careful (1)

BitGeek (19506) | more than 6 years ago | (#20484207)


Its surely a dumb idea for applications written in languages like C and Java... but not for erlang.

Remember, systems running this language have had uptime on the order of many years, and that's with in-place code modification.

You're rejecting what you don't understand based on assumptions that are true for other contexts.

Downtime is a sin, not a virtue!

Re:Be careful (1)

roman_mir (125474) | more than 6 years ago | (#20484363)

Regardless of what the virtues of the language at hand, it is never a good idea to modify code directly in production without running a full suit of tests against the code. Businesses that rely on software applications running their systems must have well defined deployment processes. Code that goes into production must be tested against the specified requirements. While Erland (just like Javascript for example) supports dynamic typing, and while it allows (just like Javascript) updating functional code on the fly, it is still a terrible idea to allow developers to work on production systems directly without deploying code into testing and staging environments first. I'll just stop there.

Re:Be careful (1)

k8to (9046) | more than 6 years ago | (#20484573)

Your criticism is completely irrelevant to the language feature. That the language (and runtime) allow for live updates does not mean that enforces (or encourages) live *edits*!

Re:Be careful (1)

roman_mir (125474) | more than 6 years ago | (#20484633)

It is not irrelevant from my point of view, because I have seen people pushing this language forward on this particular merit, that the deployment can be done without a real deployment by modifying code in production on the fly. Since that (and the dynamic typing) was the main reason why I have seen people try and push the use of this language forward, I don't think it's irrelevant.

Re:Be careful (1)

Chirs (87576) | more than 6 years ago | (#20484355)

You wouldn't *test* the modified code in the production environment, you do that in the lab. But it can definately be useful to modify apps on the fly without taking down the system.

In fact, the company that I work for has done exactly this for C/C++ apps on four different hardware architectures. (There are restrictions....its basically impossible to modify an inline function, for instance.)

Re:Be careful (1)

roman_mir (125474) | more than 6 years ago | (#20484429)

You are talking about a partial deployment, this can be specified as one possible deployment process to update production, and it is still a bad idea because at this point it is not possible to say for sure that what is running in production was built from a specific source controlling system's tag for example.

So while it may work for some special cases, I am saying it is just a bad idea to do deployments like this as a principle, you can't be sure what is running in production at some point.

Re:Be careful (1, Insightful)

Anonymous Coward | more than 6 years ago | (#20484983)

> So while it may work for some special cases, I am
> saying it is just a bad idea to do deployments like
> this as a principle, you can't be sure what is running
> in production at some point.

Decision Point:

Choose from these options:

1. Side with a Slashdotter who refuses to accept that
      this isn't testing-in-production;

2. Trust telecoms companies who do this with Erlang
      FOR REAL with MILLIONS OF DOLLARS on the line,
      literally.

Well shucks I don't know....

Re:Be careful (1)

roman_mir (125474) | more than 6 years ago | (#20485347)

3. Read carefully what the /.er wrote about special cases. In most cases this mode of deployment is unacceptable, like in most places I've worked as, which include telcos, utilities, banks, mutual funds, manufacturing and such.

4. Profit from selling Erland as another silver bullet that will save the day.

No, not a "good idea," (1)

ubikkibu (544498) | more than 6 years ago | (#20485351)

live code updates are an up-front requirement for the domain Erlang addresses. Google "nine nines" if you don't understand why.

OOP to Erlang (1)

chiph (523845) | more than 6 years ago | (#20484109)

The author here highlights one of the language features, the Erlang light weight process. These are true processes (not threads) but take up very little in the way of resources. Indeed it is not unusual to have 1000's of such processes running in an application.

Would a good analogy be that an Erlang process is comparable to an object instance, in that both are loosely coupled (ideally), focused on one task (ideally), but in Erlang they're all running asynchronously and the OS/runtime automatically handles the communications for you?

Chip H.

Needs more on common libraries (1)

vik (17857) | more than 6 years ago | (#20484475)

A great book on Erlang, but missing a few details on the usage of common libraries. In particular it could do with more information on how to drive the Mnesia database. I started programming Erlang a month ago and the shortage of implementation docs on the database and list libraries has been a problem for me.

Yes, I do know about the Ericsson Mnesia manual and http://trapexit.org/ [trapexit.org]

Vik :v)

ejabberd is written in Erlang (1)

the_olo (160789) | more than 6 years ago | (#20484595)

It's worth noting that ejabberd [jabber.ru] is written in Erlang.

For those who haven't heard about it, it's an open source, distributed, fault-tolerant instant messaging server (Jabber/XMPP), modular and very configurable and is readily available in most Linux distributions' repositories.

It's one of the most promiment erlang-based projects.

With a name like erlang (0)

Anonymous Coward | more than 6 years ago | (#20484611)

...YAWN...

Full-time Erlang programmer gives his view :] (2, Informative)

pnis (664824) | more than 6 years ago | (#20484815)

As somebody writing code in Erlang as a profession, I say, though it has strength, it's crap. It has strength in the efficient handling of many processes (faster then the OS when there are many many thousands of them), aand (re)loading modules on the fly into the virtualmachine is nice. But on the flipside Erlang is slow as it's a very high level language, with a not so clever virtual machine - much less so than java vms (well I have to admit I am an assembly&C fan). Also functional programming my ass. In reality it's more like very basic barebone declarative programming, where you can only use global variables (mnesia database, and in worse cases the process dictionary) and there are no loop constructs (you can only use ugly additional functions and recursion instead of a "for" construct). Well, at least this is my opinion.

CouchDB was written in Erlang (1)

dominux (731134) | more than 6 years ago | (#20484923)

to give you an example of something built in Erlang take a look at http://www.couchdb.com/ [couchdb.com] CouchDB is an Open Source (GPL) database back end. It is in some ways inspired by the database architecture of Lotus Notes, it is a non-relational document based store with strong replication ability. Don't bother bitching about Notes, the new UI is quite different to the old look (personally I liked the old style) but CouchDB doesn't have a UI, it has similarities at the architecture level which is where Notes is very very good indeed, and CouchDB is better.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>