2

I just hear and see people saying scala is designed for MultiThread though it's actually for general purpose.

And it claims "The thing is that while you can make classes thread-safe in Java (if you know what you're doing ), Scala makes it easy and natural to do."

And indeed AKKA and Lift is written in scala.(actually java and scala)

But java also did improves in this aspect with the new package of java.util.concurrent. So why didn't AKKA and Lift born in JAVA?

Maybe you will say scala makes java looks like C. :-)

Anyone can tell more insight or deeper thoughts on this?

I know the fact that it is possible to mix JAVA and scala. Scala is able to call seamlessly into Java code. So what java have,so does scala.

But what scala really improves that java haven't done yet regardless of different grammers?

Only some design like Actors/Agents or something else? (note Actors/Agents are cannot solve all the problem in MultiThread.)

Or does scala compiler and adopting some functional language grammer really matters or helps more than in java?

I heard some news that scala is going to be able to adopt XText. To be able to leverage XText to write thread logic, not sure if this is true or not.

Scala looks like a mixture of languages and using this approach makes it more extensible to solve problems in this aspect?

UPDATE

Thanks for your excellent answers from different angles. I think they are all very good. No matter what side you are standing.

EDIT

Topic below (in SO one year ago) was asking about the similiar thing. The "constructive" conclusion is quite similiar. But this time ,some new points are coming out probably the way I am asking is a bit different. Just FYI.

Related:

Actually I am very interested in some one can answer this question in some brand new angle which could enlighten my mind , provide some idea unknown before.

But it's closed due to not constructiveness. :-)

Community
  • 1
  • 1
Clark Bao
  • 1,743
  • 3
  • 21
  • 39
  • http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29 – Mchl Aug 20 '11 at 12:21
  • 1
    @Mchi Could you explain what is your idea with some words? – Clark Bao Aug 20 '11 at 12:24
  • 1
    Actually, one aspect of Scala that I dislike is working with multiple threads. I never know precisely what is happening. I miss some precision in the language specification regarding *visibility*. For instance, the specs don't guarantee that a val in a case class will be compiled to a final field (which it usually is)... and if you can't make this assumption, you have to add loooots of boilerplate synchronization code just to be sure. Or you can also code something that might be totally broken if, by some reason, the compiler decides not to add the final modifier.This lack of precision bugs me – Bruno Reis Aug 20 '11 at 13:13
  • @Bruno Your words gives me some hints. If the language compiler can be smarter to tell the programmer that your code is not thread-safe.Then I will love it a lot. :-) – Clark Bao Aug 20 '11 at 13:25

3 Answers3

6

I am not really an expert in this, but Scala is a (partly at least) a functional programming language while Java is not (it is imperative). One feature of functional programming is that it avoids (in a 'natural' way) side-effects.

Thread-safety on the other hand is pretty much about avoiding side-effects (i.e. different threads modifying same objects/parts of memory/other resources at the same time).

Mchl
  • 61,444
  • 9
  • 118
  • 120
3

As it is today, I find Scala much worse than Java with respect to working with multiple threads.

The language specification doesn't define some really important things, that you would rely on, to make thread-safe code.

For instance, you should know that final instance fields are very special when working with multiple threads. They are guaranteed to have their initial value visible to all threads after the constructor has completed, even if the object is published with race conditions.

Scala makes no guarantees that a val will be compiled to a final field. It is usually the case, but since the specs don't state it clearly, you cannot take it for granted. Therefore, either you write boilerplate synchronization code that wouldn't exist in Java, or you write code that is not guaranteed thread-safe (and hope for the compiler to continue mapping your vals to final fields).

Bruno Reis
  • 37,201
  • 11
  • 119
  • 156
  • +1 Very differnt answer. I guess Martin Odersky will faint when reading your answer. :-) It origins to makes multi threads programmer eaily. – Clark Bao Aug 20 '11 at 13:37
  • You can be sure he and his team are aware of it since long ago. I'd really like to know the rationale for choosing not to specify these things clearly. – Bruno Reis Aug 20 '11 at 13:44
  • You are right. But time will tell the trend. Perhaps more powerful scala is needed whatever the name. I like your answer. It gives some insight. – Clark Bao Aug 20 '11 at 13:48
  • Is there a distinction at the bytecode level between `final` and non-final fields? I thought it was just a Java keyword. – Luigi Plinge Aug 20 '11 at 18:43
  • 1
    What would be the point of having a keyword that does not have effect on byte code? – Mchl Aug 20 '11 at 20:13
  • 1
    @Mchl - it could just stop you from compiling a class where you reassign a value to a field marked final, and allow compiler optimizations – Luigi Plinge Aug 20 '11 at 21:59
  • 1
    Has the guarantee been added to the specs? What are the downvotes for? People got offended by the answer? – Bruno Reis Aug 21 '11 at 14:51
2

I'd say it not so much a matter of the actual language, but more about applying principles which ease concurrent programming, e.g. share nothing, message passing, immutable objects, side-effect free functions, etc. Scala is not a FP language in it's strictest sense, but it delivers access to functional programming techniques.

Abstractions like Actors/Reactors, which are part of the framework (not language), completely free the developer to handle threads and critical section synchronization directly. What's more: Since 2.9.x, parallel collections are directly included in the library.

Horst Dehmer
  • 369
  • 1
  • 10
  • Why Can't these principles adopted in java? However you are right about the difference in library. But you have to admit scala is a language not framework.If scala is a framework, I don't need to ask this question. – Clark Bao Aug 20 '11 at 14:45
  • I guess, they can. But IMHO, Scala makes it way simpler and it feels more 'natural'. I'd also say, that higher-order functions is the key aspect Java is missing until now. – Horst Dehmer Aug 20 '11 at 14:50
  • IMHO principles are general and common concept in design. It doesn't decide which lauguage is fitter. Instead, it should fit into all languages. So maybe scala just runs further to this path. – Clark Bao Aug 20 '11 at 14:55
  • In a word, principals are above languages. – Clark Bao Aug 20 '11 at 15:01
  • Well said. But doesn't the right tool ease the application of principles? I think the Scala language **combined** with its library raises some important levels of abstraction, so that one does not (or much less) have to worry about the nitty gritty stuff. – Horst Dehmer Aug 20 '11 at 15:07
  • Something I cannot agree. In some time, you are forced to handle some synchronization. Which cannot be fit for Agent/Actor model. – Clark Bao Aug 20 '11 at 15:10
  • I only agree it solves some problems that fit into Agent/Actor model very well. – Clark Bao Aug 20 '11 at 15:12
  • Right. Even FP gurus (which I'm not) recognized this. One answer to this is Software Transactional Memory. --- I'm not saying Scala takes away all our pains (in fact, it introduces new ones), but in my opinion Scala helps, by facilitating FP principles, getting concurrent code right. – Horst Dehmer Aug 20 '11 at 15:22