Scaling Large Projects With Erlang 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."
Huh? (Score:5, Insightful)
"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?
Proprietary? (Score:2, Insightful)
Why Erlang Matters (Score:5, Insightful)
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.
Gibberish (Score:5, Insightful)
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:Deceptive (Score:5, Insightful)
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:Huh? (Score:2, Insightful)
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:Comparison of functional languages? (Score:3, Insightful)
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.
no new language needed (Score:5, Insightful)
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.
Get a clue! (Score:2, Insightful)
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.
Re:Huh? (Score:4, Insightful)
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:Why Erlang doesn't matter (Score:5, Insightful)
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:"Cloud computing" is an Xmas artifact (Score:4, Insightful)
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.
Re:Comparison of functional languages? (Score:1, Insightful)
Y supongo que después nos dirás que para la persona "típica," el español es un idioma difícil de comprender, al menos comparado con el inglés.
Re:Comparison of functional languages? (Score:1, Insightful)
Re:Why Erlang doesn't matter (Score:3, Insightful)
Well no to use the advantages of these esoteric languages today and not 25 years from now. The people using LISP in the 1950s hard garbage collection, reentrant functions, complex data structures....
Re:Stupid article (Score:3, Insightful)
Sounds great in theory but in the real world you don't get much concurrency. Once Bright finishes D2 he'll discover this too, just as the Haskell people did. For the forseeable future, it's going to require the same humans that write the software to help the compiler generate concurrent code. Languages that have had purity for many years are trying to integrate more powerful tools into the language and standard libraries for writing concurrent code, such as STM.
In the mean time, D is still doesn't have a stable compiler and a standard library most of its users can agree on. D doesn't even have a debugger for non-windows machines (not sure about windows.) The GDB patches are long abandoned and the commercial debugger with beta D support is unusably buggy in my experience.
Re:Why Erlang doesn't matter (Score:3, Insightful)
But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.
3) They're just lists of numbers; they're neither ASCII nor Latin1. There is unicode parsing in the XMERL module.
Which is exactly the problem that GP discussed. There is a huge difference between a true in-language support of Unicode (such as the one in Perl) and just "the Unicode parsing library". In Perl there is a difference between "string of bytes" and "string of characters", and this distinction is made when the string is created (i.e. in the I/O layer when it is read from the file, or in the source code pragma when it is a literal constant). And then all things work as expected (conversion between upper and lower case, word boundaries, string length in bytes or in characters, etc.) - differently on a character string than on a byte string.
This means, that the only place you have to actually "handle" unicode is the point where the data enter your program or leave it. All the other things (libraries etc) just magically work without needing a change. This cannot be easily done without an in-language support (C or maybe Erlang).