In the news, Sun has released a Fortress interpreter. Fortress is a replacement for Fortran, and runs on the 1.5 JVM. One of the most interesting features is that it assumes that a process should be run in parallel (instead of assuming that processes should be single-threaded), making it meant for high-performance computing. Another interesting feature of Fortress is its target audience. Fortran typically appeals to programmers doing things Java traditionally hasn't been very good for (i.e., lots and lots of high-precision math), yet Fortress currently uses the JVM as its execution environment. Fortress' FAQ says that "Fortress has been designed to run well on a variety of platforms, including supercomputers with large stores of addressable memory, commodity clusters, workstations, etc. Many aspects of the language have been designed to be as portable as possible. Our initial implementation effort targets the JVM," suggesting that the JVM might not be its target environment permanently. However, this is still quite interesting: most languages that run on the JVM are meant for the same kinds of applications Java is meant for, often presenting alternate syntax more than anything else. Fortress uses a completely different paradigm, so it might broaden what people see as the primary purpose and capability of the JVM. One might also see an application of Fortress in the enterprise Java space; perhaps it could leverage JINI to farm out processing, or even a SOA for subtasks large enough.

I don't think that Fortress is just "another JVM-based scripting language". It is much more than that... I believe that in the long term it will have its own custom VM, possibly a more sophisticated one than the JVM. For example, if you read the Fortress specification, you will notice that it has a different memory model to Java, and it also supports different concurrency primitives. I.e. Fortress will provide some form of Software Transaction Memory rather than the JVM's lock-based "synchronized" primitives. Therefore I think that the release of the JVM intepreter for Fortress is just to give people a chance to play with the syntax of the language and provide feedback. In the future, Fortress will be a very important platform. Personally I see it as the evolution of Java. The Fortress homepage, which provides links to the specification, FAQ, various talks and papers is here: http://research.sun.com/projects/plrg/ Disclaimer: I don't work for Sun and I don't have any insider information. The above is merely my personal opinion.

+1, i agree. it is not a scripting language, although it may work as a script (not compiled) if wanted. and, finally a really different language i say. but for a real high-performance system in my opinion they may need a custom runtime (maybe a modified jvm?). which takes time.

This language is quite an interesting take an attacking the problem of utilizing multiple cores. In most populair languages (like Java, or C#) exploiting parallelism is not exactly trivial. It still takes quite some skill and many programmers therefor simply ignore it. Since dual-core is quite common these days and even quads aren't that rare anymore, it becomes more and more of a waste not to let your core run in parallel. It seems that Fortress, due to its structure, can provide more than a helping hand here. Even when you don't write all your code in this language it might be beneficial to just write some parts in it and call that as a library from your main app.

I think if we take a look at sample code of Fortress, it becomes way more clear who the target user of this new language really is... A hint can be found here: http://research.sun.com/projects/plrg/faq/index.html where the author points out: Fortress uses a widely known syntax that has evolved over thousands of years: mathematical notation. When Pervasive released http://www.pervasivedatarush.com to Beta a few weeks ago, we made similar goal statements: "To ease the burden of coding massively parallel applications on multicore platforms." But I knew it would be hard for the community to picture where in the ocean of parallel frameworks/languages DataRush sat -- especially with the chip vendors in a "multicore arms race" that is spawning new solutions literally monthly. I would like to take this opportunity to help cut through the marketing babble (including mine?) and point out the differences so the community can understand at least where DataRush is coming from: a) We used a Java framework, rather than a new language based on mathematical notation. If your math problem is hard to express in Java, then you aren't the target user of DataRush. b) We are targeting mainstream data processing applications built by regular Java developers (if there's such a thing? :-) c) We are only targeting data-intensive parallel apps -- not compute-intensive such as mathematical models that don't take much data as input. Look, a bunch of us have taken those really fun math 301 classes in Ordinary Differential Equations and were so proud to have mastered Triple Integrals etc... but when we entered the Global 2000 IT shops what happened? Yup... addition, subtraction, multiplication and division (i.e. a virtual lobotomy ). I know this is a vast generalization, but you get my point. It would be silly to bash Fortress and that's not my goal. I think coding in mathematical notation makes a lot of sense for a segment of the population -- you know who you are.

Java is the scripting language next to Fortress.

Frankly I agree with the previous poster: Fortress is not for the generic business segment. Have you guys looked at its syntax? http://research.sun.com/projects/plrg/faq/NAS-CG.pdf This has been done mainly for scientists or people involved in projects with a lot of math. I don't see a superscript/subscript notation widely adopted in banks or e-commerce sites :-) IMHO Fortress is aimed in killing that old Fortran that is still the mainstream in the scientific world. It's a very demanding target, but I wish Fortress the best luck: not only because I think that Fortran is just too old a technology, but because the JVM compatibility - if designed well - could bring us a good deal of ready-to-use scientific libraries that would enrich the Java ecosystem.