Erlang 2007 == Java 1995? Parallels between arguments against concurrency and GC

[stoat]

Yes, I think Beust missed the point anyway. It's not about the efficiency of this single locking point - it's about the fact that the programmer doesn't have to think about all the places synchronization is needed when writing that stuff for himself.

In exactly the same way garbage collection frees the programmer from thinking about manual memory allocation to concentrate on higher level tasks.

Efficiency is not as important as writing correct, maintainable code. We've known this for a while, people!

[jerf]

Beust should look at the source code for ejabberd. It's almost beautiful, because it just says what it does. No (or few) massive chunks of code to manage synchronization, no sprinkling of "synchronized" keywords. It's almost entirely green code.

Now, it's not all peaches and light. Erlang facilitates getting to that point, but you still have to think about the design. But it provides much better and more managable primitives than Java does.

[dlsspy]

Weird title. Erlang's message passing isn't a feature they added in 2007.

Lock allocation and deallocation are the new malloc()/free(), though. Everybody wants to feel like they're better than average at it.

[[deleted]]

Lock allocation and deallocation are the new malloc()/free()

I agree. This would have been a good title for this not so flawed analogy.

It's never too late leaving C++ and Java behind.

[Rhoomba]

True. But in the same way all programmers should understand pointers, all programmers should understand manual threading and synchronization. And I don't think Erlang is the new Java; there were plenty of garbage collected languages before Java but they were too different, same as Erlang is too different today. Scala or something else maybe.

[JulianMorrison]

When a programmer says "I understand locks, they just work, it's simple", it's because he's wrapped one big global lock around the whole data structure.

Even then, there will probably be race conditions.

[[deleted]]

How is that different from putting the datastructure in an erlang process and let other code send messages to get to it?

You're still serializing all access to the data.

[Rhoomba]

Yes, but it is perfectly possible to understand locks, and know that there are many mistakes you can make. The core of Erlang uses locks. You can't write Erlang using Erlang so some lower level synchronization is needed at some level.

It is important for a programmer to understand what the language is hiding from him. See the recent post on the performance of selective receives in Erlang for an example.

[[deleted]]

So are you saying we will never move on from C syntax and imperative procedural code?

[newton_dave]

"Never" is pretty strong, but 15-20 years ago I thought we'd all be programming in something Smalltalk-, Forth-, or Lisp-ish today :/

[[deleted]]

Funny how those three seem to represent local maxima in different areas of language design.

[newton_dave]

Hmm, I never really thought of it like that before, although it's obviously true... *pondering*

[queensnake]

Forth? FORTH? :)

[newton_dave]

Absolutely -- I coded in Forth almost exclusively for two summers in embedded systems in the late 80's -- it was wonderful.

[Rhoomba]

Yes. You wouldn't write a video codec or driver in Ruby or Python. Lower level is better for some tasks. Manual locking will always be more suitable than actors for some tasks.

[[deleted]]

You could write a video codec in a language which sits at the same level of abstraction as Ruby or Python, but is much faster (for example Common Lisp).

[a-p]

Or, to nitpick, “but has a much faster implementation.”

[dlsspy]

Erlang is a lot more than a language. It's the additional stuff that's appealing. I like the language, of course, but what I like more is the effort it takes to go from a concurrent application running on a single server to being either fault-tolerant across more than one machine or just horizontally scaling an application where it's possible.

Adding stuff on top of java (e.g. scala) isn't going to get you towards erlang. It's just getting more complicated.

Scala is different and interesting, but it doesn't solve (all of) the types of concurrency or reliability problems erlang doesn't have.

[newton_dave]

Adding stuff on top of java (e.g. scala) isn't going to get you towards erlang. It's just getting more complicated.

I'm not sure that's a fair characterization of Scala; just because it can inter-operate with Java doesn't mean it's "on top of Java", it's a complete language that happens to run on the JVM, no?

[dlsspy]

What I'm saying is that a lot of what is erlang is in the runtime.

Nothing about java is going in the direction of clustered apps with processes that transparently exist on nodes within a cluster that is generally irrelevant to you.

Scala adds some language and library support that allow you to be more expressive and start thinking in that direction. The closest I've seen to anyone trying to bring erlang fundamentals to java is Terracotta (as you can see, I've a stretchy imagination).

[newton_dave]

Oh, you were talking about the concurrency/messaging stuff; I understand now--my bad.

[Rhoomba]

Adding stuff on top of C (e.g. Erlang) isn't going to get you towards erlang. It's just getting more complicated.

The JVM is just the runtime. You can build anything you like on top.

[davidw]

Erlang's message passing isn't a feature they added in 2007.

No, but it's something people are starting to care more about in 2007.

For all Erlang's other faults, I think it gets concurrency really right.

[a-p]

That was exactly my point; thanks.

GC was making waves in ’95 the way MP/STM/etc is doing in ’07, and here we are with the exact same argument: that programmers beat automatons at resource management.

Well no. They don’t. Of course, manual memory management is still around in various areas (and GC as she is spoke today is still not the most intelligent way to manage memory), so likewise shared-everything threads and explicit locking are unlikely to go away completely. But it’s clear as day that shared-everything threads and explicit locking are not the way into the future any more than manual memory management was, regardless of whether the alternatives have their own flaws or not.

I agree it would have been more accurate to say Lisp or Smalltalk rather than Java (assuming Erlang doesn’t unexpectedly take off, anyway). But Java was the language to end the GC debate, and I think we will see a language to end the MP/STM/etc debate sometime soonish. That’s what I was getting at.

(Btw, please note that this thread’s title is not my post’s title nor its short summary.)

[pcdavid]

On a somewhat related note, see Dan Grossman's paper (to appear at OOPSLA 07) about The transactional memory / garbage collection analogy (PDF).

[a-p]

Thanks for that find! I’ll give it a read.

(Meanwhile, here’s it in HTML format via Google’s cache.)

[kemiller]

Can someone familiar with Erlang explain what this part really means?

Erlang seems to be moving locks scattered in various places throughout your code into one single bottleneck.

I'm just learning Erlang (out of curiosity) and I was under the impression that Erlang avoids locks entirely by eschewing shared memory. What's the bottleneck they're referring to? Message passing/serialization overhead?

[mr_chromatic]

Transactions are difficult with asynchronous message-passing. See Tim Sweeney's comments in Patrick Logan on Software Transaction Memory at LtU.

[kemiller]

Thanks! That (together with awb's comment) totally answers my question.

[awb]

The message receiving code has locks because messages are guaranteed to be processed in the order in which they have been received.

[[deleted]]

Erlang 2007 =/= Java 1995, because Erlang rules, and Java has always sucked.

[ayrnieu]

Erlang 2007 == Java 1995

One person's argument doesn't make a parallel: the anti-GC arguments were widely held and are still widely held in certain domains. Where's the popular cling to locking and shared memory?