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!

Scaling Large Projects With Erlang

Soulskill posted more than 6 years ago | from the right-tool-for-the-right-job dept.

Programming 200

Delchanat points out a blog entry which notes, "The two biggest computing-providers of today, Amazon and Google, are building their concurrent offerings on top of really concurrent programming languages and systems. Not only because they want to, but because they need to. If you want to build computing into a utility, you need large real-time systems running as efficiently as possible. You need your technology to be able to scale in a similar way as other, comparable utilities or large real-time systems are scaling — utilities like telephony and electricity. Erlang is a language that has all the right properties and mechanisms in place to do what utility computing requires. Amazon SimpleDB is built upon Erlang. IMDB (owned by Amazon) is switching from Perl to Erlang. Google Gears is using Erlang-style concurrency, and the list goes on."

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

Erlang: The Movie ! (5, Funny)

Enlightenment (1073994) | more than 6 years ago | (#24074403)

They were right! [youtube.com]

Sufficiently? (5, Interesting)

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

Perhaps the systems would be better running efficiently rather than sufficiently?

self sufficient? Re:Sufficiently? (1)

Fubari (196373) | more than 6 years ago | (#24075711)

I read that as "If you want to build computing into a utility, you need large real-time systems running as self sufficiently as possible."

FP (-1, Offtopic)

s1283134 (660354) | more than 6 years ago | (#24074411)

First Post!

Perl + erlang (0)

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

Perlang

hard to read after (1)

puto (533470) | more than 6 years ago | (#24074447)

"you need large real-time systems running as sufficiently as possible."

Should that not be efficiently as possible?

Re:hard to read after (5, Funny)

jc42 (318812) | more than 6 years ago | (#24074567)

"you need large real-time systems running as sufficiently as possible."

Should that not be efficiently as possible?

You obviously haven't looked very closely at any of the "market leader" software lately.

Software from the Big Guys is more and more designed to sell (think forced upgrades) bigger, faster systems. You don't do this by making your software efficient.

The logic behind many software updates these days is "Will this release require sufficient resources that customers will be persuaded to upgrade to new hardware?"

Re:hard to read after (2, Funny)

The End Of Days (1243248) | more than 6 years ago | (#24074575)

You obviously don't read summaries, articles, or headlines. The logic behind your post is "rant about something for no reason at all."

Re:hard to read after (1)

antifoidulus (807088) | more than 6 years ago | (#24075271)

You obviously don't read summaries, articles, or headlines. The logic behind your post is "rant about something for no reason at all."

Dude, if you threw out all those posts, each story would have what, maybe 10 comments per story at most? And yes, I'm guilty of the above sin, quite often actually :P

Re:hard to read after (1)

antifoidulus (807088) | more than 6 years ago | (#24075285)

And if you threw out posts with redundant grammar in them, you would have even less posts per story!

Re:hard to read after (1)

Nursie (632944) | more than 6 years ago | (#24074795)

I work for one of the "Big Guys".

We spend a lot of time looking at efficiency and trying to do more with what we've got. This is because we're interested in selling software for everyone's hardware and not just our own. You can't get everyone to switch to exclusively our stuff, but we can still get into their operations by being the best.

Re:hard to read after (1)

orasio (188021) | more than 6 years ago | (#24074901)

Maybe efficiency is not the main goal.
We are talking about utility-like quality of service.
That is not necessarily efficient.
I am sure the power grid would be much more efficient if it didn't have to account for peak usage. But they do, because their core value is not efficiency, but high availability.
I don't know if the guy meant something like that, but "efficiency" is not the right word here, either.

Re:hard to read after (1)

davester666 (731373) | more than 6 years ago | (#24076039)

Quick, somebody forward this article to twitter!

Erlang! It's Concurrently Sufficient! (0)

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

I mean, It's Sufficiently Concurrent!

...wait, what?

Bingo! (0)

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

Buzzwords that matter.

Huh? (4, Insightful)

The Breeze (140484) | more than 6 years ago | (#24074463)

"The two biggest computing providers of today"?

What the hell does that mean?

Also, is it just me or does the article intro sound like it was written by someone who has taken way too many marketing classes?

Re:Huh? (2, Insightful)

augustwest2112 (620733) | more than 6 years ago | (#24074627)

Also, is it just me or does the article intro sound like it was written by someone who has taken way too many marketing classes?

Too many marketing classes and not enough English classes.

Re:Huh? (3, Insightful)

fermion (181285) | more than 6 years ago | (#24075397)

Definitely market copy. Extremely general, not useful information, indiscriminate name dropping, with unintended consequences.

For instance, by dropping the imdb name, it is now my impression that this Erlang thing is best at destroying otherwise useful sites by making them less reliable and more annoying to users. Who in their right mind would want to do that. Oh, marketing people, thats who!

Re:Huh? (1)

SolitaryMan (538416) | more than 6 years ago | (#24075519)

In the article the guy says he is a consultant. This explains everything

Moore's Law (0, Offtopic)

ryanscottjones (851460) | more than 6 years ago | (#24074471)

Eh... Moore's Law says that we'll all be on the same processor in a couple years anyway.

Re:Moore's Law (0)

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

It does?

Re:Moore's Law (1)

ryanscottjones (851460) | more than 6 years ago | (#24074533)

It does?

Sigh... no, it doesn't.

Re:Moore's Law (1)

uassholes (1179143) | more than 6 years ago | (#24075065)

Of course it does. Haven't read about Jupiter Brains and The Singularity. We'll all be disembodied minds swimming in Computronium eventually.

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

Anyway, I think that the webertubes need a condescension filter to block the passage of "Sigh..."

Re:Moore's Law (1)

ryanscottjones (851460) | more than 6 years ago | (#24075191)

Exactly. That was pretty much my tongue-in-cheek point. The greater our processing power, the less we need things like Erlang. Follow that out and you have your Computronium. Don't really see how this is "offtopic," but I'm over it.

Proprietary? (2, Insightful)

2stein (871221) | more than 6 years ago | (#24074497)

TFA states "Because I don't want to be hooked into the (proprietary) Google stack (Python, Django, BigTable, GoogleOS) just yet" ... IMHO neither Python nor Django are proprietary. Or even proprietary in a way that the AWS stack is not?

Who wrote the summary? GWB? (5, Funny)

Junior J. Junior III (192702) | more than 6 years ago | (#24074537)

"running as sufficiently as possible"?

Sometimes as a nation we must ask ourselves, is our children learning?

Re:Who wrote the summary? GWB? (0)

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

Well, are they?

Re:Who wrote the summary? GWB? (0)

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

Man this thread seems to have had a can of *whoosh* unleashed upon it. GP was quoting a GWB speech [youtube.com] .

Re:Who wrote the summary? GWB? (1, Interesting)

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

Oops, wrong link. I isn't learning.

http://www.youtube.com/watch?v=aAUrToY33tI

Scala (5, Informative)

fils (88044) | more than 6 years ago | (#24074545)

People may also want to check out Scala at:
http://www.scala-lang.org/ [scala-lang.org]

It also uses the Erlang style concurrency approach and runs on the JVM with class compatibility with other JVM languages, ie Java, Groovy, etc.

Re:Scala (4, Informative)

bonefry (979930) | more than 6 years ago | (#24074725)

There is a significant difference between Scala and Erlang.

Erlang uses green threads. And green threads have advantages and disadvantages over native threads.

For instance Erlang is bad at IO but on the other hand it can spawn millions of threads, something that the JVM has a hard time doing because native threads are limited by the kernel.

Re:Scala (3, Informative)

jonabbey (2498) | more than 6 years ago | (#24075005)

Modern JVMs on the modern Linux Kernel can spawn quite a hellacious amount of threads these days, actually.

The problem with Java is the shared-state synchronization that is often necessary, and the extra work required to distribute state to threads across different VMs. A functional language and programming style could work quite well on top of the JVM, though, and could leverage RMI and some kind of message port facility for the distribution.

Re:Scala (1)

metaconcept (1315943) | more than 6 years ago | (#24075393)

Modern JVMs on the modern Linux Kernel can spawn quite a hellacious amount of threads these days, actually.

Thousands? Or millions, like Erlang?

Mozart/Oz (1, Informative)

synthespian (563437) | more than 6 years ago | (#24075689)

http://www.mozart-oz.org/ [mozart-oz.org]

I'll just cite another "competitor":


"The Mozart Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of a decade of research in programming language design and implementation, constraint-based inference, distributed computing, and human-computer interfaces. As a result, Mozart is unequalled in expressive power and functionality. Mozart has an interactive incremental development environment and a production-quality implementation for Unix and Windows platforms. Mozart is the fruit of an ongoing research collaboration by the Mozart Consortium.

Mozart is based on the Oz language, which supports declarative programming, object-oriented programming, constraint programming, and concurrency as part of a coherent whole. For distribution, Mozart provides a true network transparent implementation with support for network awareness, openness, and fault tolerance. Mozart supports multi-core programming with its network transparent distribution and is an ideal platform for both general-purpose distributed applications as well as for hard problems requiring sophisticated optimization and inferencing abilities. We have developed many applications including sophisticated collaborative tools, multi-agent systems, and digital assistants, as well as applications in natural language understanding and knowledge representation, in scheduling and time-tabling, and in placement and configuration."

Why Erlang Matters (5, Insightful)

mpapet (761907) | more than 6 years ago | (#24074555)

1. Multicore ready.
Erlang will use them. Write your application in Erlang and it's done for you.

2. Scales well.
As an example, http://yaws.hyber.org/ [hyber.org] scales very nicely when loads increase. Your basic LAMP/LYMP setup runs much better on vanilla hardware.

3. Designed for telecom
The architects designed the language to run in a telecom environment so things like upgrades can be done while the application is running.

Yaws in particular needs your help. Failover clustering inside the yaws server would be wonderful. Right now, it uses CGI to process other languages. It does it flawlessly, but a more direct solution might be a nice project.

Why Erlang doesn't matter (5, Interesting)

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

1. Invariable variables.
This appears to have been done for no reason other than the designer's preference. In fact, it's not strictly true -- variables can be unbound, and later bound. They just can't be re-bound once bound.

2. Weird syntax.
Why, exactly, are there three different kinds of (required) line endings? It seems as though the syntax is designed to be as different from C as possible, while maintaining at least as many quirks. Moreso, even -- when constructing normal, trivial programs, you're going to hit most language features head-on and at their worst. Where's my 'print "hello\n"' that works most other places?

I don't believe the important features of Erlang are mutually-exclusive with the sane syntax of, say, Ruby or Python.

3. Not Unicode-ready.
Strings are defined as ASCII -- maybe latin1. But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.

There are other things I haven't mentioned, mostly implementation-specific -- things like the fact that function-reloading cannot be done when you natively-compile (with hipe) for extra speed. My plan is to take the features I actually like from Erlang and implement them elsewhere, in a language I can actually stomach for its real tasks.

Re:Why Erlang doesn't matter (0)

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

Strings are defined as ASCII

IIRC, Erlang doesn't have actually have strings, it has character lists where every char is stored as a 32 bit int plus a pointer to the next char (8 bytes per char). If you're primarily concerned with processing text, it's the wrong tool for the job.

Re:Why Erlang doesn't matter (2, Interesting)

zmooc (33175) | more than 6 years ago | (#24074989)

Though I agree with you on 2 and 3, I'm not so sure about 1, but I might be wrong on that. As I understand it, you should look at variables in functional programming languages like Erlang more like those in a mathematical formula; such programs can be proven correct a lot easier, and since variables are effectively immutable, it facilitates forking the line of execution in a way that would not be possible without all kinds of semaphores and other concurrency stuff than if variables where not immutable. You should see this practice more like taking "pure functions" (http://en.wikipedia.org/wiki/Functional_programming#Pure_functions) to another level, namely to within functions themselves.

But I might be wrong, if so, please educate me:)

Re:Why Erlang doesn't matter (4, Interesting)

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

As I understand it, you should look at variables in functional programming languages like Erlang more like those in a mathematical formula; such programs can be proven correct a lot easier, and since variables are effectively immutable

All of this is based on the premise that Erlang is a functional language. It's not purely-functional, and I just don't see the point of doing it half-assedly. Erlang is effectively an imperative language dressed up like a functional language.

And they're not immutable -- they can be unbound. As I understand it, this unboundedness is detected at runtime, not compiletime. If it was detected at compiletime, you'd have a valid point.

it facilitates forking the line of execution in a way that would not be possible without all kinds of semaphores and other concurrency stuff

Except that's not how Erlang does concurrency. It does concurrency with explicit "processes" (green threads) and message-passing.

Now, it does make these very easy, and you can get it to distribute processes among a few real OS threads (one per core) -- so it's still very cool. But you're thinking of languages like Haskell, which can be automagically threaded. Erlang is manually threaded, it's just much easier to think in threads (or "processes") -- they're effectively a language feature.

Re:Why Erlang doesn't matter (1)

aconbere (802137) | more than 6 years ago | (#24075715)

As I understand it, you should look at variables in functional programming languages like Erlang more like those in a mathematical formula; such programs can be proven correct a lot easier, and since variables are effectively immutable

All of this is based on the premise that Erlang is a functional language. It's not purely-functional, and I just don't see the point of doing it half-assedly. Erlang is effectively an imperative language dressed up like a functional language.

OH come on this is bullshit. Even lisp and scheme aren't "purely functional" the fact that the actor model breaks the functional model clearly makes almost no difference in practice.

And they're not immutable -- they can be unbound. As I understand it, this unboundedness is detected at runtime, not compiletime. If it was detected at compiletime, you'd have a valid point.

it facilitates forking the line of execution in a way that would not be possible without all kinds of semaphores and other concurrency stuff

Except that's not how Erlang does concurrency. It does concurrency with explicit "processes" (green threads) and message-passing.

Now, it does make these very easy, and you can get it to distribute processes among a few real OS threads (one per core) -- so it's still very cool. But you're thinking of languages like Haskell, which can be automagically threaded. Erlang is manually threaded, it's just much easier to think in threads (or "processes") -- they're effectively a language feature.

Re:Why Erlang doesn't matter (4, Informative)

stonecypher (118140) | more than 6 years ago | (#24075013)

1) Actually, there are quite a few good reasons for this, largely around the complete elimination of mutexing and locks. Just because you don't understand the purpose doesn't mean there wasn't one.

2) Oooooh, a language is faulty because it has a syntax with which you are not familiar. Immediately kill all non-Java clones!

3) They're just lists of numbers; they're neither ASCII nor Latin1. There is unicode parsing in the XMERL module.

Please wait until you know a language before criticizing it.

Re:Why Erlang doesn't matter (3, Informative)

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

Actually, there are quite a few good reasons for this, largely around the complete elimination of mutexing and locks.

...What? No, the elimination of mutexing and locks is made possible by a shared-nothing architecture.

Oooooh, a language is faulty because it has a syntax with which you are not familiar.

Hey, I mentioned Ruby. I don't mind LISP, either.

The point is not that the language is unfamiliar, the point is that it's inconsistent (and unfamiliar) for no good reason. I use English, but I could make a lot of the same criticisms about it.

They're just lists of numbers;

In that case, the argument becomes, "Erlang has very poor text-processing, if any at all."

If Erlang has text-processing functions that are designed to operate on these "lists of numbers", then yeah, it's pretty much going to be ASCII. And how are Erlang source files read? Could be "neither ASCII nor Latin1" if you like, but they can't be Unicode unless the parser is actually Unicode-aware.

Re:Why Erlang doesn't matter (3, Informative)

aconbere (802137) | more than 6 years ago | (#24075697)

Actually, there are quite a few good reasons for this, largely around the complete elimination of mutexing and locks.

...What? No, the elimination of mutexing and locks is made possible by a shared-nothing architecture.

Oooooh, a language is faulty because it has a syntax with which you are not familiar.

Hey, I mentioned Ruby. I don't mind LISP, either.

The point is not that the language is unfamiliar, the point is that it's inconsistent (and unfamiliar) for no good reason. I use English, but I could make a lot of the same criticisms about it.

It's not that it's syntax is /inconsistent/ Erlang is actually incredibly consistent, it's just very different. Once you learn the 3 or 4 quirks that separate it from other languages those 3 or 4 quirks are very consistently applied.

Take for instance the punctuation (not line ending characters as is suggested).

Commas separated arguments in function calls, data constructors, and patterns. Periods separate functions.

Semi-Colons separate clauses. (this is the trickiest, but can be thought of as signifying the existence of multiple cases of pattern matching).

They're just lists of numbers;

In that case, the argument becomes, "Erlang has very poor text-processing, if any at all."

If Erlang has text-processing functions that are designed to operate on these "lists of numbers", then yeah, it's pretty much going to be ASCII. And how are Erlang source files read? Could be "neither ASCII nor Latin1" if you like, but they can't be Unicode unless the parser is actually Unicode-aware.

Re:Why Erlang doesn't matter (1, Informative)

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

I think you don't understand "shared-nothing". Immutable variables and objects are the core of a shared-nothing architecture. When your variables are immutable, they are not "shared state", and there can be no race conditions in accessing them.

You can have a "shared-nothing architecture" in a language with mutable variables by establishing and enforcing conventions, but then you have to think about it all the time and trust other people not to mess it up. In a language like Erlang, where all variables are immutable, a shared-nothing architecture is automatic. Your code (and more importantly, other people's code) is always automatically thread-safe and parallelizable.

Considering that thread safety is perhaps the hardest thing to achieve in traditional languages, and concurrency is the next hot topic in computer science, having it built into the language starts to sound like a good idea.

Re:Why Erlang doesn't matter (4, Insightful)

SQL Error (16383) | more than 6 years ago | (#24075463)

2) Oooooh, a language is faulty because it has a syntax with which you are not familiar.

Yes.

Where is Lisp today? Smalltalk?

On the other hand, languages that offered the same features with a familiar syntax have taken over the market.

Re:Why Erlang doesn't matter (1)

edalytical (671270) | more than 6 years ago | (#24075735)

Lisp: Emacs, Undergrad Computer Science, AI research...

Smalltalk: Objective-C, Squeak, Seaside, F-Script...

Re:Why Erlang doesn't matter (1)

magus_melchior (262681) | more than 6 years ago | (#24075997)

2) Oooooh, a language is faulty because it has a syntax with which you are not familiar. Immediately kill all non-Java clones!

What makes this rebuttal a ridiculous straw man is the fact that GP didn't even mention Java. He did mention C (with some derision), Ruby, and Python.

Here's a clue: what is familiar to you (Erlang) may have syntactic inconsistencies. Okay, so you took the time and effort to learn it, and more power to you. However, because syntax is a design decision rather than an implementation decision, it says a whole lot about the design when there are three different ways to end a statement. Perhaps next time, you could explain why Erlang was designed that way instead of responding with a useless hyperbole.

Re:Why Erlang doesn't matter (1, Funny)

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

Erlang's syntax comes from Prolog. This is not so strange with the first versions of Erlang having been implemented in Prolog. The syntax is very natural. Like the english language you have . and , doing different things. How hard can it be?

Re:Why Erlang doesn't matter (3, Informative)

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

1. Invariable variables.
This appears to have been done for no reason other than the designer's preference. In fact, it's not strictly true -- variables can be unbound, and later bound. They just can't be re-bound once bound.

On the contrary, there are very good reasons for having single-assignment variables. It makes the code more similar to plain mathematics, which makes it easier to reason about, and significantly reduces the number of programming errors. And you don't have to take that from me - there are some 20 years of experience at Ericsson and elsewhere with writing huge telecom applications in Erlang.

2. Weird syntax.
Why, exactly, are there three different kinds of (required) line endings? It seems as though the syntax is designed to be as different from C as possible, while maintaining at least as many quirks. Moreso, even -- when constructing normal, trivial programs, you're going to hit most language features head-on and at their worst. Where's my 'print "hello\n"' that works most other places?

I don't believe the important features of Erlang are mutually-exclusive with the sane syntax of, say, Ruby or Python.

The syntax is certainly different from C, Ruby, or Python, but this is because it is derived from the Prolog syntax. Furthermore, it is actually pretty systematic, once you get over those initial differences. It is a poor programmer who cannot master both worlds.

3. Not Unicode-ready.
Strings are defined as ASCII -- maybe latin1. But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.

A standard unicode library is still missing, but can be hoped for. At least, there is nothing in the basic representation of strings that prevents full unicode support (*cough* Java *cough*).

There are other things I haven't mentioned, mostly implementation-specific -- things like the fact that function-reloading cannot be done when you natively-compile (with hipe) for extra speed.

That's simply wrong. Dynamic code upgrade still works, native or not. It's the unloading of older native code from memory that is not being done (this is safe, but could be a memory leak in a very long running server).

My plan is to take the features I actually like from Erlang and implement them elsewhere, in a language I can actually stomach for its real tasks.

Well, good luck, and see you in 20 years. Meanwhile, the rest of us will be over here, getting stuff done with the language we have. For my part, I don't know anything else that lets me be as productive, at least for general problem solving.

Re:Why Erlang doesn't matter (1)

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

Furthermore, it is actually pretty systematic, once you get over those initial differences. It is a poor programmer who cannot master both worlds.

I've written a decent amount of Erlang. I can do it.

Point is, why would I want to?

That's simply wrong. Dynamic code upgrade still works, native or not. It's the unloading of older native code from memory that is not being done (this is safe, but could be a memory leak in a very long running server).

Ah, you're right.

I do consider it a fairly severe deficiency that you get to choose between interpreted bytecode and a memory leak.

Well, good luck, and see you in 20 years.

Done, in Ruby. Took a weekend. I'm polishing it now.

Re:Why Erlang doesn't matter (0)

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

I've written a decent amount of Erlang. I can do it.

Point is, why would I want to?

Given the gross misunderstandings demonstrated in your comments, you may have written some Erlang, but you sure as hell didn't understand it

Done, in Ruby. Took a weekend. I'm polishing it now.

You wrote a SMP-capable micro-stack green thread scheduler in Ruby, over the weekend? It supports transparent multi-node messaging?

Color me impressed. I've seen other implementations, such as libthread [swtch.com] , but they were written in C, using a fair bit of OS-specific assembly to support micro-stack green threads, and didn't support multi-node messaging -- just process support

If you pulled this off in Ruby, which doesn't even -support- native threads, I'll be seriously impressed -- especially given the lack of understanding inherent in your previous comments. Perhaps I misjudged you

Or, more likely, you're just another know-it-all shithead who implemented 1% of the solution to a problem you don't even understand, and are now trumpeting it on the blogowww-twittersphere.

Re:Why Erlang doesn't matter (1)

daviddennis (10926) | more than 6 years ago | (#24075493)

Since strings are just sequences of ordinary numbers, it would seem like you could develop Unicode by just using numbers in unicode character code range. A string could be a tuple with the encoding and the sequence, like this:

{ utf8, [ character1, character2 ... ] }

After reading through the documentation, my main gripe is that it's a totally different way of thinking, and so I have no clue of the first way to do what is accomplished with routine ease in other languages. The Erlang getting started guide admits that there are many things that would be, by their own admission, "impossible".

For example, the tutorial says that "guards" (conditional execution for you and me) cannot use user defined functions, to guarantee there are no side effects. Great in theory but what if you want to develop a regular expression library? How would it even be possible to do?

So what's the advantage of this language over, say, using threads in a language like Ruby or Perl? It seems to me that it's extremely difficult to master and lacks features that exist in virtually every interpreted language in existance today.

D

Get a clue! (2, Insightful)

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

It's a functional language you dolt, of course the "variables" are invariant. The only way in which it was the designers preference is that he presumably wanted all the niceties that come with declarative languages; provability, implicit parallelism, etc.

1. Invariable variables.
This appears to have been done for no reason other than the designer's preference. In fact, it's not strictly true -- variables can be unbound, and later bound. They just can't be re-bound once bound.

Why is any syntax that's not filched from C weird? Frankly I'm not that fond of C's syntax it _can_ lead to very unreadable code (Speaking as someone with 20 years experience with C). If you'd done a modicum of research you'd realise that Erlang models its syntax on Prolog, and Prolog like Lisp has very regular syntax.
Note that I'm not claiming that Erlang, or Prolog, or Lisp syntax is that great either, but by holding up C as some kind of gold standard you've automatically lost that argument.

2. Weird syntax.
Why, exactly, are there three different kinds of (required) line endings? It seems as though the syntax is designed to be as different from C as possible, while maintaining at least as many quirks. Moreso, even -- when constructing normal, trivial programs, you're going to hit most language features head-on and at their worst. Where's my 'print "hello\n"' that works most other places?

I don't believe the important features of Erlang are mutually-exclusive with the sane syntax of, say, Ruby or Python.

Not sure about Unicode, you may actually have made a valid point here.

3. Not Unicode-ready.
Strings are defined as ASCII -- maybe latin1. But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.

There are other things I haven't mentioned, mostly implementation-specific -- things like the fact that function-reloading cannot be done when you natively-compile (with hipe) for extra speed. My plan is to take the features I actually like from Erlang and implement them elsewhere, in a language I can actually stomach for its real tasks.

Comparison of functional languages? (4, Interesting)

radarsat1 (786772) | more than 6 years ago | (#24074587)

I think the summary (and article) are somewhat poorly written, but that doesn't shadow the fact that functional languages are becoming more and more interesting these days with concurrency becoming so important.

I'd like to learn one, but there are several out there.. What I'd like to see is a good in-depth comparison of different concurrent functional languages: why would I choose Haskell, or Erlang, or OCaml, for example? Are they all interpreted? (Does one exist that compiles?) Which ones support concurrency? What language features do they boast, and what are the advantages and disadvantages of these features? Do they have a complete set of libraries?

Anyone know of an article like this? I've been searching for a while. Every article on functional languages I've found seems to concentrate on a particular one, but I can't find something helping me decide which one is most worth learning.

Re:Comparison of functional languages? (3, Insightful)

AndyS (655) | more than 6 years ago | (#24074685)

Brief answer:

All three languages have both interpreters and compilers (ocaml is part of the base distribution, haskell has a number of compilers, and Erlang apparently has a compiler)

They all support concurrency, all in slightly different ways. They all have a lot of libraries.

Ocaml is sort of a functional language that includes object oriented features and also has very good performance numbers. It allows mutable updates, including arrays and references. For threading I believe it has the usual mutexes and so on, but nothing more sophisticated (but I could be wrong)

Haskell is a pure functional language. It tends to be a test bed for programming language ideas. It has some interesting features that can screw with your mind - it's lazy (which means that it only evaluates things when required), and pure (manipulating state can be interesting). It has mutex support, but also (in GHC) support for software transactional memory, which can be used to simulate erlang style concurrency.

Not really an expert on Erlang, but to my knowledge it pushes you to a 'mini-server' model, where you write each component as a mini server which then performs a single job, and you then spend most of your time sending messages to other processes. The Erlang system then distributes this across multiple machines for you and handles fault tolerance etc.

Re:Comparison of functional languages? (4, Interesting)

Richard W.M. Jones (591125) | more than 6 years ago | (#24074695)

OCaml compiles down to native code, which about 10-20% slower than C. Faster than C in a few (narrow) cases.

Haskell is also compiled to native code, but difficulties with the execution model mean it's pretty slow for any practical use.

Erlang is interpreted - the execution model is similar to Perl or Python - which means its slow on single cores, but of course the whole point of Erlang is to run in highly concurrent, distributed machines. There is a project [google.com] to use OCaml for the performance-critical, single threaded parts, and Erlang for coordinating the parallelism.

Of course, this is probably missing the point. Unless you're doing intensive numerical work, you probably don't need the performance. The real advantage of these languages is how your code will be much smaller, easier to understand, safer, and faster to write.

Rich.

Re:Comparison of functional languages? (2, Informative)

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

Just a minor correction: Erlang has native code compilation on quite a few architectures -- try the "+native" flag. Most projects seem content with just using the VM interpreter, though.

Best,
Thomas Lindgren

Re:Comparison of functional languages? (1)

shallot (172865) | more than 6 years ago | (#24075085)

The real advantage of these languages is how your code will be much smaller, easier to understand, safer, and faster to write.

YMMV, but for the typical person, Erlang code is hardly easier to understand, at least compared to a typical imperative language. There are numerous obscure parts of the syntax - such as the pushing variables onto an array [like|this] or referencing unused arguments _likethis (especially fun in arcane constructs such as having [_|likethis] in function arguments) - and obviously the general problem of being unable to randomly create "normal" variables, as well as an unhealthy addiction to tail recursion.

In my programming classes, Erlang was one of those things that no students actually *learned* - they just forced themselves to use it because it was required, but once their grade was in the gradebook, nobody ever looked back.

Re:Comparison of functional languages? (1)

larry bagina (561269) | more than 6 years ago | (#24075343)

Erlang is a functional language.

Re:Comparison of functional languages? (2, Informative)

GatesDA (1260600) | more than 6 years ago | (#24074761)

Can't point you to a comparison article, but one language you should consider is Scala. It compiles to the Java platform, and thus can interact almost transparently with existing Java code and libraries, and uses Erlang's concurrency model. It can do both functional and imperitive, object-oriented tasks. It's statically-typed, but with features I didn't think were possible outside a dynamic language, such as duck-typing (only compile-time checked!)

It's very powerful, but sometimes hard to figure out. Not my ideal language, but the closest I've found.

Official site:
http://www.scala-lang.org/ [scala-lang.org]

The busy Java developer's guide to Scala:
http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=scala+neward [ibm.com]

Scala for Java refugees:
http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees [codecommit.com]

Consider Stackless Python (0)

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

http://www.stackless.com/ [stackless.com]

I will usually bend over backward to use Python just because I find it very easy to write self documenting code. I have to maintain my own code and find it easy to work with code that I wrote years ago. In fact, my cow-irkers (who don't use Python at all) can easily follow what I've done. The language is sane enough that I can get help from C++ people if I get into a thinko. (a thinko is like a typo but way way worse) It also means that I can still help people with their C and C++ problems even though I have hardly written a line in those languages in the last couple of years.

If I had to write something concurrent, I would try Stackless Python. I looked at the mailing list archive and the project is active (so you can get help) and there are major projects that use it. It looks like it is worth checking out. (Obviously, I haven't used it yet)

Re:Consider Stackless Python (2, Informative)

GaryOlson (737642) | more than 6 years ago | (#24075559)

Erlang vs. Stackless python: a first benchmark [wordpress.com] is a very good discussion of lots of niggling details in benchmarking a concurrency language. The comments are quite good.

Re:Comparison of functional languages? (1)

bcrowell (177657) | more than 6 years ago | (#24075985)

This [defmacro.org] is an excellent article about functional programming.

Ocaml has a very good reputation. It compiles to native code, and has performance comparable to C. It's agnostic about programming style. You can use it as if it was C with garbage collection, or you can us it in an fp style, or you can mix the two. There are good libraries. Because of the way the garbage collector is designed, it doesn't support SMP to the extent that erlang does. The design of ocaml includes some conscious trade-offs of elegance for performance. In particular, strings are not lists.

Erlang's claim to fame is that any code you write will automagically take advantage of SMP.

Haskell's design focuses on elegance, sometimes at the expense of performance. It's strongly focused on the functional style.

Deceptive (1)

sentientbrendan (316150) | more than 6 years ago | (#24074591)

>The two biggest computing-providers of today, Amazon as well as Google, are building their concurrent offerings on top of really concurrent programming languages and systems

Google is largely a C++ company, a language that doesn't include explicit support for concurrency (although the next version, C++0x, will).

They mention erlang only being used in a relatively small project that most of google's own software doesn't support yet.

Note, that google gears is used in the excellent google reader software (although not much else).

Re:Deceptive (4, Insightful)

IamTheRealMike (537420) | more than 6 years ago | (#24074623)

Actually, Gears doesn't use Erlang either. What he means is that Gears threading doesn't allow for shared state (is it really threading then?). Instead threads communicate back to the browser by message passing.

It's remarkably deceptive indeed to even imply that Gears and Erlang are connected. Message passing based concurrency isn't exactly new or limited to Erlang, and can be implemented in any language.

I'm not sure what the point of this piece is. I've looked at Erlang and didn't see much of anything to get me excited. It's a functional language, which like most of them have unnecessarily weird syntax and force immutable state. I don't really see what this buys you over a language like D 2 (or hell, even C++) in which you can write in a functional message passing style if you like, but then still use imperative shared state whenever useful, convenient or performant.

Re:Deceptive (1)

Richard W.M. Jones (591125) | more than 6 years ago | (#24074717)

... force immutable state

You're probably looking for an impure functional language like OCaml. You get to use purity when you want to (it helps in reasoning about code), but drop to impurity when you need the performance.

Rich.

Re:Deceptive (1)

IamTheRealMike (537420) | more than 6 years ago | (#24074763)

Well, OK. Most functional languages I know require immutable state, but I'll look more closely at OCaml. How though, is it better than v2 of D, which appears to offer most things that functional languages offer (except perhaps an easy pattern matching syntax) but also a whole lot more?

Re:Deceptive (1)

Richard W.M. Jones (591125) | more than 6 years ago | (#24075167)

I don't really know much about D, but OCaml nowadays has loads of libraries, excellent features like macros, type safety everywhere, pattern matching, a super-powerful object system (not used very much, mind you), functors, and it compiles down to fast, tight machine code. If you use Debian or Fedora you can just 'apt-get' or 'yum install' the whole system and almost all of the popular libraries [cocan.org] .

Rich.

Gibberish (5, Insightful)

SpinyNorman (33776) | more than 6 years ago | (#24074597)

If you want to build computing into a utility, you need large real-time systems running as sufficiently as possible.

But if you want to build sprockets into a weasel you need small batch-mode systems running as necessarily as possible.

If the poster had anything interesting to say (I'd guess not, but who knows!), it was totally obscured by his lack of grasp of the English language.

Re:Gibberish (1)

Deliveranc3 (629997) | more than 6 years ago | (#24075873)

by his lack of grasp of the English language.

Lol... (/English Major)

Wrong parenthesis added for humour :P

TFA is misleading (1, Informative)

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

TFA implicitely states that Google is using Erlang or some concurrent programming languages. That's wrong: they use C++, Java and Python, and prett much nothing else (apart for specialized stuff for MacOS apps for instance).

Re:TFA is misleading (1)

Ambidisastrous (964023) | more than 6 years ago | (#24075333)

Google wrote their own language for parallelism called Sawzall [wikipedia.org] . I'm not sure where they're using it in particular (possibly as a front-end to MapReduce), but they've published some research papers about it.

Too late (3, Funny)

Fnord666 (889225) | more than 6 years ago | (#24074631)

Anyhow, this post was not intended to be a rant about old-school technology solutions vs. current and future technology problems.

Given that this statement appears almost halfway through the blog post, I would say that it was already too late for that.

Stupid article (5, Informative)

IamTheRealMike (537420) | more than 6 years ago | (#24074697)

Wow, it's not often I strongly criticise articles around here, but that was total garbage.

For the smart ones that didn't RTFA, here's a quick summary:

  • I like Erlang.
  • Big companies like Google and Amazon make things fast by using concurrency.
  • Erlang supports (one type of) concurrency.
  • Thus Google and Amazon are [probably] using Erlang.
  • Thus everyone should learn Erlang.

For the record, I work for Google and we don't use Erlang anywhere in the codebase. Google Gears restricts you to message passing between threads because JavaScript interpreters are not thread-safe, so it's the only way that can work. Visual Basic threading works the same way for similar reasons. It's not because eliminating shared state is somehow noble and pure, regardless of what the article would have you believe, and in fact systems like BigTable use both shared-state concurrency and message passing based concurrency.

The article says this:

Architects (but also university-professors for that matter) still think they can build current and future industrial-grade and internet-grade systems with the same technologies as they did 10-15 years ago.

But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.

Seeing as the article is merely an advert for Erlang, I'll engage in some advocacy myself. If you have an interest in programming languages, feel free to check out Erlang, but be aware that such languages are taking options away from you, not giving you more. A multi-paradigm language like version two of D [digitalmars.com] is a better way to go imho - it supports primitives needed to write in a functional style like transitive invariance, as well as a simple lambda syntax, easy closures and first class support for lazyness.

However it also compiles down to self-contained native code in an intuitive way, or at least, a way that's intuitive to the 99.9% of programmers used to imperative languages, unlike Erlang or Haskell. It provides garbage collection but doesn't force you to use it, unlike Java. It doesn't rely on a VM or JIT, unlike C#. It provides some measure of C and C++ interopability, unlike most other languages. And it has lots of time-saving and safety-enhancing features done in a clean way too.

Re:Stupid article (3, Interesting)

burris (122191) | more than 6 years ago | (#24075095)

I'm not going to disagree with most of your post, I think you're spot on. However, your suggestion of D is totally off. I like the D programming language quite a bit and version 2 is going to be really cool. However, even version 1 of D is not ready for prime-time [timburrell.net] . Version 2 of D is unstable and not recommended for production by even the author himself. All of the other languages you mentioned such as Erlang or Haskell are much more mature.

Also, "most other languages" have a foreign function interface for C, including Erlang, Haskell, Python, Java, Perl, Ruby, etc... In fact, I can't think of a well known programming language actually used by people other than the author that does not have an FFI... It is true that in most cases the FFI of other languages is more difficult to use than the one in D, but they are there.

Re:Stupid article (5, Interesting)

IamTheRealMike (537420) | more than 6 years ago | (#24075795)

Yes, D is very young and has problems. But then again, what language didn't? It's easy to forget but Python was first released in 1991. It took many years before it became mainstream (and some would say it's still not there yet).

The post-mortem is an interesting document, but I disagree with the authors conclusions. The compilers are buggy, well, C++ had exactly the same problem for a long time but still was a huge success. In particular, the trend seems to be basing new compilers on LLVM, which has a pretty robust optimization core. Frontend bugs are by comparison pretty trivial and easy to fix. Another few years and I think this problem will be licked - and besides, lots of C++ code has workarounds for compiler issues. Same thing for class libraries.

You're right about C-level FFIs. However D provides a simple C++ FFI which as far as I know is unique. Such a thing would be very useful for a company like Google which has a lot of C++ code, as it'd simplify binding considerably (I don't mean to imply anything about the future direction of the codebase, by the way).

The argument about parallelism is a more interesting one. But I disagree with that too :) D provides exactly what is needed for automatic sharding of work across cores (or machines). Specifically the combination of transitive invariance, reflection and purity enforcement is a very powerful one.

Essentially, if you can write your code to consist of non-trivial trees of pure functions, then it's perfectly safe to parallelise something like this:

foreach (item; list) {
    fooResults[item] = someTransform(item);
    barResults[item] = anotherTransform(item);
}

If someTransform and anotherTransform are both pure, by implication their parameters are transitively invariant, and thus they can both be invoked in parallel (because the compiler knows "item" can't be changed). What's more both calls can be invoked simultaneously as well.

Once the compiler knows these things, making this code run in parallel is simply another compiler optimization. That's the whole theory behind how functional languages can be super easy to parallelize. But in fact the key concepts can be applied to imperative languages as well, with the advantage that you can still have temporary mutable state within the function scopes - you just can't modify the heap, or anything reachable through your arguments.

D has keywords that let the compiler know and enforce function purity.

Now as it happens I doubt that any D compiler today implements this optimisation - it's sophisticated and transitive invariance is newly introduced in D2. But all the pieces of the puzzle are there. This also lets the compiler do calculations on data structures available at compile time.

Cloud computing, not internal services (1)

jmcbain (1233044) | more than 6 years ago | (#24075405)

This article is discussing the front-facing programmatic interface to cloud computing. It is not referring to the internal code of your company.

Re:Stupid article (1)

Jerry Coffin (824726) | more than 6 years ago | (#24075767)

But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.

Not to mention Sabre and the VISA credit card processing system -- both use TPF, which is a lot older than Erlang. Meanwhile, many libraries have used the Tandem/Compaq/HP Non-stop system for years -- in fact, I'm pretty sure some have been up without a single interruption since before Erlang was invented. IBM has also had CICS for decades as well; IIRC, it's used by quite a few banks and hotel reservation systems. Likewise, substantial parts of the updates to the Air Traffic Control system currently in progress are being written in various older languages (more in Ada than any other, but it's certainly not the only one).

Now, don't get me wrong: none of these is a panacea for scalable programming. Nonetheless, the people who think they can create highly scalable systems using technology that's a lot more than 10 or 15 years old have some pretty good support. In fact, I can't think of a single really large scale system developed using only technology newer than that.

From a viewpoint of programming languages, there have been quite a few with support for various forms of parallelism over the years. Some (e.g. Concurrent Pascal) were oriented primarily toward tightly coupled processing. Others (e.g. Occam) were oriented primarily toward loosely coupled parallelism.

IMO, you just about need at least some degree of both. You can't take anywhere close to full advantage of a tightly coupled machine using only a loosely-coupled programming model. Likewise, if you want to scale to lots of separate machines, you just about need a more explicitly loosely coupled programming model.

If, however, you use a loosely coupled model even when it's not really appropriate, you may end up needing scalability, even when you otherwise wouldn't -- i.e. your code will be enough slower that it requires multiple machines, even when code using a more appropriate model wouldn't have required it.

Re:Stupid article (0)

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

  • Erlang supports (one type of) concurrency.
  • Thus Google and Amazon are [probably] using Erlang.

Amazon's SimpleDB does use Erlang, but it does not use the Erlang concurrency model -- they wrote their own because they didn't feel that Erlang's was robust enough.

It's unlikely that any of the retail site uses Erlang, because Erlang's not integrated with the Amazon communication framework. C++ and Java are formally supported internally for server applications and clients are written for C++, Java, Perl, and Ruby. SimpleDB wouldn't care, as it doesn't work inside the Amazon framework; it's an outgrowth of the A9 search engine.

I never looked at the IMDB code, so I'm not sure how it's set up, but they also mention Java in the same breath as Erlang. This suggests that they have a very particular application in which they plan to use Erlang, some number of use cases where they plan to use Java, and will continue to use Perl for things like generating content.

Learning it (1)

caluml (551744) | more than 6 years ago | (#24074715)

I started getting interested in Erlang a year ago. I bought Joe Armstrong's book about it, and, when I was in a place for a few weeks with no internet connectivity, I settled down with my laptop to learn it.

However, I got stuck a: By the lack of documentation (perhaps I could have downloaded it, but over a mobile phone it would have been painful), and b: one of the tutorials in his book seemed to include a library that he had written, to which there was no source code, and the others then built upon that, which scuppered me.

I got dispirited, but I'm still interested. I guess I'll end up learning it when I need to use it for something (like I've learned everything in life). Anyone know where the equivalent of Javadocs are for the core Erlang libraries?

Re:Learning it (1)

e4liberty (537089) | more than 6 years ago | (#24074887)

Erlang documentation has been improving over the last few releases. The Erlang core and OTP libraries are documented here [erlang.org] . -- e

Re:Learning it (1)

caluml (551744) | more than 6 years ago | (#24075003)

Yes, I've just upgraded from 11.something to 12.something, and it seems a lot better now.

Might have another crack at it.

no new language needed (4, Insightful)

speedtux (1307149) | more than 6 years ago | (#24074723)

Erlang is a language that has all the right properties and mechanisms in place to do what utility computing requires.

Well, except that it's darned inconvenient to actually write the applications in it.

Google Gears is using Erlang-style concurrency, and the list goes on."

Yup, and it makes more sense to add "Erlang-style concurrency" to existing languages than to throw out everything and switch to Erlang.

Re:no new language needed (0)

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

Erlang is a language that has all the right properties and mechanisms in place to do what utility computing requires.

Well, except that it's darned inconvenient to actually write the applications in it.

Tell that to Ericsson, the creators of the language, whose AX301 ATM switch is powered by 1.7 million lines of Erlang (the largest functional program ever) and which achives 'nine 9s'
  reliability, i.e. an uptime of 99.9999999% (which translates to 31 milliseconds of downtime a year).

This, IMHO, makes it one of the most successful languages ever designed.

And no, it is not an imperative language with function bits bolted on, as someone suggested.

It's not perfect, but at least it's not Java, which looks as if it was designed (badly) in the (early) 1970s.

Wings 3D is written in Erlang... (2, Interesting)

Fallen Andy (795676) | more than 6 years ago | (#24074951)

See here [wikipedia.org] . (It's an open source subdivision modeller).

Andy

"Cloud computing" is an Xmas artifact (4, Interesting)

Animats (122034) | more than 6 years ago | (#24075027)

The enthusiasm for "cloud computing" may evaporate when Xmas rolls around.

I went to a talk at Stanford by the architect of Amazon's web services. It came out in questioning that the real motivation between Amazon's low-priced web services is that their load in the Xmas shopping season is about 4x the load for the rest of the year. Their infrastructure is sized for the November-December peak, so for ten months of the year they have vast excess capacity. That's why Amazon's web services are so cheap.

Don't expect good response time during the shopping season. Although this Xmas might be OK, due to the recession.

Re:"Cloud computing" is an Xmas artifact (2, Funny)

datablaster (999781) | more than 6 years ago | (#24075249)

Santa Claus, take note: Just what do you do with your sleigh and reindeer the rest of the year? That 11-month excess capacity could be out makin' you money Jan thru Nov.

Re:"Cloud computing" is an Xmas artifact (3, Insightful)

Chang (2714) | more than 6 years ago | (#24075653)

While the origin of EC2 in 2006 is certainly related to peak capacity requirements at Amazon, it is certainly way beyond that point now.

Two Christmas seasons have come and gone without major capacity problems on EC2.

The reality is that EC2 has grown far beyond its roots as a way for Amazon to amortize their peak capacity by reselling it and it has turned into a small but growing profit center and publicity success for Amazon.

Erland textbook: read and adapt (2, Interesting)

Kupfernigk (1190345) | more than 6 years ago | (#24075281)

Joe Armstrong's Erlang textbook is interesting, but I did not have time to learn the language and recode the part of our current project that would benefit from it. So I did what any sensible person would do: raided the concepts, and used them to redesign the critical parts of the application. I was initially provoked into doing this because, in the book, the comparison at one point between the Erlang and Java way of doing something is just plain wrong. When I thought out how I would actually do it in Java, I realised that it helps to stick to a language you know well.

Dunno if Google uses Erlang, but Facebook does (2, Interesting)

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

They built the Facebook Chat backend using Erlang. Scaling something from 0 users one day to tens of millions of active users the next day is a challenge, and they decided Erlang was the right tool for the job. http://www.facebook.com/note.php?note_id=14218138919&id=9445547199

sufficient efficiency? (1)

JustNiz (692889) | more than 6 years ago | (#24075469)

>> you need large real-time systems running as sufficiently as possible.

lol. Are they running vista then? oh wait.. that would be INsufficient...

Going from Perl to Erlang, eh? (2, Informative)

thanasakis (225405) | more than 6 years ago | (#24075515)

TFA more or less says that IMDB is switching from Perl to Erlang. So I looked at the link and here's what I got:

(From here [computerjobs.com]

We are looking for developers with experience building web scale distributed systems. We are currently working in Perl but have plans to use Java, Erlang and any other language that we think will suit our purposes. We aren't looking for expertise in any of those, particularly, but we expect that you will be an expert in the systems you know. We do require that you be passionate about testing (unit, integration, fault-injection) and code quality. Experience with relational databases (Oracle, MySQL, etc), embedded databases (BerkeleyDB, CDB, MonetDB, etc) and Linux are a big plus.

I'll leave anyone to draw his own conclusions.

Re:Going from Perl to Erlang, eh? (1)

sigzero (914876) | more than 6 years ago | (#24075847)

Yeah...that is kind of stretching the "IMDB is re-writing in Erlang".

...switching from Perl to Erlang (0)

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

Oh no! What's to become of poor pudge?? Will he rather fight than switch? Or will he roll over like he does for his favorite political thugs?

Web apps not large-scale, something is off (1)

Tablizer (95088) | more than 6 years ago | (#24075655)

I don't get it. Web transactions are generally like little programs. Concurrency is only needed when sharing info, which is what the database is used for. They need a big-ass database, not a big-ass language unless they are doing online games or the like. Are they trying to re-invent a navigational RAM database or something? Something doesn't add up.

imdb? (0)

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

IMDB (owned by Amazon) is switching from Perl to Erlang

You know, other than the spam blogs that just cut and paste the front of Slashdot, I can't find any reference to back this statement up. Anyone have a link that isn't a spam blog?

So what are Ericsson doing? (1)

dread (3500) | more than 6 years ago | (#24075777)

I can tell you that NO development that is outside of core network componens (I have only limited insight there) is done in Erlang. Not the billing systems, the messaging components (SMS/MMS/Voicemail), not the IVRs. But sure. Whatever. If you really want to build an old school exchange then by all means, get your SS7 stack and Erlang away. Unfortunately the movements towards IMS aren't really helping Erlang internally. And neither is LTE.

Concurrency Fad? (1)

Tablizer (95088) | more than 6 years ago | (#24075787)

People are turning to currency-friendly languages as kind of a fad. A solid need has not been identified for it yet except maybe action gaming. Outside of that, a smart use of the database takes care of most if not all of the alleged "concurrency problems" that are being generated by new chip sets.

I agree that database architecture may need an adjustment to take advantage of more RAM, but that shouldn't require a significant change in the way applications are written. DB's already insulate most apps from implementation issues including concurrency. I'm not saying that concurrency app languages don't have their use, but lets make sure there is really a problem before we make a mad dash to claimed solutions. The IT industry has a tendency to get carried away with fake or exaggerated problems.

Research is fine, but lets approach actual implementation smartly. Maybe I've been around too long, but this smells like yet another fad.
     

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?