Never trust a statistics you didn't forge yourself
Wed Feb 22 18:15:23 CET 2006
I have to agree that not only Java, but many languages (if you count
their library support) provide for concurrency via thread locks around
shared data. I have built extremely scalable and efficient application
and system frameworks in Java that encapsulate concurrency for the
application programmer. And now that I don't have to support Java
anymore, I looked for a different solution and found erlang was the best
go forward solution (most notably for its concurrency model).
I suppose we get used to the far more useful concurrency paradigm in
erlang that the mainstream model appears low level and not a first class
I'm sorry to see such a tirade about this parallel language report.
I think the report speaks only two things:
1 - The report didn't have a large enough response to provide meaningful
2 - The only meaningfully statistic I can produce from the report and
its fall out is that when other language communities were asked to fill
out the questionnaire, they didn't show as much support as the erlang
community. This statistic only holds if you think it was the community
on the erlang maillist that were the bulk of the pro-erlang responses.
What this implies is obviously subjective..but I know where I stand ;-)
BTW, I remember the post which Joe wrote referencing the questionnaire.
I did not fill it out.
The reason I remember this post is because I read every post on this
maillist regardless of the sender. One the many reasons I chose to use
erlang is because I really like the maillist community...responsive,
friendly, professional and not too much useless traffic (although this
post may qualify ;-).
thanks again to this maillist for making erlang a great choice!!!
Ulf Wiger (AL/EAB) wrote:
> (I've trimmed the receiver list a bit.)
> Joe wrote:
>>> To be fair, Java does support concurrency at the language level. It
>>> just happens to do it poorly.
>> No it doesn't java thread map to OS threads - see for example
> Well, yes, but mapping to OS threads shouldn't in itself
> disqualify a language from being called concurrency-oriented
> (Erlang/OTP R11 will probably support the option of making
> use of OS threads, at least for running multiple schedulers.)
> Java does support concurrency at the language level. It
> happens to do it poorly. Leaving the issue of preemptiveness
> open to each occasion is perhaps the worst mistake, but
> relying on a shared-object model is not that great either.
> The fact remains: Java _was_ designed with concurrency in
> This is also the common perception. Quoting from "Java in
> a Nutshell" ((c) O'Reilly 1997):
> "Java makes programming with threads much easier, by
> providing built-in language support for threads. The
> java.lang package provides a Thread class that supports
> methods to start and stop threads and set thread
> priorities, among other things. The Java language
> syntax also supports threads directly with the
> 'synchronized' keyword. This keyword makes it
> extremely easy to mark sections of code or entire
> methods that should only be run by a single thread
> at a time." (Page 8)
> /Ulf W
More information about the erlang-questions