4 ms·

The fact that the author is one of the main developers on the Play Framework means that he should be even more gracious towards the framework/design he is compa

The fact that the author is one of the main developers on the Play Framework means that he should be even more gracious towards the framework/design he is comparing Play against, otherwise he and his project comes off as comparing their project against weak strawmen. Sure, Play has some nice concepts - but the fact that it's built in Scala (and that there is a Java API) means that all of the things that it makes possible are also possible in plain old Java! So this isn't a performance comparison by any means, but rather a "look at what you can do in similar amounts of code" comparison, which is a pretty shallow comparison. Check out the author's previous post where he concludes that Scala is faster than Java (whatever that means, the whole concept seems to ignore the fact that Scala compiles to JVM bytecode) was 18% faster (on a single execution? average execution? author doesn't say): https://jazzy.id.au/default/2012/10/16/benchmarking_scala_against_java.html https://jazzy.id.au/default/2012/10/16/benchmarking_scala_ag...

gclaramunt 13y ago
> Sure, Play has some nice concepts - but the fact that it's built in Scala (and that there is a Java API) means that all of the things that it makes possible are also possible in plain old Java! So this isn't a performance comparison by any means, but rather a "look at what you can do in similar amounts of code" comparison, which is a pretty shallow comparison. If you follow that argument, what you can do in Java that you can't do by writing bytecode by hand? Or, what you can do with a JVM lang that you can't do in assembler? His argument is that even you can do the same in Java, is so unnatural that (almost) nobody does it.