BT

The multicore crises: Scala vs. Erlang

by Niclas Nilsson on Jun 23, 2008 |

There has been a somewhat heated debate about Scala vs. Erlang on the blogosphere recently. The future will be multi-cored, and the question is how the multi-core crises will be solved. Scala and Erlang are two languages that aspire to be the solution, but they are a bit different. What are the pros and cons with their approaches?

The problem

Moore’s law has changed. We don’t get the same increase in clock frequency as we used to. Instead, we get more cores. Today, even your laptop probably has two cores.

To utilize more than one core, your application has to be concurrency-aware. If your customer bought an eight-core machine, you will have a hard time explaining to them that it’s normal that the application only uses about 12% of the CPU capacity, even if the machine is dedicated to that particular application.

In the future, this will be even worse. Not only will your sequential code not run faster, it will actually run slower. The reason is that the more cores you get, the slower each core will run for power and heat reasons. In a couple of years, Intel will give us 32 cores, and there are trends that suggests that will have thousands of cores before we know it. But each core will be very slow compared to todays cores.

Concurrent code

One obvious way to solve the problem is to write (and rewrite) software to be concurrent. The most common way to do that is to use threads, but most developers consider thread-based applications particularly hard to write. Deadlocks, starvation and race conditions are concepts that are way too familiar for a majority of developers doing concurrency. Both Erlang and Scala take away a lot of that pain.

An brief overview of the languages

Scala is sometimes seen as the next big JVM language. It combines the object-oriented paradigm with the functional paradigm, has a terse syntax compared to Java, is statically typed and is as fast or sometimes even faster than Java. There are numerous reasons to take a serious look at Scala.

Erlang is a language designed for robustness, but because of its design, it is thereby a language that scales well. It predates Java, but it is often considered to be a language of the concurrent future. It is a dynamically typed, functional language, with some remarkable examples of uptime.

The debate

So what’s the Scala vs. Erlang debate all about? In the end, performance and scalability, but the debate includes other things like style, language features and library support as well. The debate was started unintentionally when Ted Neward gave his opinions about a number of languages and that “the fact that [Erlang] runs on its own interpreter [is] bad”.

Steve Vinoski and Ted then had a couple of rounds of debate, but the discussion then moved to a couple of other blogs where it highlighted interesting differences and similarities between Scala and Erlang. We’ll summarize each interesting point to show pros and cons of each language and the different views on some problems.

Reliability

Steve Vinoski wrote a response to Ted’s post where he gave his take on that Erlang runs its own interpreter:

The fact that it runs on its own interpreter, good; otherwise, the reliability wouldn’t be there and it would be just another curious but useless concurrency-oriented language experiment.

Steve is talking about the problem that even if a language itself is reliable, everything it stands upon has to be reliable too. Since Erlang is designed from the bottom up for reliability and thereby concurrency, it doesn’t suffer from usual problems when it comes to concurrency, primarily that the underlying libraries needs to play well in a concurrent setting.

Scala on the other hand lives on top of the JVM and one of the most important selling points is the potential usage of all existing Java code. However, a lot of Java code is not designed for concurrency, and Scala code needs to take this into account.

Lightweight processes

To run massively concurrent applications, you need a lot of parallel execution. This can be done in several ways. Using threads is one common way, using processes is another. The difference is that a thread shares memory with other threads, processes share nothing. That means that threads needs locking mechanisms like mutexes to prevent two threads from manipulating the same memory at the same time, but processes don’t suffer from that problem and instead uses some kind of message passing to communicate with other processes. But processes are normally expensive regarding performance and memory, and that is a reason why people often choose thread based concurrency, even though it’s a harder programming model.

Steve Vinoski writes:

Massive concurrency capabilities become far easier with an architecture that provides lightweight processes that share nothing, but that doesn’t mean that once you design it, the rest is just a simple matter of programming.

Erlang takes this approach to concurrency. An Erlang process is very lightweight, and Erlang applications commonly have tens-of thousands of threads or more.

Scala on the other hand does the same thing with event-based actors. Yariv Sadan explains how:

Scala has two types of Actors: thread-based and event based. Thread based actors execute in heavyweight OS threads. They never block each other, but they don’t scale to more than a few thousand actors per VM. Event-based actors are simple objects. They are very lightweight, and, like Erlang processes, you can spawn millions of them on a modern machine.

Yariv explains that there is a difference though:

The difference with Erlang processes is that within each OS thread, event based actors execute sequentially without preemptive scheduling. This makes it possible for an event-based actor to block its OS thread for a long period of time (perhaps indefinitely).

Immutability

Erlang is a functional language. This means that data is immutable, like Java’s strings, and there is no risk of side effects. Any operation on some data will result in a new modified version of that data, but the old one stays the same. Immutability is a highly regarded ingredient when it comes to robustness, since no code can unintentionally change data that someone else is dependent upon, but from a concurrency point of view, it is also an important feature. If data is immutable, the risk of it being changed by two parallel execution paths doesn’t exist and data can even be copied to other machines since there is no way for it to change and nothing to keep in sync.

Since Scala is based upon the JVM and combines an object-oriented and functional approach, there are no guarantees of immutability like in pure functional languages. However, in the comment section of Yariv’s post, a very interesting discussion between Yariv and David Pollack on interesting differences between the languages took place. David, who is the creator of the Scala web framework Lift, gives his views on immutability.

Immutability — Erlang enforces this and there’s almost no way around it. But you trade the rest of Scala’s amazingly powerful type system for enforcement of this single type. I do my Scala Actor coding with immutable data and I have Scala’s type system to enforce the rest of my types.

Yariv asks:

Doesn’t sending only immutable types a big limitation? It means you can’t, for example, load a simple bean from Hibernate and send it to another actor.

David answers:

I’ve built a number of production systems based on Scala Actors. There’s very little work actually required to deal with the immutable issue. You just define your case classes (the messages) to be immutable and away you go.

Type systems

Erlang is dynamically typed. Scala is statically typed and has a stronger type system than Java. However, a big difference compared to Java is that Scala has type inference. This means that you can omit a lot of type annotations, which makes the code cleaner but the compiler will still do all checks.

The debate about pros and cons of dynamic and static type systems will likely never come to an end, but that is a noticeable difference between Erlang and Scala.

Tail recursion or loops

Yariv again:

Functional programming and recursion go hand-in-hand. In fact, you could hardly write working Erlang programs without tail recursion because Erlang doesn’t have loops — it uses recursion for everything (which I believe is a good thing :) ).

This is definitely something that differs Erlang a lot from Scala. Scala has a much more traditional style of iterations, but David Pollack doesn’t see an advantage for tail recursion in this context:

Tail recursion — It’s a non-issue for event-based actors.

In that case, it all comes down to preference and style.

Hot swapping code

Since Erlang was designed for reliability, hot swapping code (replacing code in runtime) is built in.

The JVM has some support for hot swapping code. Classes can be changed, but due to the static type system, method signatures can not be changed - only the content of a method. There are third party tools to get around that, and there are frameworks that promotes a programming style that makes it easier to swap classes in running systems, but because of how a Scala Actor is built up, how swapping works even though it runs on the JVM. Jonas Bonér gives a thorough example of how to do it.

Summary

Both Scala and Erlang are languages that target the multi-core crises. They come from different background and eras and thereby approach some problems differently, but in many ways they have more in common than they differ, at least when it comes to the concurrency issues.

Erlang has been around for a couple of decades, and has proved itself in many critical real-world systems. One of it’s drawbacks is that it is a bit of an island and the recent polygot programming trend is not likely to affect Erlang community that much.

Scala on the other hand is the new kid on the block for the same type of applications. There are real world applications just coming out the door, and there are companies that are betting their future on it. Scala’s biggest advantage compared to Erlang is that is runs on the JVM and can use all existing Java code, frameworks and many of the tools. That said, that power comes with great responsibility, since most Java code don’t automatically fit well the Scala’s Actor model.

Both languages offer similar ways to solve a increasingly pressing problem that mainstream languages don’t help developers with very well. Hopefully you have a slightly better insight about which language to take a closer look at for your particular situation after reading this debate summary.

The future is multi-cored. Scala and Erlang is likely to increase in popularity.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Use OSGi for more powerful and reliable hotswapping by Neil Bartlett

If you use OSGi (JSR 291), the dynamic module system for Java, then you can actually get a far more powerful hotswap capability in the JVM than in BEAM, the Erlang VM.



The Erlang runtime "only" supports two simultaneous versions of a module: the current and the old; as soon as you update again the current becomes the old and the previous old is expunged. Of course this is better than almost every other language runtime! However in OSGi on the JVM you can have as many versions of a module in memory as you wish, all with explicit version numbers, and modules can depend on specific versions of other modules. Modules can be dynamically installed, updated and uninstalled at runtime.



I think the core feature offered by Erlang that cannot also be copied in Scala is its extremely lightweight processes. As the article highlights, we can simulate these on the JVM using Event actors, but there is always the potential to block the entire OS thread by doing IO or acquiring a lock etc. Largely the problem here is legacy libraries. On the other hand Erlang has poor interoperability with libraries written in other languages, including Java. You could say that interoperability with existing Java code is Scala's biggest strength, and also its biggest weakness.

Nice article.... by Brendan McKenna

Nice article, but I think you're missing at least part of the point. The issue really isn't Erlang vs. Scala, as such, but the Erlang VM vs. the Java VM supporting concurrency. Since they're ultimately both interpreted languages, it really a matter of which language you (or the organization you work for) prefers to use, and the VM on top of which it's implemented is far more important.

Re: Use OSGi for more powerful and reliable hotswapping by Niclas Nilsson

Neil,




I fully agree about OSGi and that was the reason I included the OSGi link in the text ("... and there are frameworks that promotes a programming style that makes it easier to swap classes in running systems"). For me, this has always been the most important point of OSGi.




It still amazes me that it took so long (and to be honest, there is still a long way to go) for OSGi to be adopted by the Java community. For some reason, people had no problem hanging around, waiting for their apps to restart. I never got why.




Another important difference with hot swapping in production, in my opinion, is the difference between a dynamic type system and a static type system. Take a callback interface for instance. It is harder to evolve that interface (adding a method), since you have to upgrade everyone that implements the interface (if you ever want to get rid of the old class). With a dynamic type system / message passing, a class (pun intended) of problems evolving more or less goes away. There are less "artifacts" that needs to have new version numbers in general.




Kind regards

Niclas




---

blog: niclasnilsson.se

Re: Nice article.... by Niclas Nilsson

Brendan,



You're right, I should have been more clear on that part.



The main problem though, as I see it, is that even if they will add Erlang style, lightweight threads into a future JVM, or manage to emulate it well enough on top of it (which event-based actors seems to do a rather good job at according to the debaters) - it won't help solving the problem of the biggest selling point. All old code will still be unaware of the new concurrency model.



I think Scala is a very welcome addition to the JVM family of languages, and one that I prefer in most ways over Java (even though I've had very little exposure to it in comparison to Java). But just as Neil wrote:



You could say that interoperability with existing Java code is Scala's biggest strength, and also its biggest weakness.


It's the damned if you do, damned if you don't" thing.



Kind regards

Niclas



---

blog: niclasnilsson.se

Re: Nice article.... by Niclas Nilsson

To be more clear:



It's the damned if you do, damned if you don't" thing.


...which of course is the same thing (but opposite) for Erlang.



Kind regards

Niclas



---

blog: niclasnilsson.se

What about distributed computing? by Raffaele Guidi

I believe that distributed computing is a core concept (together with functional and concurrent programming) in erlang - and is totally missing in scala.

Isn't that true? And I believe that this is a substantial differentiating factor - not only multi-core, but grid enabled applications out-of-the-box (well, kinda...) with erlang.

Regards,
Raffaele

How many mission critical 24*7 apps is Scala running? by Tom Ayerst

Scala is very interesting and it may be able to do everything Erlang can do and more (especially with OSGi) but will it? Sun may derail OSGi and Scala may be too complicated for the average Joe (as the IntelliJ guys believe) and the actor/library interaction may mean Scala is never really "non-stop".


Erlang has "form", it has been around for 20 years running non-stop apps in critical environments, it is quite a small language with a set of libraries and idioms dedicated to non-stop operation. I really hope something else matches it because it is this kind of approach we need more of.

Its I/O guys... by Bill Burke

A couple of things:

* Big deal about multicore, we've had multi CPU for years and years now and the bottleneck has always been the database, which is why we've had to turn to things like multi-level transactional caches to be able to take advantage of the multi-cpus. I don't see multicore, Erlang, or Scala solving or making this problem easier to solve.



Knowing this caching problem, does Erlangs memory model even allow for concurrent caching?


* on OSGi and hot deployment. Guys, I know I'm tooting my own horn here, but this is old, old news as JBoss users haven't had to "restart the app server" since 2002.* I think Erlang's "lightweight concurrency" model is overrated. As we start to go beyond 8 cores as a base system, the Operating Systems are going to have to go through some refactoring to support hundreds of thousands of threads anyways. OS's are not going to be standing still, and now that the JDK is open source, neither is the JVM. Since there are *already* probably at least an order of magnitude (2 orders? 3?) of high performance, highly scalable applications written in Java that take advantage of 4,8,32,64 cpus, let alone cores, (think Azul too), my bets are still on Java first, and languages that run on the JVM 2nd.


* Erlang and Scala are never going to usurp Java (or even Ruby) until they can reach the productivity levels of Java (or Ruby). They need a "sweet-spot" application if they are ever going to gain any relevance (a.k.a. J2EE or Rails). I just don't see it at all from either of these communities.



--

Bill Burke

JBoss, a division of Red Hat

bill.burkecentral.com

Re: Its I/O guys... by Niclas Nilsson

Bill,



* Absolutely right. To get at that problem, in the Erlang case, Mnesia seems to be the way to go, and on the Scala side, the recommendations seems to go for either Javaspaces or Terracotta (see comment section).



* I do agree that OSGi and hot deployment is old news. I worked with OSGi from it's first early steps and we haven't had to restart systems since the late -90:s. And yet JBoss (and many, many others) reinvented the wheel. ;-)



* The last point I don't quite grasp. Why would you have less productivity with Scala or Erlang than with Java? I can grasp that it may still be hard to reach the productivity levels of Ruby, but outperforming the productivity we have in Java is done out of the box with more or less anything but C++? Scala can use any framework that Java can and the code base is much cleaner and smaller to maintain? Erlang will definitely be cleaner, but you may loose out on some frameworks, depending on what kind of app you're building.


But I suspect we're likely talking about different things here?



Kind regards

Niclas



---

blog: niclasnilsson.se

Re: What about distributed computing? by Kirk Peterson

I believe that distributed computing is a core concept (together with functional and concurrent programming) in erlang - and is totally missing in Scala.


You are mostly correct. Lex Spoon has done some great work at mapping Scala actors to JXTA, however from what I have been able to find, it does not yet provide what the Erlang guys tout as "Location Transparency", that is, the ability to send a message to an actor, regardless of there that actor is located(within the local VM, or on another VM on another machine). Scala's Actors work great on solving problems of a concurrent nature. Erlang's actors are more than just a concurrency mechanism, they are also distribution mechanism. Each Erlang VM runs epmd, a node wide daemon used monitoring the heartbeats of other VMs and mapping global processes. Afaik, these features are still getting worked out or are non-existent in Scala's current offerings. The fact that Erlang/OTP has this feature baked-in out-of-the-box with years of testing and hardening is incredible.

Re: Its I/O guys... by Bill Burke

* Absolutely right. To get at that problem, in the Erlang case, Mnesia seems to be the way to go, and on the Scala side, the recommendations seems to go for either Javaspaces or Terracotta (see comment section).


JBoss Cache??? ;-) I'll take a look at Mnesia, thanks.



* The last point I don't quite grasp. Why would you have less productivity with Scala or Erlang than with Java? I can grasp that it may still be hard to reach the productivity levels of Ruby, but outperforming the productivity we have in Java is done out of the box with more or less anything but C++? Scala can use any framework that Java can and the code base is much cleaner and smaller to maintain? Erlang will definitely be cleaner, but you may loose out on some frameworks, depending on what kind of app you're building.



I guess my point is that until there is a "sweet-spot" productivity enhancer app that showcases the features of the particular language, there's no way, IMO, that Erlang or Scala is going to gain any traction. You can knock J2EE all you want, but it hit a sweet spot in its hayday. JBoss, Hibernate, Tomcat, Struts, Spring, and then with annotations EE 5, JPA, Seam these all just pushed productivity even further and added another 5-10 years onto the viability of the language itself. I'd like to know the "killer frameworks" out there for Erlang and/or Scala that are going to make me want to give those languages a chance. (Ruby gave us Rails, Groovy Grails).



--

Bill Burke

bill.burkecentral.com

Re: Its I/O guys... by Debasish Ghosh


I'd like to know the "killer frameworks" out there for Erlang and/or Scala that are going to make me want to give those languages a chance. (Ruby gave us Rails, Groovy Grails).


Erlang OTP, that allows 9 9's in uptime percentage with a few milliseconds downtime per year .. Isn't that killer ?

Re: Its I/O guys... by Niclas Nilsson


I'd like to know the "killer frameworks" out there for Erlang and/or Scala that are going to make me want to give those languages a chance. (Ruby gave us Rails, Groovy Grails).


Hibernate, Tomcat, Struts and Spring maybe? All frameworks that Java can use goes for Scala as well? It just happens to have a leaner syntax, more abstractions (not mentioned in the article though, since it wasn't a comparison with Java), and an Actor implementation that can help solve a normally hard-solved problem. Especially for systems where the database it not the bottleneck (or that doesn't have a database at all).



I don't think anybody believes that Java the language will ever disappear or be overtaken in a long time, but Scala solves some types of problem quite nicely, and it also seems to be an interesting choice for a general purpose language on the JVM, imho.



If I was starting a green field project on the JVM, that would be one language I'd take under consideration as a base ingredient. I'd likely do the same consideration for a non green field project too, depending on the state of the project, since it runs just as well on JBoss as any other byte code. ;-)



Kind regards

Niclas



---

blog: niclasnilsson.se

Neck of the bottle by Viktor Klang

From my point of view, scalability of data processing, software development and organization of data is THE problem of the near future.

Personally, I think Scala is a very viable alternative for the near future, when we get fully transparent localization of Actors, and can combine that with fault tolerance (Bonér has made the first step in that direction) and we get a better data storage facility (let's face it, RDBMSes are built upon the constraints of the '60s. )
we can finally start offering environments that can expand horizontally without effort (which has previously only been available to more exotic platforms than hte JVM).

Erlang is a nifty language, and surely has some really cool platform features, but the lack of competence and libraries is a hinderance.

What'd be really cool is to have native JVM support for share-nothing Threads, tail calls and reified generic types.

Immutability by Markus Kohler

Hi,
String in Java is immutable.
I consider this a failed experiment.
Immutability not only has advantages for parallel programming, but it has also the drawback the memory consumption tends to go up.
Strings typically consume more memory in today Java applications than they should.
Check my block at for some examples.

Regards,
Markus

The Next Best Thing! by alpha alpha

I'm aware that the future is multicore, cloud, clustered, web, services, concurrent, functional, dynamic and we need a change, I think that means Erlang is the way to go. It is mature, concurrent from the core, distributed, scalable, fault tolerance, opensource, so on and is evolving fast. My last language in the JVM it will be Java if I will learn a new language I want it have a new syntax, I don't want to continue with the same C'ish curly braces and also we all know OOP failed, I think functional/concurrent without OOP is the way to go.

I don't believe Scala is the way to go because seems is bolted on the JVM and even can reuse Java libraries as many people said it will not be 100% for multicore or concurrency with locks problems and all that from the Java API's, maybe the solution is porting all libraries to Scala heheh good luck with that, I prefer to start fresh and that is Erlang.

This is just my 2c.

Re: Its I/O guys... by Jon Bettinger

Never done rails, but apparently Lift is scala's answer. liftweb.net/

As for JEE, Hibernate, Spring, etc, those are all available in Scala.

Re: The Next Best Thing! by Hitesh Bagchi

What ends up being the next best language is a difficult prediction and not worth worrying about. We all agree both are excellent languages and will help in furthering the task of software development. Unfortunately, not all good languages win as history have shown us (java & smalltalk in the '90s). There are also a lot of other factors like ease of use, library support, willingness to adopt a new style or approach by the larger programmer community. The classic example from history being java displacing C++. Smalltalk could have done it as well. In fact, there is a revival of sorts for Smalltalk through squeak. But we can almost predict it will continue to be niche.
Scala has a huge advantage over Erlang owing to its interoperability with existing Java code and this alone will put Scala miles ahead. The whole proposition of reusing existing code is so appealing that it will be an easy sell to the stakeholders.

Re: The Next Best Thing! by Hugh Gilmore

This is assuming that future distributed architectures will need packages like Hibernate, Struts or Spring. Why not CouchDb for loosely structured databases, single page Ajax clients with jQuery and multi-agent peer to peer architectures deployed on heterogeneous, mobile platforms running Erlang? Java/J2EE is the COBOL/CICS of the 21st century. Browser Client/WebWhale Server architectures are strongly reminiscent of the GreenScreen/Mainframe dinosaurs of the Jurassic 20th century - the extinction event is upon us.

Re: Nice article.... by Stephan Schmidt

"[...] it won't help solving the problem of the biggest selling point. All old code will still be unaware of the new concurrency model"

I'm hearing this over and over again, and each time it does make less sense. Using immutable messages in Scala shields you from non-concurrent aware libraries (I don't know of one library I use which uses static mutable state). So by going the Scala way, you have less troubles with libraries. But on top of that: The "old" Java libraries needed to work in a state sharing enviroment, and therefor need to be written "safer" than Erlang libraries. They are not "unsafer" when used in a immutable, message passing enviroment.

Cheers
Stephan
twitter.com/codemonkeyism

Re: The Next Best Thing! by Stephan Schmidt

"I don't believe Scala is the way to go because seems is bolted on the JVM and even can reuse Java libraries as many people said it will not be 100% for multicore or concurrency with locks problem ..."

As stated above, this makes zero sense.

Think again

Cheers
Stephan
twitter.com/codemonkeyism

Re: Nice article.... by Stefan Tilkov

As soon as you call into a mutable language (Java) from an immutable one (or a sub-section of a language that's immutable), all bets are off. The Java library you call might change some shared state, contained in global (static) variables, it might create new threads, write stuff to disk or to the DB, or in general: behave very unlike what you the caller if your immutable/pure method expected.

Re: Nice article.... by Stephan Schmidt

The point is:

1.) "Using immutable messages in Scala shields you from non-concurrent aware libraries"

If a library works in a mutable enviroment, it works in an immutable enviroment.

2.) Strawmen attack: "or in general: behave very unlike what you the caller if your immutable/pure method expected."

I talked about immutable message passing.

3.) "write stuff to disk or to the DB" - I'm no Erlang expert, but I would assume that Erlang writes to a DB (Mnesia?) and to disk, it's otherwise very hard to write business applications.

4.) "The Java library you call might change some shared state, contained in global (static) variables."

Haven't seen mutabale global state in Java ever - only immutable. But your experience may differ, do you have examples for libraries which do that? This would help me in my JEE environment - to be warned. Thanks.

5.) "The Java library you call might change some shared state, [...]"

Would be interested to see how this can happen with

Actor1 -> Message(String,String,String) -> Actor2

I'm not very experienced with immutable message passing as a concurrency strategy though. How could this share state (without 4)?

Cheers
Stephan

Re: Nice article.... by Stefan Tilkov

I can't point to any well-known wide-spread open source libraries that use shared state, but I've seen plenty of bad code in projects that did. Haven't you?

Anway, I'm not really familiar with Scala, so maybe the point doesn't apply here. You tell me: in other languages, such as Haskell, the infrastructure (the platform, or VM, or whatever) can parallelize stuff like crazy because it knows functional and there's no mutable state. The same is IIUC true for Erlang - the only side effects are the explicit messages passed to processes.

I'd imagine the reason for immutability is the same with Scala. But as soon as any of your functions can call into a piece of code that's not controlled by the same runtime, you can no longer be sure state won't be changed, and thus can't apply the same optimizations.

Am I missing something? Or do you simply feel that while this might be true in theory, it doesn't matter in practice? If so, what if e.g. I expect my code to be parallelizable in lightweight processes, and library calls to Java code create threads?

Re: Nice article.... by Stephan Schmidt

"[...] but I've seen plenty of bad code in projects that did. Haven't you?"

Sure I have, and I introduced code reviews,static quality checks (FindBugs, custom PMD rules) and told developers about software craftmanship.

"You tell me: in other languages, such as Haskell, the infrastructure (the platform, or VM, or whatever) can parallelize stuff like crazy because it knows functional and there's no mutable state."

No, not yet, Scala will get a @Pure for sure, just like in D, and like @Tailrec in Scala. But why isn't Haskell performing better than Scala "like crazy"?

Cheers
Stephan
twitter.com/codemonkeyism

Re: Nice article.... by Stefan Tilkov

Hm, you seemed to call into question the logical validity of the argument that a language running on top of a mixed-language VM will always "suffer" from a lack of guarantees, simply because one can call into the "lower-level" language. Now I'm no longer sure I know what it is you take issue with.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

26 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT