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!

Erlang and OTP in Action

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

Book Reviews 63

RickJWagner writes "Manning has just released a new Erlang title, called Erlang and OTP in Action. For quite some time now, there's been a definitive guide to Erlang-- Joe Armstrong's excellent book Programming Erlang. Well, it's time to make a little extra room on the bookshelf, because the Erlang book-o-sphere has just shifted. There are now two must-have resources for an Erlang programmer." Keep reading for the rest of Rick's review.The book is divided into three sections. The first one deals with the basics of Erlang and details about the OTP application framework. Part two shows how to build a production-worthy application in Erlang. The third part of the book is about integration and tuning.

Section 1 has chapters that cover the following: basics of Erlang and OTP, Erlang language fundamentals, writing a TCP-based RPC server, OTP and the supervisor model, and graphical tools to help your development efforts. Language newbies will spend some time here, as Erlang can be a little odd to programmers coming from non-functional environments. (Concepts like recursion are given great coverage, as it should be.) OTP, the Erlang ubber-framework, is explained in detail as well. Section 1 alone would make a decent book on Erlang, but there is much more here.

Section 2 covers building a production application. The example given is a caching application, designed to increase throughput of a web application. In addition to expected topics like logging and an event-framework, the reader is exposed to Erlang's built-in distributed database, Mnesia. Application packaging and deployment considerations are also covered here.

Chapters in section 2 follow a helpful pattern to guide the reader through building an application. First, there is an introduction to some high level concept. Next, it is shown how this new widget can be used to further the needs of our production-worthy caching application. Finally the authors provide code that brings the desired functionality into the ever growing caching application. Erlang code tends to be somewhat dense-- not much code goes a long way-- so much of the latter part of each chapter is explanatory text explaining why you'd want to implement things in the way the authors did. Chapters in this part of the book read like an in-depth tutorial, and that's not a bad thing.

The third section of the book shows how to integrate with external users via HTTP, how to allow programs written in other languages to communicate with your Erlang code, and how to tune your environment. It's notable that Java gets a whole chapter on integration, through JInterface (in comparison, Joe's book offers about 4 lines on this topic. In fairness, that's a much older book, though.)

Throughout the book, simple illustrations are used to demonstrate key concepts. I found these to be extremely helpful, as Erlang in general is quite different than most programming languages. The delta between Erlang application development and other-language development is an order of magnitude different than something like the difference between Java and Ruby or Python and .Net. It's got different characteristics and different concepts. Given these large differences, I really appreciated the illustrations.

The book covers language built-ins like management tools, profilers, etc. (If you've ever used GNU development tools to profile an application, some of these might look a little familiar). The reader is given a lot to think about, and it's scattered over nearly 400 pages. To make a Java analogy, it's like an all-in-one book that teaches the language, the JDK and tools, JEE, and shows how to integrate your enterprise application with external entities. It's ambitious, but the book does a good job in explaining everything. That's why the impressive page-count helps. A skinnier book probably wouldn't be able to pull all that off.

The book is written with easy-to-understand anecdotes that help the reader grasp the finer points of Erlang craftsmanship. You definitely get the impression the authors have written 'real' code, and they offer strong direction to guide the reader through constructing application code. There is a big difference between understanding language syntax and understanding best practices in application construction. Section 2 in particular is loaded with best practices, and this alone makes this book a worthwhile read for Erlang coders writing production applications.

Probably the best thing I can say about this book is that the authors seem to put the advancement of Erlang above all else. To bolster that statement, I'd point out that they give the reader a list of other Erlang books they may wish to read, and they also include several mentions of Joe Armstrong. (Joe is the author of what has been the most popular Erlang book.) In my opinion, the authors can afford this indulgence, as this book is strong enough to merit inclusion on the Erlang programmer's bookshelf.

So who is this book good for? I'd recommend this book to anyone who wants to program in Erlang. It can get beginners off the ground, and will reveal many best-practices to those who already know their way around Erlang.

You can purchase Erlang and OTP in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

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

I'm sure that both Erlang programmers... (0)

gestalt_n_pepper (991155) | more than 3 years ago | (#34491462)

will just love this book.

Oh, and by the way, "First!"

Haskell is in a similar position (2, Funny)

emj (15659) | more than 3 years ago | (#34491642)

But apparently the Haskell comunity found a programmer that actually care about Haskell [blogspot.com] just last week, they are now up to 38 people. I quote:

People see words like monads and category theory," Briars continued, swatting invisible flies around his head for emphasis, "and their Giving a Shit gene shuts down...

Re:Haskell is in a similar position (0)

Anonymous Coward | more than 3 years ago | (#34491782)

To be fair Haskell was not really meant to be a mainstream language for the average Joe. It's a great vehicle for research and the benefits of some of this research have become features in languages/libraries such as Java, C# and LINQ.

Re:Haskell is in a similar position (3, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34491908)

Neither was Erlang. It was intended as a domain-specific language for writing high-availability telecoms software, which is not allowed any downtime (therefore requires live patching) and must scale to an almost arbitrary degree. It just turned out that these requirements were very similar to a lot of Internet servers.

And if you've ever written a server in Erlang and then gone back to another language, you'll really miss being able to do pattern matching on binaries.

Re:Haskell is in a similar position (1)

sourcerror (1718066) | more than 3 years ago | (#34492840)

I think Prolog deserves an honorary mention here, as that's what the first Erlang interpreter/runtime was built in. (Actually, it shows through Erlang syntax.) People usually don't know how powerful Prolog is for Domain Specific Language creation.

Re:Haskell is in a similar position (1)

da cog (531643) | more than 3 years ago | (#34493910)

Would you please explain why you think that Prolog is powerful for DSL creation? This is an honest question, because the language fascinates me and I would like to experiment using it for a project one day, but I have never run into a situation where it looked to me like writing a program in Prolog would be easier than using some other language+library.

Re:Haskell is in a similar position (1)

TheRaven64 (641858) | more than 3 years ago | (#34494096)

Prolog has very strong pattern matching functionality. The SLD derivation mechanism that it uses for term rewriting lets you almost write the grammar for your language and have it execute automatically, just write the pattern on the left of the rule and what it means on the right.

It's not a good way of writing fast language implementations, but it's a very fast way of prototyping them. It can also be used to write compilers pretty easily.

Re:Haskell is in a similar position (0)

Anonymous Coward | more than 3 years ago | (#34508748)

Prolog is a much larger language than the small amount of exposure I got in college led me to believe. Once you learn a little more uses besides database queries start to come to mind. That being said, I'd much rather write relational database queries in prolog than SQL.

Re:Haskell is in a similar position (1)

Just Some Guy (3352) | more than 3 years ago | (#34497056)

And if you've ever written a server in Erlang and then gone back to another language, you'll really miss being able to do pattern matching on binaries.

Could you give a high-level explanation on what pattern matching means here, and why I might want to do it?

Re:Haskell is in a similar position (0)

Anonymous Coward | more than 3 years ago | (#34497630)

without pattern matching:

f x =
      if x equals 1
          print "hi"
      else
          print "bye"

with pattern matching:

f 1 = print "hi"
f _ = print "bye"

(note that the order matters, if f x is first, then f 1 would never be chosen).

So basically, its a way to define functions piecewise, which is nice syntactically. It's especially nice when your language has Algebraic Data Types.

Re:Haskell is in a similar position (1)

sourcerror (1718066) | more than 3 years ago | (#34498908)

I guess what GP didn't understand was the "binaries" part. I mean, Erlang runs in a virtual machine.

Re:Haskell is in a similar position (1)

TheRaven64 (641858) | more than 3 years ago | (#34499440)

Erlang has a binary type, which is basically a blob of data. You can define patterns on a variable of this type with double angle brackets, so you can put stuff like this as an argument to a case statement:

<<1:32/big, UUID:128, Data/binary>> -> handlePacket(UUID, Data)

This would match a packet that starts as a 32-bit, big-endian, value of 12 and then contains at least 128 more bits. The next 128 bits would be stored in the variable UUID, while the remainder would be in the variable Data. You can add other variables and constants to the binary pattern. For most network protocols, you have a packet header which has a fixed layout, with some flags defining what some of the fields mean. With Erlang, you can trivially define a pattern that decomposes these based on the value of the flags.

Erlang can also do pattern matching in functions, so you can define a single function with different implementations that are called when the argument matches specific patterns. These patterns can be at bit granularity, so you can specify each flag in a bitfield independently if you need to, but they can also span large ranges in the packet so you can extract a payload easily.

The binary type in Erlang is one of its nicest features, in my opinion. It makes implementing network protocols trivial. I've implemented code for communicating between Erlang and C over a network and the C code ended up being well over ten times longer than the Erlang code. Oh, and the Erlang code scaled quite happily up to a 64 processor machine without any real effort towards scalability on my part.

Re:Haskell is in a similar position (1)

Just Some Guy (3352) | more than 3 years ago | (#34500118)

I think I see what you mean and how that'd be nice, but I admit that I kept thinking "kind of like a C struct!" while reading it. It might be like wondering why you'd ever want a program to modify its own parse tree and why Lisp macros are such a big deal to those who have used them: until you've had them, you don't really miss them.

Re:Haskell is in a similar position (1)

TheRaven64 (641858) | more than 3 years ago | (#34500966)

but I admit that I kept thinking "kind of like a C struct!" while reading it

C structures are like Erlang tuples. Binaries are like byte arrays. Consider the trivial problem of parsing and handling a packet from a network in C. The read() or recv() function gives you an array of bytes. You then have to construct a struct from it. You can do this by casting it to a packed structure, but then you still have endian problems and you typically have a performance penalty from the unaligned loads and stores. Then you have to have a bunch of if or case statements to find out exactly what kind of packet it is, typically followed by some more casting to handle the fields of the structure that depend on the values in the header. Then you have to dispatch it to the function that handles it.

In Erlang, this entire sequence of operations is a single line. You define each possible layout for a packet as a pattern, with the flags that define the layout as constant values and the remaining fields as variables. When you receive a packet matching one of these patterns, it will automatically have all of the fields in the header decomposed for you, and you can construct a tuple from them trivially. For example, if you wanted to write something that handled TCP SYN packets in Erlang (and didn't want to use use the normal TCP support), you could just write a line like this:

<<SourcePort:16/big, DestinationPort:16/big, SeqNum:32/big, AckNum:32/big, DataOffset:4/big, _:4, CWR:1, ECE:1, URG:1, ACK:1, PSH:1, RST:1, 1:1, FIN:1, Packet/binary>>
-> ...

Now try doing the same thing in C. First, C has no bit type, so you'd need to get the byte corresponding to the flags field and then mask it to get the SYN flag. Then you'd need to decompose each of the other fields with some pointer arithmetic and a ntoh{s,l}() call.

The pattern matching behaviour makes this kind of thing very flexible, because you can do things like first have a pattern where the SYN and ACK flags are both set, then have one where the SYN flag is set and the ACK flag is not set and have them match differently. If there is some combination of flags that is not allowed, then you can put a pattern that matches that first, and discard the packet immediately (or do some other error handling behaviour).

Typically you wouldn't use this for TCP, because your OS already has a TCP stack, but it's great when implementing new protocols on top of UDP. The pattern matching is also good for other parsers. For example, a simple XML parser in Erlang is about 5 lines of code - I wrote a toy messaging system that sent XML messages around a network in about 40 lines of Erlang code, which lets you understand why the Jabber server written in Erlang is the most popular XMPP server, and the one with the most features.

It might be like wondering why you'd ever want a program to modify its own parse tree and why Lisp macros are such a big deal to those who have used them: until you've had them, you don't really miss them.

I think anyone who's ever come up against the limitations of the C preprocessor realises why this is useful...

Re:Haskell is in a similar position (1)

alexo (9335) | more than 3 years ago | (#34501662)

Now try doing the same thing in C. First, C has no bit type, so you'd need to get the byte corresponding to the flags field and then mask it to get the SYN flag.

Technically, C has bit fields [gbdirect.co.uk] although in practice they are best avoided due to the alignment and ordering being implementation defined.

Re:Haskell is in a similar position (1)

TheRaven64 (641858) | more than 3 years ago | (#34502512)

C bit fields are really just a way of cramming limited-range integers into a structure to save some space, they're not usable for manipulating bits (and C, of course, in spite of being a 'low-level' language doesn't expose the CPU's native bit manipulation operations to the programmer, unless you want to use compiler-specific intrinsics...).

D used to have a bit type, which was a lot more useful. You could define arrays of bits and then manipulate individual bits as if they were arrays of any other type. You could also use pointer casts to access individual bits in other values. For some reason, apparently the bit type was dropped in later versions of the language.

Re:Haskell is in a similar position (0)

Anonymous Coward | more than 3 years ago | (#34505052)

Thanks! This is what reading slashdot used to be like. (before september)

Re:Haskell is in a similar position (0)

Anonymous Coward | more than 3 years ago | (#34509110)

Imagine a Diracted Acyclic Graph (DAG) structure implemented in a very generic way so that it can hold just about anything. You could use this DAG to hold a binary tree, a linked list, or may other things.

Now imagine that in addition to regular data that you are used to storing in abstract data types, you are also able to store wild cards in this generic DAG. And you are able to store less wild cards as well -- like regular expression patterns or "any number less than 6" type expressions. Then you have an operation that you can do with with the one of these DAGs with regular data and one of these special DAGs that has the pattern expressions in it, and the result of this operation is a boolean value to tell you if the pattern matches the DAG. For the pattern to match it must match both the structure and all of the expressions have to match.

Now imagine that in addition to just getting the boolean result that says "match" or "no match" you have the ability to have some code execute conditionally if the pattern matches (nothing special here), but referencing the data that matched some or all of your wild cards or patterns (similarly to the way this is done for regular expressions in perl, sed, ...).

Now imagine that instead of just one piece of code that gets executed based on a pattern match you have a series of patterns, each with their own code that references values from the DAG that matched, and only the first one that matches is executed (similar to lex rules, but not quite because it does the longest first match). Oh, except that saying "executed" may be misleading in Prolog in many cases.

Now imagine that instead of just comparing 1 DAG at a time to the pattern expression DAG you compare a set of DAGs to the pattern DAG and instead of a match you get a set of matches. In prolog each member of the set is examined in tern (unless you make it not do so interactively or with a cut), but you can often think of it as having a reference to a set of matches rather than just one (unless it is the empty set).

This is the best explanation I could come up with for this for someone who has never touched prolog, and even if you had you might not recognize that what I have described here is equivalent (unless I've made errors) to its queries. This explanation probably fits better in some places to Lisp pattern matching, but they are mostly equivalent once you get past the syntax and vocabulary.

Re:Haskell is in a similar position (1)

anonymous cupboard (446159) | more than 3 years ago | (#34499818)

It is getting some interest for financial services such as trading and trade processing - again online patching is great as is the built in messaging and scalability.

Re:Haskell is in a similar position (1)

icebike (68054) | more than 3 years ago | (#34495728)

I've been batting nearly 1000 over the last many decades dismissing each new wiz language that comes along.

(Ok, two failures out of a career.)

So I guess I'll dismiss this one as well.

The problem is that even when a language comes along that is perfectly suited foe some specific task, adopting it means 6 months of writing crappy code because you don't yet understand the language, and 6 years trying to find some one to maintain the system once its completed.

The time is far better spent canning some routines in a main stream language you know well to do those few tasks that the new language excels at.

Its far more portable, maintainable, and understandable.

When your Erlang programmer walks out the door, your system just became unmaintainable.

Re:Haskell is in a similar position (2)

Tetsujin (103070) | more than 3 years ago | (#34492232)

But apparently the Haskell comunity found a programmer that actually care about Haskell [blogspot.com] just last week, they are now up to 38 people. I quote:

Blah. Can't feel a lot of respect for any programmer who doesn't cultivate an appreciation for different styles of expression. To me that's a fundamental aspect of improving myself as a programmer.

Still, the bit about "hired a Perl hacker" was funny. For sure one of the big temptations in thinking too hard about programming is failing to get anything done. :)

Re:Haskell is in a similar position (1)

Kagetsuki (1620613) | more than 3 years ago | (#34495730)

Whoever ranked the parent a Troll is either devoid the ability to sense humor or somehow is a Haskell fan that just happened to have mod points. Face it, Erlang, Haskell, and even OCaml are not popular languages outside of the mathematical and scientific communities. Even I as a programmer tried to pick up all three, to a degree succeeded in learning the syntax and grasping the concepts, but hit a dead end when I found out all three are missing many things that are required to create actual real world applications - and these were all things that would have been there had there actually been a community around the project. Reasonable graphics intrefaces (set up and use an OpenGL window natively), CGI and managed database adapters, libraries to handle video and audio data. Sure languages like OCaml allow you to make abstractions to C/C++ libraries and headers but if we're going that far just use C/C++ to begin with.

Re:Haskell is in a similar position (1)

NateTech (50881) | more than 3 years ago | (#34497744)

Actually wasn't Erlang written for and successfully used by Ericsson in telco control and/or billing software with some insanely low amount of system down-time? Never figured out why the more business-minded innovative leaders in software didn't pick up on that and find some programmers willing to drop their prima-donna loves for mainstream languages to give writing some other software in it to see if the results for uptime could be duplicated.

Re:Haskell is in a similar position (-1)

Anonymous Coward | more than 3 years ago | (#34498348)

If you think there's such a thing as "C/C++" your opinion is worthless.

Re:I'm sure that both Erlang programmers... (2)

TheRaven64 (641858) | more than 3 years ago | (#34491820)

I doubt it. Erlang has pretty good documentation. There's a book that you can download that describes the core language and parts of OTP, and the various OTP modules all have detailed documentation. When I learned Erlang, the idea of buying a book about it never really occurred to me. The language itself is pretty tiny (and sufficiently similar to Prolog that it's easy to pick up). I've written a couple of concurrent server apps with Erlang, although I wouldn't describe myself as an Erlang programmer. Maybe someone who only knows Java would find a book like this useful, but a rounded programmer should find Erlang pretty trivial to learn without one.

Re:I'm sure that both Erlang programmers... (0)

Anonymous Coward | more than 3 years ago | (#34494708)

I can count the number of programmers sufficiently rounded enough to consider learning a functional language "trivial" on my fingers.

Signed,
Cap'n Hook.

Re:I'm sure that both Erlang programmers... (1)

TheLink (130905) | more than 3 years ago | (#34498804)

I can count the number of programmers sufficiently rounded enough to consider learning a functional language "trivial" on my fingers.

I think there are lot of very rounded programmers around here. Especially around the midriff.

They've all experienced much personal growth and have stretched their limits many times. They carry a lot of weight in any discussion.

Re:I'm sure that both Erlang programmers... (1)

TheRaven64 (641858) | more than 3 years ago | (#34499462)

Really? There's nothing especially complicated about functional languages, and once you've learned one, then learning the next one is pretty easy. I don't think someone could describe themselves as a rounded programmer if they've only ever used imperative languages. Oh, and going from Prolog to Erlang is probably easier than going from something like Haskell to Erlang (more similar syntax, type system, and pattern matching semantics), and Prolog is one of the languages that I'd expect anyone who wants to call themselves a programmer to have at least played with.

Re:I'm sure that both Erlang programmers... (0)

Anonymous Coward | more than 3 years ago | (#34491916)

You mean all three of them---someone reviewed the book by one of the other three programmers; and it wasn't the guy who wrote the FIRST book..

first_post(_) - false. (0)

Anonymous Coward | more than 3 years ago | (#34491482)

ahh, fuck it.

Well, damn (0)

Revotron (1115029) | more than 3 years ago | (#34491492)

I was heavily considering writing a book on Erlang. It's a good thing I didn't. God only knows what the market for Erlang publications would be like if there were THREE books to choose from!

Re:Well, damn (2)

QRDeNameland (873957) | more than 3 years ago | (#34491552)

I was heavily considering writing a book on Erlang. It's a good thing I didn't. God only knows what the market for Erlang publications would be like if there were THREE books to choose from!

Don't forget Erlang: The Movie!! [youtube.com]

Re:Well, damn (1)

larry bagina (561269) | more than 3 years ago | (#34491564)

Better get it out the door before O'Reilly publishes Erlang in a Nutshell, Head First Erlang and the Erlang Pocket Reference.

Re:Well, damn (2)

whizbang77045 (1342005) | more than 3 years ago | (#34491722)

Don't forget "Erlang for Dummies," "Son of Erlang," "Erlang Strikes Back," "The Revenge of Erlang," "House of Erlang," and perhaps most important, "Ghost of Erlang." By the way, what's Erlang?

ejabberd is written in Erlang (1)

Kupfernigk (1190345) | more than 3 years ago | (#34493944)

But if you don't want scalable, secure communications using a well established protocol, I guess you wouldn't be interested.

Erlang and Off-Topic Programming In Action? (0)

Anonymous Coward | more than 3 years ago | (#34491522)

Jeeez... one would think there are much better options for books to review.

it leaked? (0)

Anonymous Coward | more than 3 years ago | (#34491560)

it leaked?

I don't know what Erlang is (0)

Anonymous Coward | more than 3 years ago | (#34491570)

But hot damn, after reading this review, I'll buy eight!

Re:I don't know what Erlang is (0)

Anonymous Coward | more than 3 years ago | (#34492106)

You bought the ENTIRE first edition, damn you!

Mnesia (0)

Anonymous Coward | more than 3 years ago | (#34491588)

I'm interested if the book goes into a lot of detail on Mnesia. Mnesia just seems like databases done right.

Joe Armstrong is also ... (0)

Anonymous Coward | more than 3 years ago | (#34491638)

... the principle developer of Erlang and the OTP. So you'd expect his name and publications mentioned a few times.

The new 'IT' gift of 2010 (2)

digitaldc (879047) | more than 3 years ago | (#34491732)

Everyone needs more programming languages in their life this holiday season, and everyone loves Erlang!
With this book, no one will EVER guess what you gave them, it is truly original.
Pick up your copy today, makes a great stocking stuffer!

Re:The new 'IT' gift of 2010 (1)

eyenot (102141) | more than 3 years ago | (#34493186)

Doulb-plus! Even if, by some miniscule chance or miracle, they manage to guess that it's a book on Erlang you've given them without even unwrapping it, imagine how surprised they'll be when they see the cover! No-one EVER would have guessed a book on programming languages would have THAT cover!

stocking stuffer (0)

Anonymous Coward | more than 3 years ago | (#34494436)

Pick up your copy today, makes a great stocking stuffer!

Who's stocking are you putting it into? Bigfoot's?

No Thanks; I'm Too Busy As A SysAdmin (-1)

Anonymous Coward | more than 3 years ago | (#34491888)

preparing for $$$TEAM&OBAMA to shut down the Intertubes [guardian.co.uk] .

Yours In Electrogorsk,
Kilgore Trout, C.I.O.

>ping www.mastercard.com

Pinging www.mastercard.com [216.119.208.50] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 216.119.208.50:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

How odd (0)

Anonymous Coward | more than 3 years ago | (#34491922)

I just ordered this a couple days ago. Do the erlang guys know that the language makes complex science calcs a snap on distributed networks? What scientist wants to spend days programming in C when you can do stuff in a few hours instead? They should look into this.

Re:How odd (2)

TheRaven64 (641858) | more than 3 years ago | (#34492328)

Erlang's strength is scalability, not performance. If you've got something that's numerically intensive, Erlang is unlikely to give you better performance than C unless you're using a really big cluster or a supercomputer. HiPE does pretty well on floating point if you make sure that the type inference can work correctly, but even then it's not very close to C performance. That said, it's now much easier to call C from Erlang than it used to be, so you can pretty easily write the performance-critical parts in C and all of the distribution stuff in Erlang.

Re:How odd (0)

Anonymous Coward | more than 3 years ago | (#34493452)

That's the overall idea. The actual math in C is not tricky, it's the node communications stuff.

Re:How odd (1)

bigattichouse (527527) | more than 3 years ago | (#34494054)

But you can interface directly with C libraries for stuff not suited to Erlang, and then do the Erlang for the messaging and coordination.

Meh (0)

Anonymous Coward | more than 3 years ago | (#34492174)

Erlang sucks. C++ and Boost.MPI [boost.org] is better.

...OK just kidding. Erlang's a neat language. C++ is one of those things you wouldn't wish on your worst enemy, although it's occasionally very interesting what people achieve with it. I hope more programmers will throw aside their initial fear and learn how fun (and easy) functional programming really is.

OTP? (1)

bar-agent (698856) | more than 3 years ago | (#34492972)

OTP? "One True Pairing?"

Re:OTP? (0)

Anonymous Coward | more than 3 years ago | (#34493538)

"One Time Pad" see also LMGTFY

Re:OTP? (3, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34494038)

Open Telecom Platform. Erlang was created for writing telephone switching systems, and so the standard library that it comes with was named with this in mind. It's a bit of a silly name now, because it contains a load of stuff that would be no use for telecoms, but which are pretty useful in other situations.

The cover (1)

eyenot (102141) | more than 3 years ago | (#34493110)

That does NOT look like a good cover for a book on computer programming!!!

Re:The cover (0)

Anonymous Coward | more than 3 years ago | (#34494678)

All of the Manning books have such a cover. Maybe you don't immediately recognize it as a computer programming book, but anyone who has even read one of the other Manning books will immediately recognize it. And they're good.

You must have both Erlang books... (1)

Anonymous Coward | more than 3 years ago | (#34494086)

...so you can read them concurrently.

Erlang x Manning OTP (2)

Peganthyrus (713645) | more than 3 years ago | (#34494442)

What with being more up on the activities of fan-fiction authors than the activities of the Erlang world (it's really a fine slicing of 'vaguely aware of' for both), I keep wanting to read "OTP" as "One True Pairing", and wonder who Erlang is supposed to be having an imagined relationship with.

I'm not sure I want to google for the real meaning of OTP in this context. I kinda like the mental images.

Mnesia is unstable on Ubuntu 10.04 (2)

msobkow (48369) | more than 3 years ago | (#34494796)

Just a warning for anyone thinking of picking up Erlang programming. The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.

Re:Mnesia is unstable on Ubuntu 10.04 (1)

Anonymous Coward | more than 3 years ago | (#34496114)

The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.

Well it lost the 'a' from the front of of its name, so it's no wonder it forgets stuff.

Re:Mnesia is unstable on Ubuntu 10.04 (1)

Mattias (24907) | more than 3 years ago | (#34497918)

Just a warning for anyone thinking of picking up Erlang programming. The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.

Do you have any references for this? I have used Mnesia on Ubuntu 10.04 and I haven't lost any data yet. However, I am about to use this combination on a mission-critical system so I really need to know if there is a problem.

The free version of book (0)

Anonymous Coward | more than 3 years ago | (#34499300)

Here is the version of this book for people who haven't money http://www.wowebook.com/java/erlang-and-otp-in-action.html

Dont forget "Erlang Programming" (1)

BigTom (38321) | more than 3 years ago | (#34499478)

Dont forget "Erlang Programming" http://oreilly.com/catalog/9780596518189/. Its been out for a while

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?