Some comments in case interesting. My understand of Kilim (and therefore anything built on it) is you have to annotate every method from the top of the stack down to where you send/receive messages. Its very common for only the top most method to need annotations, but I suspect that for more complex apps you may end up with wanting to send messages (and wait for a result) deeper in the code tree - maybe even in a library. This would require annotations on every single message in the call sequence. Yuck.
I was thinking that as long as you had a somewhat decent API, then the length of the Actor code itself is not that big an issue. E.g. if the Java API required twice as much code, is it really a problem? The rest of the code would almost certainly dominate real world applications. Looking at the blog post, I must say I personally thought the Scala code looked the easiest to read. But I don't think that is a reason by itself to pick Scala over Java for Actors. Relying on third party libraries from these various sources is more of an issue for a real world project. Scala to me has the feeling of a bigger community. No criticism intended of the other groups developing Actor frameworks - but I would want to dig into them a bit more to make sure they would stick around. With for example Kilim doing byte weaving etc, supporting the code yourself might be non-trivial. My very limited work with Actors so far is leading me towards having lots more actors than I would threads. It seems more natural to break up big chunks of code into smaller units. This however means reducing the boilerplate to do actors is more important. Over the weekend I tried the Eclipse and Netbeans Scala plugins and gave up on them both very quickly. I know there is the new plugin for Scala 2.8 coming that is supposed to be good, but released versions today amazed me how bad they were. I was trying to open a Scala file with Java code in it (that I was converting to Scala) - the Eclipse plugin refused to paste in the text at all, and then for text I did load up I could not edit parts of the text (could not insert or delete characters). It really does make you appreciate the quality of the Java tools that exist. I know people are working hard on the Scala plugins and don't mean to be negative on their hard work - but it does make you appreciate the difference in code quality when there is more funding behind the tool set. One thing that is available in Scala Actors that I have not checked for Java Actors yet is the guard condition support. For a some Actor code I wrote, guards made the code almost trivial to write. http://alankent.wordpress.com/2009/10/07/my-first-real-use-of-scala-actors/ Basically I wanted to read data in from an external data source in parallel to requests to access the data. Requests should block until the data was available. Using guards is was easy to leave messages in the inbox until enough other processing had occurred to allow them to be answered. Its how easy it was to do that I think make Actors in languages such as attractive - its so easy to get more concurrent code going. But bottom line, I don't think its a slam dunk between Scala and Java for Actors. The quality of the Java development tools compared to Scala tools (so far) would make me hesitant to introduce Scala here at work as a core supported language yet. After a weekend of coding, most of my fears about Scala language complexity are going away. Its not that hard a language once you get into it. Its more the Scala IDE support and compiler error messages that are limitations so far for me. Alan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
