9 ms·

Joe Armstrong: Solving the wrong problem

237 points by geoffhill 13y ago

eridius 13y ago
If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
- klibertp 13y ago
  No, it just makes lock-free and parallel programming much easier.
  - eridius 13y ago
    I can see it making concurrency easier, but lock-free-ness is an attribute of the data structure and the algorithms that interact with it, regardless of how easy it is to write concurrent code.
    - transitorykris 13y ago
      Lock-free-ness is a consequence of data being immutable in Erlang
      - eridius 13y ago
        You can avoid mutating data in C if you want to. People just don't, because mutation is so convenient and fast.
        stelonix 13y ago
        Yes, but standard C has no way to tell the compiler a variable is immutable (immutability != constness), so unless you go non-standard (and very verbose at it) Erlang is still a better tool for the job.
- PixelPusher 13y ago
  Well, zlib is fairly trivial and probably not a good example due to overheads. However, an example such as a torrent server this would make much more sense. That being said, Erlang is basically a scripting language for building fault-tolerant and parallel applications. Using C, you might be able to get parallel, but it'll be a lot of work to make it distributed and fault tolerant. The underlying data structures have little to nothing to do with what's being said in the article.
  - eridius 13y ago
    I've looked at Erlang before, and I would certainly agree that it's far simpler to write a concurrent application in Erlang than it would be in C. I'm just taking issue with the bit at the end, where they're bragging about removing a serial bottleneck by rewriting zlib in Erlang in order to remove a lock. Rewriting it in Erlang really doesn't have anything at all to do with switching to a lock-free data structure.
    - PixelPusher 13y ago
      Ah yeah, I had to read it a second time to realize what you meant. That's true, that it's a bad example and doesn't make much sense. I think what they meant to say was that they parallelized the image processing mechanism of the application as a whole.
- cube13 13y ago
  I'm confused where the lock that TFA is talking about is in zlib. We've used zlib in a multithreaded environment for years, and haven't had any issues with it, and as far as I can see, there isn't any mutex or semaphore usage in the source code(http://zlib.net/ http://zlib.net/ ) for the library. It sounds like this is a zlib usage issue more than anything else.
- jarrett 13y ago
  One certainly could. But to obtain the same properties you get with Erlang, you'd have to reimplement some features of the Erlang VM: Lightweight threads, message passing, etc.. Erlang is opinionated. It imposes a very specific model of concurrency. If you buy into that model, the language/VM gives it to you for free. If you don't, then you pretty much can't use Erlang. By contrast, C is a very low-level language that can do anything. You can implement any model of concurrency in C. But you'll be doing all the plumbing yourself, or using a library that does the same. Erlang's model is not the only possible way to be lock-free, and you can pursue other options in C, if you want to.
- rdtsc 13y ago
  Ok so you re-write zlib. Then re-write, imagemagic, then re-write glibc, then re-write other, etc, etc. Yes you can do it. But after a while it is like plugging wholes in a piece of swiss cheese. That is what Joe was saying you start with code that doesn't run well concurrently because concurrency was added later. It is better sometimes to start from scratch with a language that makes concurrency the default and the sequential sections are the exception. > AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free. There is some magic in how it has separate heaps and how it maps schedulers n:m (n cpus say 2 to 24 to m processes say 2 to 300k), how it provides concurrent garbage collection without stopping the world, how it provides hot code reloaded if that is what you need. No it won't make coffee for you and it might not work well for a lot of tasks but it just happens to be the right tool for the right job lately as reliable concurrent back-ends becomes more important (as opposed to say single threaded desktop applications)
spenrose 13y ago
In conventional blocking languages, you can get a start on parallelizing your programs this way: - break program into function calls that match the steps that can happen in parallel - wrap the function calls in messages passed over the network + i.e. process(thing) -> post(thing)/poll_for_things() - split the sender and receiver into different processes OF COURSE there are big advantages to using a language (Erlang) or a heavyweight framework (map/reduce) designed for concurrency. Rolling your own process-centric concurrency is a different set of tradeoffs, not a panacea. But it's worth considering for some problems.
zzzeek 13y ago
> The road to automatic parallelisation of sequential programs is littered with corpses. It can’t be done. (not quite true, in some specific circumstances it can, but this is by no means easy). vs three paragraphs later > Alexander’s talk gave us a glimpse of the future. His company concurix is showing us where the future leads. They have tools to automate the detection of sequential bottlenecks in Erlang code. why is that not a contradiction? because an erlang program isn't "sequential" to start with?
- dustismo 13y ago
  I think you missed the "automatic" part. Completely rewriting a program in a new language is certainly not automatic.
  - zzzeek 13y ago
    both phrases feature the term "automate"...but yes, one is detection, one is resolution
- jameskilton 13y ago
  They're different statements. Taking a sequential program and automatically parallelizing it is a very hard problem. What this tool does, as I read it, is simply find sequential parts of code, and it's up to the devs to figure out how to parallelize said code.
- masklinn 13y ago
  > why is that not a contradiction? because an erlang program isn't "sequential" to start with? Yes. The point is that in a well-coded erlang program only bottlenecks should be sequential (and the bulk should be concurrent), the goal's tool would be (I haven't seen the presentation so I'm throwing ideas to the wall) to see what dependencies lead to sequences in the system reducing overall concurrency and leaving the developer to handle fixing this part if possible. It doesn't try to automatically parallelize a sequential program, and it does not start from fully sequential programs in the first place. (not saying I agree with Joe's assertions, they're quite inflammatory and at a very fundamental level lack solid evidence. I have to say I prefer his milder tone to this new "rha rha" one, though this one may yield more visibility for the language I fear the drama)
daleharvey 13y ago
I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release comes with some nice sounding benchmark about how much faster your programs will run in parallel and there is never a mention of whats actually important to programmers, a vibrant ecosystem and community, language improvements that doesnt make it feel like you are programming in the 80's. Better constructs for reusing and packaging code in a sane way. Its fairly trivial in most languages to get the concurrency you need, I think erlang is solving the wrong problem in 2013.
- tieTYT 13y ago
  I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.
  - MichaelGG 13y ago
    What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
    - tieTYT 13y ago
      You mean like the Scala and Clojure libraries? You can use those in Java code if you want.
    - marshray 13y ago
      Erlang itself is, after all, implemented in C and ASM. But what you can't (practically) implement yourself in other languages is all the professional care and maturity that have gone into the whole package over its long history. AFAICT, Erlang/OTP is much more than just a library.
meshko 13y ago
The lack of understanding is amazingly widespread. I often have to explain to people that when they look at their CPU utilization and it is at 10% it means "you are throwing money way", not "you are efficient".
- masklinn 13y ago
  That's not really true though, or at least not on all workloads: much as you are not "throwing money away" by not pegging your car engine in the red zone 100% of the time, you're not throwing money away by not being at 100% CPU all the time, there are other metrics, values and issues to take in account e.g. a pegged CPU but an unresponsive computer is useless for a desktop, a pegged CPU which can't serve requests because the CPU is pegged because it's swapping like mad is useless for a server, so is a server at 100% CPU when there's no load on it which will just keel over when people start trying to actually interact with it.
  - jeremyjh 13y ago
    It sounds like you missed the point here. If an eight-core server is at 10% utilization, it effective has a single processor nearly pegged and the process doing it is thus CPU bound (and maybe serving responses at a high latency) while you have other cores sitting idle. Conserving CPU resources and running under capacity is wise, but has nothing at all to do with this comment.
- alexchamberlain 13y ago
  It really depends why you are at 10%. A file server will probably spend the vast majority of its time waiting on I/O... That's not necessarily a bad thing.
mncolinlee 13y ago
I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without pragmas to guide it. With that said, our top compiler devs did some amazing work adding automatic parallelization to some awful code. We inevitably sold our supercomputers because we had application experts who would manually restructure the most mission-critical code to fit cache lines and fill the vectors. Most other problems would perform quite adequately with the automatically-generated code. What this article lacks is a description of why Erlang is more uniquely suited to writing parallel code than all the other natively parallel languages like Unified Parallel C, Fortran2008, Chapel, Golang, etc. There are so many choices and many have been around for a long, long time.
- larsberg 13y ago
  I completely agree. As someone who works on a parallel functional language, it's very hard to sell a parallel language that isn't as fast as parallel fortran or hand-tuned C code that uses pthreads and the fastest parallel implementation of BLAS and other libraries. The people who really care about performance are using those. The ones who don't are honestly mostly still writing code that has large constant factors of _sequential_ performance available as low-hanging fruit. Sure, they'd take free performance, but the rewrite/porting/debug costs (even in automatic parallel compilers for the same language) are at least as high as just firing up a profiler. I'm increasingly of the opinion that if you can't win a top spot in the supercomputer performance fight, you have to have a unique application domain. Erlang's seems to be reliability. I suspect that a parallel variant of javascript that runs in every browser will end up being the next compelling parallel language, as opposed to all of us who are either inventing or attempting to resurrect languages that target x86 or GPUs.
  - necrodome 13y ago
    Does/can Manticore have a such unique application domain?
fulafel 13y ago
all true. to add' we are in a local optimum where we have a lot of fast non- parallel solutions and the parallel way needs >10 x parallelism. we'll see if we ever get to ubiquitous 100-way parallelism with no need for backward compatibility.
konstruktor 13y ago
> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 points while a July 2008 Intel Core2 Duo T9400 scores 1005 points. This is almost double the score in less than four years. Of course, one factor is the larger cache that the quad core has, but this refutes Armstrong's point that the multicore age is bad for single thread performance even more. For exposure to a more balanced point of view, I would highly recommend Martin Thompson's blog mechanical-sympathy.blogspot.com. It is a good a starting point on how far single threaded programs can be pushed and where multi-threading can even be detrimental. Also, I think that fault tolerance is where Erlang really shines. More than a decade after OTP, projects like Akka and Hysterix are finally venturing in the right direction.
- jrajav 13y ago
  So somebody else doesn't waste a minute or two googling up the wrong tree: It's Hystrix, not Hysterix. https://github.com/Netflix/Hystrix https://github.com/Netflix/Hystrix http://akka.io/ http://akka.io/
- pdog 13y ago
  Obviously, sequential programs haven't been getting slower on new chips. However, the acceleration rate of single thread performance has been slowing, so even with all our tricks we're getting double in four years when it used to be every 18 months just by doubling the number of transistors on an IC.
  - marshray 13y ago
    AMD recently sacrificed some single-threaded performance in order to achieve an increased core count. Whether or not that was a good move or representative of the industry as a whole is open to debate, but it does occasionally happen. http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper http://www.anandtech.com/show/5057/the-bulldozer-aftermath-d...
alexchamberlain 13y ago
A very very interesting article, but I was extremely disappointed with the example they gave. So, there was an error in someone's code which you rewrote without the error and it ran faster? Well done detective... We need more parallel programs, no doubt, but we need more, better programmers, who are willing to write in compiled languages with low-overhead.
dvt 13y ago
Same old hype. Erlang is good I guess, and I've used it in production a couple of times. But it's just a language that solves 3 problems but creates another 30. Just like C++11, Dart, Go, etc. This kind of belligerent rhetoric (we're solving the right problems, everyone else is dumb) is the kind of drivel that gives momentum to language zealots that think language X is better than language Y. I've contributed to Google Go in the early phases and I was naïve and really believed that Go was the "next big thing." But it turned out to be yet another general-purpose language with some things that were really interesting (goroutines, garbage collection, etc.) but some things that were just same-old same-old. Now, I'm editing a book about Dart and I've since lost my enthusiasm for new languages; I can already see that Dart solves some problems but often creates new ones. And in a lot of ways Erlang sucks, too. The syntax is outdated and stupid (Prolog lol), it has weird type coercion, memory management isn't handled that well (and many more). Of course, since Facebook uses it, people think it's a magic bullet (Erlang is to Facebook like Python is to Google). The article also forces readers to attack a straw man. Often times, algorithms simply cannot be parallelized. The Fibonacci sequence is a popular example (unless you use something called a prefix sum -- but that's a special case). So in many ways, the rhetorical question posed by the article -- "but will your servers with 24 cores be 24 times faster?" -- is just silly.
- davidw 13y ago
  > This kind of belligerent rhetoric For some context: http://joearms.github.com/2013/03/27/promoting-erlang.html http://joearms.github.com/2013/03/27/promoting-erlang.html He's new at "rah rah!" promotion of his language, so cut him a bit of slack.
- banachtarski 13y ago
  > memory management isn't handled that well. So... how would you have handled it, out of curiosity.
  - dvt 13y ago
    > So... how would you have handled it, out of curiosity. Imo separate heaps is the first big mistake. Even implementations like Erjang (Erlang on the JVM using the Kilim microthreading library -- which I've also contributed to) improve on the copy-from-heap mechanism prevalent in vanilla Erlang. Not only that, but Erlang's memory allocator isn't that well-suited for multi-threaded allocations, which also means that Erlang doesn't (can't?) take advantage of tcmalloc, umem, hoard, etc.
eksith 13y ago
There's one big problem Erlang couldn't solve that I live with to this day : Unlike another general purpose language (like say, C++ or C#) allow me to grasp what's happening after staring at it for 30 seconds. This is the same problem, I have with Lisp. Maybe I'm just dyslexic, but these rhetoric pieces for one language or another that says it's concurrent (which it is), fast (obviously), more C than C, will bring the dead to life, create unicorns and other wonderful, fantastic things that I'm sure are all true, just don't seem to be capable of passing into my grey matter. You know another thing all these amazing super power languages haven't been able to do that even a crappy, broken, in many ways outright wrong, carcinogenic etc... etc... language like even PHP has allowed me to do? Ship in 48 hours. Before, I get flamed, I already tried that with Nitrogen (http://nitrogenproject.com http://nitrogenproject.com). It didn't end well, but maybe it will work for someone already familiar with Erlang. It's like you've written the Mahabharata; it'a a masterpiece and it's one of the greatest epics of all time. Unfortunately, it's written in Sanskrit.
- abc_lisper 13y ago
  Now, I have never read or written PHP. Here's the thing. PHP fills a niche. That niche is being super-productive early on. There are other goals, like, the code being readable, ease of being reasoned about, fast and so on. And there are languages that fill those niches. When people say crappy language, more often than not, crappy for their needs(or sometimes their expertise). There is no need to fight about it; its like saying who prefers which color. The reason you do lisp is not to do coding in it(given the current state of affairs), but to reshape one's mind by thinking in terms previously unseen because we could not see forest for the trees. And that ability to see something from different view points arms you with weaponry to solve challenging problems. There is atleast a physicist who agrees with me on that :) http://www.youtube.com/watch?v=IfUhkSEoku0 http://www.youtube.com/watch?v=IfUhkSEoku0
  - eksith 13y ago
    Thank you for this. I fear I'll be an old man by the time I fully grasp thinking in Lisp, but I hate being defeated by my the limits of my own imagination. Very nice video.
surferbayarea 13y ago
Have you even used zlib in c++? The largest ecommerce site out there uses zlib in a multitreaded c++ application(24 cores, 100s of threads, 1000s requests/sec/server) and it works just fine! Bet you erlang can't come within a tenth of the performance of c++...
- coldtea 13y ago
  >1000s requests/sec/server That's not particularly impressive you know.
  - surferbayarea 13y ago
    yes, because it also does other computation. Poiint was to illustrate that zlib can be used in a concurrent computing setting with high performance. The blog writer had claimed that zlib doesn't work in a multithreaded setting.
- querulous 13y ago
  whatsapp is approaching 3 million simultaneous connected users on a single server using erlang
djvu9 13y ago
We used Erlang several years ago. The code base has ~100k lines of code so it should be representative. We abandoned it later and switched to C++ because of performance (mostly in mnesia) and quality issues (some drivers in OTP). We didn't expect too much from performance considering it is functional (which seldom does in place update) but it is still below expectation. It is understandable though. Just think about how much resources have been put into development of Erlang VM and the runtime/libraries(OTP), and compare it with JVM/JDK. There is just no magic in software development. When talking about high concurrency and performance, the essential things are data layout, cache locality and CPU scheduling etc for your business scenario, not the language.
- acqq 13y ago
  The tests here confirm your experience, Erlang is for many algorithms significantly slower, even when more cores are used: http://benchmarksgame.alioth.debian.org/u64q/erlang.php http://benchmarksgame.alioth.debian.org/u64q/erlang.php
  - digitalzombie 13y ago
    Do not use Erlang for number performance. I tried with EulerProject and create some prime number generators in Erlang. It is slow as hell. Use it for what it is built for!
acdha 13y ago
zlib is fine as long as you don't give an non-threadsafe memory allocator - see http://www.gzip.org/zlib/zlib_faq.html#faq21 http://www.gzip.org/zlib/zlib_faq.html#faq21. As far as I can tell, it either means that the summary was imprecise and the slowdown was in the image processing code and not zlib or that they chose to rewrite (and debug) a big chunk of code rather than read the zlib documentation. Ignoring that point, this seems like a poor point for comparison as it's a trivially parallelized task because zlib operates on streams and shouldn't have any thread contention. There's very little information in the description but unless there are key details missing, this doesn't sound like a problem where Erlang has much interesting to add. The most interesting aspect would be the relative measures for implementation complexity and debugging.
artsrc 13y ago
Excel solves this right problem, and Erlang does not. Erlang allows you to create concurrent programs, i.e.: programs where the result is schedule dependent. One right problem is allowing people to write deterministic parallel programs. This gives you the speed (from parallel) with the reliability (from deterministic).
splicer 13y ago
> We’re right and the rest of the word is wrong. We (that is Erlang folks) are solving the right problem, the rest of the world (non Erlang people) are solving the wrong problem. > The problem that the rest of the world is solving is how to parallelise legacy code. As member of the rest of the world, I can assure you that I'm not trying to solve either of these problems. :p
damian2000 13y ago
I would hazard a guess that 90%+ of the worlds programmers are working on projects that don't really need to use parallelism to get the job done.
- tunesmith 13y ago
  The question is, will that percentage go up or down as time goes on?
dap 13y ago
This completely misses the fact that many network services are not compute bound, and multi-tenancy (as we get from "the cloud") lets "legacy" code make very efficient use of CPU resources, even a larger number of relatively slow cores.
kamaal 13y ago
This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all programmers in the world. No serious company until its absolutely unavoidable(and situation gets completely unworkable without it) will ever use a language like Erlang or Lisp. Because every one knows the number of skilled people in market who know Erlang, are close to zero. And those who can work for you are going to be crazy expensive. And not to mention the night mare of maintaining the code in this kind of a language for years. There is no friendly documentation or a easy way a ordinary programmer can use to learn these languages. And there is no way the level of reusable solutions available for these languages as they are for other mainstream C based languages. In short using these languages attracts massive maintenance nightmares. The concurrency/parallelisation problem today is very similar to what memory management was in the 80's and 90's. Programmers hate to do it themselves. These are sort of things that the underlying technologies(Compilers/VM's) are supposed to do it for us. I bet most of these super power languages will watch other pragmatic languages like Perl/Python/Ruby/Php etc eat their lunch over the next decade or so when they figure out more pragmatic means of achieving these goals.
- smosher 13y ago
  This is total disregard for that the rest of the world considers valuable to them. Yes and no. Where it's true, sure, arrogant jerks. But the Lisp weenies have realized they know something the rest of the world doesn't. They think it's important, and it is in a sense. If only you knew that... you'd agree. (Ok, try not to take that too seriously.) Unlike the impossibly abstract Lisp Truth™, this Erlang bit is centered in a very concrete fact that affects all of us. If you don't care about it today, it will affect you tomorrow all the same. You might as well argue that you never much cared for oxygen and who cares if the atmosphere is slowly turning to methane? Joe wasn't saying you have to write Erlang, he was saying you need to write concurrent programs. If another language eats his lunch, it will probably do it in the same way that would be done in Erlang. There are alternatives, but the actor model is by far the most programmer-friendly that I have ever seen.
Uchikoma 13y ago
Because the lock-free Erlang meme doesn't die: 1. Erlang has locks and semaphores [1], receive is a lock, actors are semaphore. Erlang chose a 1 semaphore/ 1 lock per process model 2. Erlang scales better not because of being lock-free (see above), but because it easily uses async compared to other languages 3. Async prevents deadlocks not Erlang being lock-free (see above) Some 4year old reading http://james-iry.blogspot.de/2009/04/erlang-style-actors-are-all-about_16.html http://james-iry.blogspot.de/2009/04/erlang-style-actors-are... [1] http://en.wikipedia.org/wiki/Semaphore_(programming) http://en.wikipedia.org/wiki/Semaphore_(programming)
InclinedPlane 13y ago
People have been thinking this, that it's vastly better to design for concurrency upfront, for literally decades. And every single time there has been a big sea change in processor technology it's always been the next generation which will see things like VLIW or Erlang and so forth come to the fore while what I will call "iterative advancements" and "patched solutions" turn out to have too many weaknesses to be competitive. In reality the reverse has happened, and new specialized languages and instruction sets have been relegated to niches. It'll be the same over the next 20 years as well. I predict that we'll see a lot of technological leaps which will serve as much to maintain the ability to run "old code" in new and interesting ways as to enable a brave new world of purpose-built languages. In the next few decades we'll see advances in micro-chip fabrication and design as well as memory and storage technology (such as memristors) which will result in even handheld battery powered devices having vastly more processing power than high-end workstations do today. Is that an environment in which one seeks to trade programmer effort and training in order to squeeze out the maximum possible efficiency from hugely abundant resources? Seems unlikely to me, to be honest. Indeed, it seems like the trend of relying on even bloatier languages (like Java) will continue. Do you think anyone is going to seriously consider rewriting the code for a self-service point-of-sale terminal in Erlang in order to improve performance? That's not the long pole, it never has been, and it's becoming a shorter and shorter pole over time. In the future we'll be drowning in processor cycles. The most important factor will very much not be figuring out how to use them most efficiently, it'll be figuring out how to maximize the value of programmer time and figuring out how to use any amount of cycles to provide value to customers effectively. (I think that advancements in core, fundamental language design and efficiency will happen and take hold in the industry, but mostly via back-door means and blue sky research, rather than being forced into it through some impending limitation due to architecture.)
- lifeisstillgood 13y ago
  Can I rephrase slightly (and take the odd strawman liberty) The "mainstream" has been relying on incremental improvements for decades, and in doing so avoided rewriting legacy code until last possible moment Some people have taken concurrency upfront and anecdotally seen cost / performance benefits plus more modern codebases and have anecdotally enjoyed competitive advantages in areas where concurrency makes a difference We will never see the average, user interface bother with concurrency and legacy rewrites because the competitive advantages are low. There are likely to be areas where the concurrency advantage is great enough - if you like erlang look for those niches
jlebrech 13y ago
Which frameworks can you use? This? http://nitrogenproject.com/ http://nitrogenproject.com/
- melchebo 13y ago
  I suppose you mean web framework. There's Chicago Boss: http://www.chicagoboss.org/ http://www.chicagoboss.org/ Also a recent book using other Erlang web technology: http://www.amazon.com/Building-Web-Applications-Erlang-Working/dp/1449309968 http://www.amazon.com/Building-Web-Applications-Erlang-Worki...
ternaryoperator 13y ago
Joe Armstrong: "The problem that the rest of the world is solving is how to parallelise legacy code." Donald Knuth: "During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading."
uwiger 13y ago
To say that Erlang fails to deliver what most programmers need misses the point. If you have a mainstream problem, use a mainstream language! I've spent many years developing and reviewing products in the telecoms realm, and have found that failing to realize when something like Erlang brings life-saving concepts to your project may well make the difference between delivering on time and disappearing into a black hole of endless complexity. It's not for everyone, but when it fits, boy does it help!

237 points by geoffhill 13y ago

If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.

klibertp 13y ago
No, it just makes lock-free and parallel programming much easier.
- eridius 13y ago
  I can see it making concurrency easier, but lock-free-ness is an attribute of the data structure and the algorithms that interact with it, regardless of how easy it is to write concurrent code.
  - transitorykris 13y ago
    Lock-free-ness is a consequence of data being immutable in Erlang
    - eridius 13y ago
      You can avoid mutating data in C if you want to. People just don't, because mutation is so convenient and fast.
      - stelonix 13y ago
        Yes, but standard C has no way to tell the compiler a variable is immutable (immutability != constness), so unless you go non-standard (and very verbose at it) Erlang is still a better tool for the job.
PixelPusher 13y ago
Well, zlib is fairly trivial and probably not a good example due to overheads. However, an example such as a torrent server this would make much more sense. That being said, Erlang is basically a scripting language for building fault-tolerant and parallel applications. Using C, you might be able to get parallel, but it'll be a lot of work to make it distributed and fault tolerant. The underlying data structures have little to nothing to do with what's being said in the article.
- eridius 13y ago
  I've looked at Erlang before, and I would certainly agree that it's far simpler to write a concurrent application in Erlang than it would be in C. I'm just taking issue with the bit at the end, where they're bragging about removing a serial bottleneck by rewriting zlib in Erlang in order to remove a lock. Rewriting it in Erlang really doesn't have anything at all to do with switching to a lock-free data structure.
  - PixelPusher 13y ago
    Ah yeah, I had to read it a second time to realize what you meant. That's true, that it's a bad example and doesn't make much sense. I think what they meant to say was that they parallelized the image processing mechanism of the application as a whole.
cube13 13y ago
I'm confused where the lock that TFA is talking about is in zlib. We've used zlib in a multithreaded environment for years, and haven't had any issues with it, and as far as I can see, there isn't any mutex or semaphore usage in the source code(http://zlib.net/ http://zlib.net/ ) for the library. It sounds like this is a zlib usage issue more than anything else.
jarrett 13y ago
One certainly could. But to obtain the same properties you get with Erlang, you'd have to reimplement some features of the Erlang VM: Lightweight threads, message passing, etc.. Erlang is opinionated. It imposes a very specific model of concurrency. If you buy into that model, the language/VM gives it to you for free. If you don't, then you pretty much can't use Erlang. By contrast, C is a very low-level language that can do anything. You can implement any model of concurrency in C. But you'll be doing all the plumbing yourself, or using a library that does the same. Erlang's model is not the only possible way to be lock-free, and you can pursue other options in C, if you want to.
rdtsc 13y ago
Ok so you re-write zlib. Then re-write, imagemagic, then re-write glibc, then re-write other, etc, etc. Yes you can do it. But after a while it is like plugging wholes in a piece of swiss cheese. That is what Joe was saying you start with code that doesn't run well concurrently because concurrency was added later. It is better sometimes to start from scratch with a language that makes concurrency the default and the sequential sections are the exception. > AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free. There is some magic in how it has separate heaps and how it maps schedulers n:m (n cpus say 2 to 24 to m processes say 2 to 300k), how it provides concurrent garbage collection without stopping the world, how it provides hot code reloaded if that is what you need. No it won't make coffee for you and it might not work well for a lot of tasks but it just happens to be the right tool for the right job lately as reliable concurrent back-ends becomes more important (as opposed to say single threaded desktop applications)

spenrose 13y ago

In conventional blocking languages, you can get a start on parallelizing your programs this way: - break program into function calls that match the steps that can happen in parallel - wrap the function calls in messages passed over the network + i.e. process(thing) -> post(thing)/poll_for_things() - split the sender and receiver into different processes OF COURSE there are big advantages to using a language (Erlang) or a heavyweight framework (map/reduce) designed for concurrency. Rolling your own process-centric concurrency is a different set of tradeoffs, not a panacea. But it's worth considering for some problems.

zzzeek 13y ago

> The road to automatic parallelisation of sequential programs is littered with corpses. It can’t be done. (not quite true, in some specific circumstances it can, but this is by no means easy). vs three paragraphs later > Alexander’s talk gave us a glimpse of the future. His company concurix is showing us where the future leads. They have tools to automate the detection of sequential bottlenecks in Erlang code. why is that not a contradiction? because an erlang program isn't "sequential" to start with?

dustismo 13y ago
I think you missed the "automatic" part. Completely rewriting a program in a new language is certainly not automatic.
- zzzeek 13y ago
  both phrases feature the term "automate"...but yes, one is detection, one is resolution
jameskilton 13y ago
They're different statements. Taking a sequential program and automatically parallelizing it is a very hard problem. What this tool does, as I read it, is simply find sequential parts of code, and it's up to the devs to figure out how to parallelize said code.
masklinn 13y ago
> why is that not a contradiction? because an erlang program isn't "sequential" to start with? Yes. The point is that in a well-coded erlang program only bottlenecks should be sequential (and the bulk should be concurrent), the goal's tool would be (I haven't seen the presentation so I'm throwing ideas to the wall) to see what dependencies lead to sequences in the system reducing overall concurrency and leaving the developer to handle fixing this part if possible. It doesn't try to automatically parallelize a sequential program, and it does not start from fully sequential programs in the first place. (not saying I agree with Joe's assertions, they're quite inflammatory and at a very fundamental level lack solid evidence. I have to say I prefer his milder tone to this new "rha rha" one, though this one may yield more visibility for the language I fear the drama)

daleharvey 13y ago

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release comes with some nice sounding benchmark about how much faster your programs will run in parallel and there is never a mention of whats actually important to programmers, a vibrant ecosystem and community, language improvements that doesnt make it feel like you are programming in the 80's. Better constructs for reusing and packaging code in a sane way. Its fairly trivial in most languages to get the concurrency you need, I think erlang is solving the wrong problem in 2013.

tieTYT 13y ago
I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.
- MichaelGG 13y ago
  What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
  - tieTYT 13y ago
    You mean like the Scala and Clojure libraries? You can use those in Java code if you want.
  - marshray 13y ago
    Erlang itself is, after all, implemented in C and ASM. But what you can't (practically) implement yourself in other languages is all the professional care and maturity that have gone into the whole package over its long history. AFAICT, Erlang/OTP is much more than just a library.

meshko 13y ago

The lack of understanding is amazingly widespread. I often have to explain to people that when they look at their CPU utilization and it is at 10% it means "you are throwing money way", not "you are efficient".

masklinn 13y ago
That's not really true though, or at least not on all workloads: much as you are not "throwing money away" by not pegging your car engine in the red zone 100% of the time, you're not throwing money away by not being at 100% CPU all the time, there are other metrics, values and issues to take in account e.g. a pegged CPU but an unresponsive computer is useless for a desktop, a pegged CPU which can't serve requests because the CPU is pegged because it's swapping like mad is useless for a server, so is a server at 100% CPU when there's no load on it which will just keel over when people start trying to actually interact with it.
- jeremyjh 13y ago
  It sounds like you missed the point here. If an eight-core server is at 10% utilization, it effective has a single processor nearly pegged and the process doing it is thus CPU bound (and maybe serving responses at a high latency) while you have other cores sitting idle. Conserving CPU resources and running under capacity is wise, but has nothing at all to do with this comment.
alexchamberlain 13y ago
It really depends why you are at 10%. A file server will probably spend the vast majority of its time waiting on I/O... That's not necessarily a bad thing.

mncolinlee 13y ago

I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without pragmas to guide it. With that said, our top compiler devs did some amazing work adding automatic parallelization to some awful code. We inevitably sold our supercomputers because we had application experts who would manually restructure the most mission-critical code to fit cache lines and fill the vectors. Most other problems would perform quite adequately with the automatically-generated code. What this article lacks is a description of why Erlang is more uniquely suited to writing parallel code than all the other natively parallel languages like Unified Parallel C, Fortran2008, Chapel, Golang, etc. There are so many choices and many have been around for a long, long time.

larsberg 13y ago
I completely agree. As someone who works on a parallel functional language, it's very hard to sell a parallel language that isn't as fast as parallel fortran or hand-tuned C code that uses pthreads and the fastest parallel implementation of BLAS and other libraries. The people who really care about performance are using those. The ones who don't are honestly mostly still writing code that has large constant factors of _sequential_ performance available as low-hanging fruit. Sure, they'd take free performance, but the rewrite/porting/debug costs (even in automatic parallel compilers for the same language) are at least as high as just firing up a profiler. I'm increasingly of the opinion that if you can't win a top spot in the supercomputer performance fight, you have to have a unique application domain. Erlang's seems to be reliability. I suspect that a parallel variant of javascript that runs in every browser will end up being the next compelling parallel language, as opposed to all of us who are either inventing or attempting to resurrect languages that target x86 or GPUs.
- necrodome 13y ago
  Does/can Manticore have a such unique application domain?

fulafel 13y ago

all true. to add' we are in a local optimum where we have a lot of fast non- parallel solutions and the parallel way needs >10 x parallelism. we'll see if we ever get to ubiquitous 100-way parallelism with no need for backward compatibility.

konstruktor 13y ago

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 points while a July 2008 Intel Core2 Duo T9400 scores 1005 points. This is almost double the score in less than four years. Of course, one factor is the larger cache that the quad core has, but this refutes Armstrong's point that the multicore age is bad for single thread performance even more. For exposure to a more balanced point of view, I would highly recommend Martin Thompson's blog mechanical-sympathy.blogspot.com. It is a good a starting point on how far single threaded programs can be pushed and where multi-threading can even be detrimental. Also, I think that fault tolerance is where Erlang really shines. More than a decade after OTP, projects like Akka and Hysterix are finally venturing in the right direction.

jrajav 13y ago
So somebody else doesn't waste a minute or two googling up the wrong tree: It's Hystrix, not Hysterix. https://github.com/Netflix/Hystrix https://github.com/Netflix/Hystrix http://akka.io/ http://akka.io/
pdog 13y ago
Obviously, sequential programs haven't been getting slower on new chips. However, the acceleration rate of single thread performance has been slowing, so even with all our tricks we're getting double in four years when it used to be every 18 months just by doubling the number of transistors on an IC.
- marshray 13y ago
  AMD recently sacrificed some single-threaded performance in order to achieve an increased core count. Whether or not that was a good move or representative of the industry as a whole is open to debate, but it does occasionally happen. http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper http://www.anandtech.com/show/5057/the-bulldozer-aftermath-d...

alexchamberlain 13y ago

A very very interesting article, but I was extremely disappointed with the example they gave. So, there was an error in someone's code which you rewrote without the error and it ran faster? Well done detective... We need more parallel programs, no doubt, but we need more, better programmers, who are willing to write in compiled languages with low-overhead.

dvt 13y ago

Same old hype. Erlang is good I guess, and I've used it in production a couple of times. But it's just a language that solves 3 problems but creates another 30. Just like C++11, Dart, Go, etc. This kind of belligerent rhetoric (we're solving the right problems, everyone else is dumb) is the kind of drivel that gives momentum to language zealots that think language X is better than language Y. I've contributed to Google Go in the early phases and I was naïve and really believed that Go was the "next big thing." But it turned out to be yet another general-purpose language with some things that were really interesting (goroutines, garbage collection, etc.) but some things that were just same-old same-old. Now, I'm editing a book about Dart and I've since lost my enthusiasm for new languages; I can already see that Dart solves some problems but often creates new ones. And in a lot of ways Erlang sucks, too. The syntax is outdated and stupid (Prolog lol), it has weird type coercion, memory management isn't handled that well (and many more). Of course, since Facebook uses it, people think it's a magic bullet (Erlang is to Facebook like Python is to Google). The article also forces readers to attack a straw man. Often times, algorithms simply cannot be parallelized. The Fibonacci sequence is a popular example (unless you use something called a prefix sum -- but that's a special case). So in many ways, the rhetorical question posed by the article -- "but will your servers with 24 cores be 24 times faster?" -- is just silly.

davidw 13y ago
> This kind of belligerent rhetoric For some context: http://joearms.github.com/2013/03/27/promoting-erlang.html http://joearms.github.com/2013/03/27/promoting-erlang.html He's new at "rah rah!" promotion of his language, so cut him a bit of slack.
banachtarski 13y ago
> memory management isn't handled that well. So... how would you have handled it, out of curiosity.
- dvt 13y ago
  > So... how would you have handled it, out of curiosity. Imo separate heaps is the first big mistake. Even implementations like Erjang (Erlang on the JVM using the Kilim microthreading library -- which I've also contributed to) improve on the copy-from-heap mechanism prevalent in vanilla Erlang. Not only that, but Erlang's memory allocator isn't that well-suited for multi-threaded allocations, which also means that Erlang doesn't (can't?) take advantage of tcmalloc, umem, hoard, etc.

eksith 13y ago

There's one big problem Erlang couldn't solve that I live with to this day : Unlike another general purpose language (like say, C++ or C#) allow me to grasp what's happening after staring at it for 30 seconds. This is the same problem, I have with Lisp. Maybe I'm just dyslexic, but these rhetoric pieces for one language or another that says it's concurrent (which it is), fast (obviously), more C than C, will bring the dead to life, create unicorns and other wonderful, fantastic things that I'm sure are all true, just don't seem to be capable of passing into my grey matter. You know another thing all these amazing super power languages haven't been able to do that even a crappy, broken, in many ways outright wrong, carcinogenic etc... etc... language like even PHP has allowed me to do? Ship in 48 hours. Before, I get flamed, I already tried that with Nitrogen (http://nitrogenproject.com http://nitrogenproject.com). It didn't end well, but maybe it will work for someone already familiar with Erlang. It's like you've written the Mahabharata; it'a a masterpiece and it's one of the greatest epics of all time. Unfortunately, it's written in Sanskrit.

abc_lisper 13y ago
Now, I have never read or written PHP. Here's the thing. PHP fills a niche. That niche is being super-productive early on. There are other goals, like, the code being readable, ease of being reasoned about, fast and so on. And there are languages that fill those niches. When people say crappy language, more often than not, crappy for their needs(or sometimes their expertise). There is no need to fight about it; its like saying who prefers which color. The reason you do lisp is not to do coding in it(given the current state of affairs), but to reshape one's mind by thinking in terms previously unseen because we could not see forest for the trees. And that ability to see something from different view points arms you with weaponry to solve challenging problems. There is atleast a physicist who agrees with me on that :) http://www.youtube.com/watch?v=IfUhkSEoku0 http://www.youtube.com/watch?v=IfUhkSEoku0
- eksith 13y ago
  Thank you for this. I fear I'll be an old man by the time I fully grasp thinking in Lisp, but I hate being defeated by my the limits of my own imagination. Very nice video.

surferbayarea 13y ago

Have you even used zlib in c++? The largest ecommerce site out there uses zlib in a multitreaded c++ application(24 cores, 100s of threads, 1000s requests/sec/server) and it works just fine! Bet you erlang can't come within a tenth of the performance of c++...

coldtea 13y ago
>1000s requests/sec/server That's not particularly impressive you know.
- surferbayarea 13y ago
  yes, because it also does other computation. Poiint was to illustrate that zlib can be used in a concurrent computing setting with high performance. The blog writer had claimed that zlib doesn't work in a multithreaded setting.
querulous 13y ago
whatsapp is approaching 3 million simultaneous connected users on a single server using erlang

djvu9 13y ago

We used Erlang several years ago. The code base has ~100k lines of code so it should be representative. We abandoned it later and switched to C++ because of performance (mostly in mnesia) and quality issues (some drivers in OTP). We didn't expect too much from performance considering it is functional (which seldom does in place update) but it is still below expectation. It is understandable though. Just think about how much resources have been put into development of Erlang VM and the runtime/libraries(OTP), and compare it with JVM/JDK. There is just no magic in software development. When talking about high concurrency and performance, the essential things are data layout, cache locality and CPU scheduling etc for your business scenario, not the language.

acqq 13y ago
The tests here confirm your experience, Erlang is for many algorithms significantly slower, even when more cores are used: http://benchmarksgame.alioth.debian.org/u64q/erlang.php http://benchmarksgame.alioth.debian.org/u64q/erlang.php
- digitalzombie 13y ago
  Do not use Erlang for number performance. I tried with EulerProject and create some prime number generators in Erlang. It is slow as hell. Use it for what it is built for!

acdha 13y ago

zlib is fine as long as you don't give an non-threadsafe memory allocator - see http://www.gzip.org/zlib/zlib_faq.html#faq21 http://www.gzip.org/zlib/zlib_faq.html#faq21. As far as I can tell, it either means that the summary was imprecise and the slowdown was in the image processing code and not zlib or that they chose to rewrite (and debug) a big chunk of code rather than read the zlib documentation. Ignoring that point, this seems like a poor point for comparison as it's a trivially parallelized task because zlib operates on streams and shouldn't have any thread contention. There's very little information in the description but unless there are key details missing, this doesn't sound like a problem where Erlang has much interesting to add. The most interesting aspect would be the relative measures for implementation complexity and debugging.

artsrc 13y ago

Excel solves this right problem, and Erlang does not. Erlang allows you to create concurrent programs, i.e.: programs where the result is schedule dependent. One right problem is allowing people to write deterministic parallel programs. This gives you the speed (from parallel) with the reliability (from deterministic).

splicer 13y ago

> We’re right and the rest of the word is wrong. We (that is Erlang folks) are solving the right problem, the rest of the world (non Erlang people) are solving the wrong problem. > The problem that the rest of the world is solving is how to parallelise legacy code. As member of the rest of the world, I can assure you that I'm not trying to solve either of these problems. :p

damian2000 13y ago

I would hazard a guess that 90%+ of the worlds programmers are working on projects that don't really need to use parallelism to get the job done.

tunesmith 13y ago
The question is, will that percentage go up or down as time goes on?

dap 13y ago

This completely misses the fact that many network services are not compute bound, and multi-tenancy (as we get from "the cloud") lets "legacy" code make very efficient use of CPU resources, even a larger number of relatively slow cores.

kamaal 13y ago

This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all programmers in the world. No serious company until its absolutely unavoidable(and situation gets completely unworkable without it) will ever use a language like Erlang or Lisp. Because every one knows the number of skilled people in market who know Erlang, are close to zero. And those who can work for you are going to be crazy expensive. And not to mention the night mare of maintaining the code in this kind of a language for years. There is no friendly documentation or a easy way a ordinary programmer can use to learn these languages. And there is no way the level of reusable solutions available for these languages as they are for other mainstream C based languages. In short using these languages attracts massive maintenance nightmares. The concurrency/parallelisation problem today is very similar to what memory management was in the 80's and 90's. Programmers hate to do it themselves. These are sort of things that the underlying technologies(Compilers/VM's) are supposed to do it for us. I bet most of these super power languages will watch other pragmatic languages like Perl/Python/Ruby/Php etc eat their lunch over the next decade or so when they figure out more pragmatic means of achieving these goals.

smosher 13y ago
This is total disregard for that the rest of the world considers valuable to them. Yes and no. Where it's true, sure, arrogant jerks. But the Lisp weenies have realized they know something the rest of the world doesn't. They think it's important, and it is in a sense. If only you knew that... you'd agree. (Ok, try not to take that too seriously.) Unlike the impossibly abstract Lisp Truth™, this Erlang bit is centered in a very concrete fact that affects all of us. If you don't care about it today, it will affect you tomorrow all the same. You might as well argue that you never much cared for oxygen and who cares if the atmosphere is slowly turning to methane? Joe wasn't saying you have to write Erlang, he was saying you need to write concurrent programs. If another language eats his lunch, it will probably do it in the same way that would be done in Erlang. There are alternatives, but the actor model is by far the most programmer-friendly that I have ever seen.

Uchikoma 13y ago

Because the lock-free Erlang meme doesn't die: 1. Erlang has locks and semaphores [1], receive is a lock, actors are semaphore. Erlang chose a 1 semaphore/ 1 lock per process model 2. Erlang scales better not because of being lock-free (see above), but because it easily uses async compared to other languages 3. Async prevents deadlocks not Erlang being lock-free (see above) Some 4year old reading http://james-iry.blogspot.de/2009/04/erlang-style-actors-are-all-about_16.html http://james-iry.blogspot.de/2009/04/erlang-style-actors-are... [1] http://en.wikipedia.org/wiki/Semaphore_(programming) http://en.wikipedia.org/wiki/Semaphore_(programming)

InclinedPlane 13y ago

People have been thinking this, that it's vastly better to design for concurrency upfront, for literally decades. And every single time there has been a big sea change in processor technology it's always been the next generation which will see things like VLIW or Erlang and so forth come to the fore while what I will call "iterative advancements" and "patched solutions" turn out to have too many weaknesses to be competitive. In reality the reverse has happened, and new specialized languages and instruction sets have been relegated to niches. It'll be the same over the next 20 years as well. I predict that we'll see a lot of technological leaps which will serve as much to maintain the ability to run "old code" in new and interesting ways as to enable a brave new world of purpose-built languages. In the next few decades we'll see advances in micro-chip fabrication and design as well as memory and storage technology (such as memristors) which will result in even handheld battery powered devices having vastly more processing power than high-end workstations do today. Is that an environment in which one seeks to trade programmer effort and training in order to squeeze out the maximum possible efficiency from hugely abundant resources? Seems unlikely to me, to be honest. Indeed, it seems like the trend of relying on even bloatier languages (like Java) will continue. Do you think anyone is going to seriously consider rewriting the code for a self-service point-of-sale terminal in Erlang in order to improve performance? That's not the long pole, it never has been, and it's becoming a shorter and shorter pole over time. In the future we'll be drowning in processor cycles. The most important factor will very much not be figuring out how to use them most efficiently, it'll be figuring out how to maximize the value of programmer time and figuring out how to use any amount of cycles to provide value to customers effectively. (I think that advancements in core, fundamental language design and efficiency will happen and take hold in the industry, but mostly via back-door means and blue sky research, rather than being forced into it through some impending limitation due to architecture.)

lifeisstillgood 13y ago
Can I rephrase slightly (and take the odd strawman liberty) The "mainstream" has been relying on incremental improvements for decades, and in doing so avoided rewriting legacy code until last possible moment Some people have taken concurrency upfront and anecdotally seen cost / performance benefits plus more modern codebases and have anecdotally enjoyed competitive advantages in areas where concurrency makes a difference We will never see the average, user interface bother with concurrency and legacy rewrites because the competitive advantages are low. There are likely to be areas where the concurrency advantage is great enough - if you like erlang look for those niches

jlebrech 13y ago

Which frameworks can you use? This? http://nitrogenproject.com/ http://nitrogenproject.com/

melchebo 13y ago
I suppose you mean web framework. There's Chicago Boss: http://www.chicagoboss.org/ http://www.chicagoboss.org/ Also a recent book using other Erlang web technology: http://www.amazon.com/Building-Web-Applications-Erlang-Working/dp/1449309968 http://www.amazon.com/Building-Web-Applications-Erlang-Worki...

ternaryoperator 13y ago

Joe Armstrong: "The problem that the rest of the world is solving is how to parallelise legacy code." Donald Knuth: "During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading."

uwiger 13y ago

To say that Erlang fails to deliver what most programmers need misses the point. If you have a mainstream problem, use a mainstream language! I've spent many years developing and reviewing products in the telecoms realm, and have found that failing to realize when something like Erlang brings life-saving concepts to your project may well make the difference between delivering on time and disappearing into a black hole of endless complexity. It's not for everyone, but when it fits, boy does it help!