Play 2.0 Whatsnew Tartismasi

[Ahmet Alp Balkan]

Selamlar herkese, 

Bildiginiz gibi Play 2.0 final surumu cikti. Play 2.0 "for Java" dokumantasyonunu okudum. Birkac dusuncem & sorum var tartisalim istedim. Inline yanitlar alabilirsem cok sevinirim biliyorsaniz cevaplari. 

1) Reverse routing destegi: Henuz denemedim sistemi. Doc'larda su yaziyor: controllers.Application.hello(name) metodunun URL'ini almak icin controllers.routes.Application.hello yapabilirsiniz diyor. Nasil oluyor ki bu controller.routes olayi sizce? Android gibi otomatik bir routes.java falan mi uretiliyor her degisiklikte, yahut compile time'da mi icabina bakiliyor bunun? Eger oyleyse IDE nasil otomatik tamamliyor bunu ben anlayamadim... 

2) Body Parsers ve Scala karisimi: body parsers denen olay oncelikle butun POST bekleyen action'lari etkisi altina almis anlasilan. POST'larda request parametreleri almak icin request. asFormUrlEncoded().get("paramName") dememiz gerekcek galiba? Yoksa sizce yine method signature'daki arguments list'e yazdigimiz metodlar POST'ta da auto-bind ediliyor mu? Dokumantasyonda bisey bulamadim.

3) Async results + promise : Bu en ilgincime giden konu oldu, bilgisizligimden de kaynaklaniyor olabilir. Async computation'un bitmesini bekleyip o zamana kadar response'un gitmesini bekletiyor galiba. Peki bunun zaten o thread'de blocking computation yapmasindan ne farki var? Yani ben zaten request'in islendigi thread'de atiyorum fotograf resize etmeyi beklesem blocking olarak, sonra sonucu kullaniciya gostersem bunun Promise+async mantigindan ne farki var ki? Dokumana gore, CPU intensive islem farkli bi thread'de caliscaktir diyor ama ayni thread'de calissa ne yazar?

Bide galiba Play'in mantiginda bi gariplik var. Suan gelistirdigim uygulamada, fotograflar blocking (synchronous) resize edilirken ayni IP'den gelen requestlerin de bloklandigini gordum. Sanirim iki nedeni var:

a) Bu tip blocking islemleri promise ile yapacagiz cunku Play'in mantigi bu sekilde, doc'larda da demis ki.

 By giving aPromise<Result> instead of a normal Result, we are able to compute the result quickly without blocking anything. Play will then serve this result as soon as the promise is redeemed.

ne anlama geldigini de cozemedim...

b) Play ayni IP'den gelen requestleri tek thread'den yanitliyor olmali. Ama load test programimda gordum ki ne kadar bot yuklersem sisteme thread sayisi da ayni miktarda artiyor. Ama bi tane fotograf resize requesti gelince ayni IP'den gelen butun requestler bloklaniyor. Belki farkli IP'dekiler de bloklaniyor, eger oyleyse yandik. :D

3) Validation'a ne oldu: Guzelim validation sinifi ortadan kalkmis galiba. Zaten metodlarin icinde biz validation.required(password); validation.email(email); falan diye flash scope'a validation error'lari atiyorduk. Ona cok uzuldum, her seyi annotation'lara dayamaya calismislar. :-( Template engine de groovy'i ozletiyor ne yazik ki zaten.

4) Ebean geldi JPA noldu:  JPA ile ilgili sayfaya bakinca gordum ki uvey cocuk muamelesi yapmaya baslamislar. Configuration'lari onceden annotationla yapardik, bunla ovunurduk onu yazmadiklarina gore ve Hibernate'i nasil XML'le config ederiz yazdiklarina gore annotation destegi gitmis mi jpa icin?

Bir de onceden User.find("username = ?" ,foo ) falan derdik simdi JPA.em().find(User.class, ...) falan tarzi klasik J2EE uygulamalari havasina sokmuslar JPA kullanimini, sanki Ebean cok cool'muscasina. Butun o basitligi ucurmuslar, zira ebean'i de konfigure etmek o kadar basit-pratik degil. Yeni Play'le ilgili gorusum Simplicity concern'inden vazgecilmis.

5) Caching templates: "Caching in templates" basligina bakarsaniz template'in bi kisminin cache'lenebilecegini soylemis. Ben bunun ne ise yarayabilecegini hala bulamadim. Statik bir div'i niye cache'leyeyim ki? Statik olmayan seyin de icine konacak seyin binding'ini controller'da yapiyorum, view render edilene kadar zaten is isten gecmis olmuyor mu cache kullanmak icin?

Ancak div'in icine koydugum dinamik variable'in, o region cached ise controller'da compute edilmesini onleyen bi sistem yazdilarsa (oha derim) o zaman ise yarar gibi duruyor.

6) Moduller ne olacak?: Hala Play 2.0 icin hicbir modul yazilmamis. Benim kullandigim toplam 2 modul var aslinda: play-morphia ve play-rabbitmq. Bunlari da zaten modules klasorume atip calistiriyorum. Ama bunlar Play 2.0'i desteklemedikleri surece 2.0'a gecmem mumkun olmayacak :-/ 

~o~o~

Begendigim ozellikler de cok yeni Play'de

• Action'larin static void'den throwable atmalari yerine Result dondurmeleri guzel olmus.
• Akka entegrasyonu cok hos.
• Comet genelgecer herkesin isine yaramaz saniyorum ama WebSocket destegi gayet guzel.
• Global class'i ise yarar olmus. En azindan basitce request interception yapilabilir, hatalar handle edilebilir.
• Testing'de guzel seyler var. Test esnasinda app'in icinde fake app calistirma falan yapmislar. Cool. 
• Template engine'in guzel yanlari da var kotu yanlari da. Epey trade-off olmus. Eski tag'leri ozleriz galiba
• Bu sartlar altinda 1.2.x'den 2.0'a gecebiliriz belki bir haftasonu hackathon'unda. Ama ah iste su modules meselesi...

Siz neler dusunuyorsunuz?

[Fehmi Can SAĞLAM]

3) Async results + promise için hemen kısaca cevap vereyim. Yazı çok
uzun, klavyene sağlık:) Güzel bir tartışma konusu olacak gibi görünüyor.

Play içinde gelen netty bir non-blocking server. Her request için bir
thread açmaktansa başlangıçta bir thread pool oluşturuyor ve
requestleri bu pool aracılığıyla işliyor. Pool size application.conf
içindeki play.pool parametresi ile ayarlanıyor. Default değer (nb
processors + 1) olarak setleniyor. Java concurrency ile uğraşmış
olanlar bilirler: bu değer en yüksek throughput için optimum kabul
edilen değerdir.

Uzun süre işlem yapılması gereken bir request geldiğinde ilgili thread
uzun süre kullanımda kalacaktır. Aynı şekilde nb processors + 1 request
geldiğinde boşta hiç thread kalmaz ve sunucu yeni requestlere cevap
veremeyecek hale gelir. Bu soruna çözüm olarak uzun sürecek işler async
olarak ayrı bir thread içinde çalıştırılır ve requstleri işleyen
threadler mümkün olduğunca az meşgul edilir.

Promise+async olayının mantığı bu. DEV modda play.pool=1'dir. Yani
bütün istekler seri işlenir.

PS: IP konusunda bir işlem yapıldığını sanmıyorum:)

On Wed Mar 14 11:14:58 2012, Ahmet Alp Balkan wrote:
> Selamlar herkese,
>
> Bildiginiz gibi Play 2.0 final surumu cikti. Play 2.0 "for Java"

> <http://www.playframework.org/documentation/2.0/JavaHome>dokumantasyonunu

> okudum. Birkac dusuncem & sorum var tartisalim istedim. Inline
> yanitlar alabilirsem cok sevinirim biliyorsaniz cevaplari.
>
> 1) Reverse routing destegi:

> <http://www.playframework.org/documentation/2.0/JavaRouting> Henuz

> denemedim sistemi. Doc'larda su yaziyor:
> controllers.Application.hello(name) metodunun URL'ini almak icin

> controllers.*routes*.Application.hello yapabilirsiniz diyor. Nasil

> oluyor ki bu controller.routes olayi sizce? Android gibi otomatik bir
> routes.java falan mi uretiliyor her degisiklikte, yahut compile
> time'da mi icabina bakiliyor bunun? Eger oyleyse IDE nasil otomatik
> tamamliyor bunu ben anlayamadim...
>
> 2) Body Parsers

> <http://www.playframework.org/documentation/2.0/JavaBodyParsers>ve

> Scala karisimi: body parsers denen olay oncelikle butun POST bekleyen
> action'lari etkisi altina almis anlasilan. POST'larda request
> parametreleri almak icin request. asFormUrlEncoded().get("paramName")
> dememiz gerekcek galiba? Yoksa sizce yine method signature'daki
> arguments list'e yazdigimiz metodlar POST'ta da auto-bind ediliyor mu?
> Dokumantasyonda bisey bulamadim.
>
> 3) Async results + promise

> <http://www.playframework.org/documentation/2.0/JavaAsync> : Bu en

> ilgincime giden konu oldu, bilgisizligimden de kaynaklaniyor olabilir.
> Async computation'un bitmesini bekleyip o zamana kadar response'un
> gitmesini bekletiyor galiba. Peki bunun zaten o thread'de blocking
> computation yapmasindan ne farki var? Yani ben zaten request'in
> islendigi thread'de atiyorum fotograf resize etmeyi beklesem blocking
> olarak, sonra sonucu kullaniciya gostersem bunun Promise+async
> mantigindan ne farki var ki? Dokumana gore, CPU intensive islem farkli
> bi thread'de caliscaktir diyor ama ayni thread'de calissa ne yazar?
>
> Bide galiba Play'in mantiginda bi gariplik var. Suan gelistirdigim
> uygulamada, fotograflar blocking (synchronous) resize edilirken ayni
> IP'den gelen requestlerin de bloklandigini gordum. Sanirim iki nedeni var:
>
> a) Bu tip blocking islemleri promise ile yapacagiz cunku Play'in
> mantigi bu sekilde, doc'larda da demis ki.
>

> By giving a|Promise<Result>| instead of a normal |Result|, we

> are able to compute the result quickly without blocking
> anything. Play will then serve this result as soon as the
> promise is redeemed.
>
> ne anlama geldigini de cozemedim...
>
> b) Play ayni IP'den gelen requestleri tek thread'den yanitliyor
> olmali. Ama load test programimda gordum ki ne kadar bot yuklersem
> sisteme thread sayisi da ayni miktarda artiyor. Ama bi tane
> fotograf resize requesti gelince ayni IP'den gelen butun
> requestler bloklaniyor. Belki farkli IP'dekiler de bloklaniyor,
> eger oyleyse yandik. :D
>
>
> 3) Validation'a ne oldu

> <http://www.playframework.org/documentation/2.0/JavaForms>: Guzelim

> validation sinifi ortadan kalkmis galiba. Zaten metodlarin icinde biz
> validation.required(password); validation.email(email); falan diye
> flash scope'a validation error'lari atiyorduk. Ona cok uzuldum, her
> seyi annotation'lara dayamaya calismislar. :-( Template engine de
> groovy'i ozletiyor ne yazik ki zaten.
>

> 4) Ebean <http://www.playframework.org/documentation/2.0/JavaEbean>
> geldi JPA <http://www.playframework.org/documentation/2.0/JavaJPA>

> noldu: JPA ile ilgili sayfaya bakinca gordum ki uvey cocuk muamelesi
> yapmaya baslamislar. Configuration'lari onceden annotationla yapardik,
> bunla ovunurduk onu yazmadiklarina gore ve Hibernate'i nasil XML'le
> config ederiz yazdiklarina gore annotation destegi gitmis mi jpa icin?
>
> Bir de onceden User.find("username = ?" ,foo ) falan derdik simdi
> JPA.em().find(User.class, ...) falan tarzi klasik J2EE uygulamalari
> havasina sokmuslar JPA kullanimini, sanki Ebean cok cool'muscasina.
> Butun o basitligi ucurmuslar, zira ebean'i de konfigure etmek o kadar
> basit-pratik degil. Yeni Play'le ilgili gorusum Simplicity
> concern'inden vazgecilmis.
>
> 5) Caching templates:

> <http://www.playframework.org/documentation/2.0/JavaCache> "Caching in

> templates" basligina bakarsaniz template'in bi kisminin
> cache'lenebilecegini soylemis. Ben bunun ne ise yarayabilecegini hala
> bulamadim. Statik bir div'i niye cache'leyeyim ki? Statik olmayan
> seyin de icine konacak seyin binding'ini controller'da yapiyorum, view
> render edilene kadar zaten is isten gecmis olmuyor mu cache kullanmak
> icin?
>
> Ancak div'in icine koydugum dinamik variable'in, o region cached ise
> controller'da compute edilmesini onleyen bi sistem yazdilarsa (oha
> derim) o zaman ise yarar gibi duruyor.
>
> 6) Moduller ne olacak?: Hala Play 2.0 icin hicbir modul yazilmamis.
> Benim kullandigim toplam 2 modul var aslinda: play-morphia ve
> play-rabbitmq. Bunlari da zaten modules klasorume atip calistiriyorum.
> Ama bunlar Play 2.0'i desteklemedikleri surece 2.0'a gecmem mumkun
> olmayacak :-/
>
> ~o~o~
>
> Begendigim ozellikler de cok yeni Play'de
>

> * Action'larin static void'den throwable atmalari yerine Result
> dondurmeleri guzel olmus.
> * Akka entegrasyonu cok hos.
> * Comet genelgecer herkesin isine yaramaz saniyorum ama WebSocket
> destegi gayet guzel.
> * Global <http://www.playframework.org/documentation/2.0/JavaGlobal>

> class'i ise yarar olmus. En azindan basitce request interception
> yapilabilir, hatalar handle edilebilir.

> * Testing'de guzel seyler var. Test esnasinda app'in icinde fake app
> calistirma falan yapmislar. Cool.
> * Template engine'in guzel yanlari da var kotu yanlari da. Epey

> trade-off olmus. Eski tag'leri ozleriz galiba

> * Bu sartlar altinda 1.2.x'den 2.0'a gecebiliriz belki bir haftasonu

[Erdem Agaoglu]

Selamlar,

Oncelikle yeni ozellikleri ozetlediginiz icin tesekkur ederim, inceleme firsatim olmamisti. Cogunun cevabini bilmiyorum ama tartisma olsun diye bir seyler yazmak istedim, aralarda tabi...

2012/3/14 Ahmet Alp Balkan <ahmetal...@gmail.com>

Selamlar herkese, 

Bildiginiz gibi Play 2.0 final surumu cikti. Play 2.0 "for Java" dokumantasyonunu okudum. Birkac dusuncem & sorum var tartisalim istedim. Inline yanitlar alabilirsem cok sevinirim biliyorsaniz cevaplari. 

1) Reverse routing destegi: Henuz denemedim sistemi. Doc'larda su yaziyor: controllers.Application.hello(name) metodunun URL'ini almak icin controllers.routes.Application.hello yapabilirsiniz diyor. Nasil oluyor ki bu controller.routes olayi sizce? Android gibi otomatik bir routes.java falan mi uretiliyor her degisiklikte, yahut compile time'da mi icabina bakiliyor bunun? Eger oyleyse IDE nasil otomatik tamamliyor bunu ben anlayamadim... 

Sirf meraktan kurcaladim biraz kodlari, dediginiz gibi her degisiklikte iki dosya olusturuluyor, routes_routing.scala ve routes_reverseRouting.scala gibi. play bunlari compile ediyor, IDE'de bytecode'dan bakiyor olabilir. bakmiyor da olabilir tabi, IDE denemedim hic.

 

2) Body Parsers ve Scala karisimi: body parsers denen olay oncelikle butun POST bekleyen action'lari etkisi altina almis anlasilan. POST'larda request parametreleri almak icin request. asFormUrlEncoded().get("paramName") dememiz gerekcek galiba? Yoksa sizce yine method signature'daki arguments list'e yazdigimiz metodlar POST'ta da auto-bind ediliyor mu? Dokumantasyonda bisey bulamadim.

GET querystring parametrelerini dogrudan alabiliyor, denedim. POST request body kismi olmadi. Ben becerememis olabilirim, diger taraftan olmuyor da olabilir. Bunun faydalari ve zararlari iyi bir tartisma olabilir aslinda.

3) Async results + promise : Bu en ilgincime giden konu oldu, bilgisizligimden de kaynaklaniyor olabilir. Async computation'un bitmesini bekleyip o zamana kadar response'un gitmesini bekletiyor galiba. Peki bunun zaten o thread'de blocking computation yapmasindan ne farki var? Yani ben zaten request'in islendigi thread'de atiyorum fotograf resize etmeyi beklesem blocking olarak, sonra sonucu kullaniciya gostersem bunun Promise+async mantigindan ne farki var ki? Dokumana gore, CPU intensive islem farkli bi thread'de caliscaktir diyor ama ayni thread'de calissa ne yazar?

Bide galiba Play'in mantiginda bi gariplik var. Suan gelistirdigim uygulamada, fotograflar blocking (synchronous) resize edilirken ayni IP'den gelen requestlerin de bloklandigini gordum. Sanirim iki nedeni var:

a) Bu tip blocking islemleri promise ile yapacagiz cunku Play'in mantigi bu sekilde, doc'larda da demis ki.

 By giving aPromise<Result> instead of a normal Result, we are able to compute the result quickly without blocking anything. Play will then serve this result as soon as the promise is redeemed.

ne anlama geldigini de cozemedim...

b) Play ayni IP'den gelen requestleri tek thread'den yanitliyor olmali. Ama load test programimda gordum ki ne kadar bot yuklersem sisteme thread sayisi da ayni miktarda artiyor. Ama bi tane fotograf resize requesti gelince ayni IP'den gelen butun requestler bloklaniyor. Belki farkli IP'dekiler de bloklaniyor, eger oyleyse yandik. :D

3) Validation'a ne oldu: Guzelim validation sinifi ortadan kalkmis galiba. Zaten metodlarin icinde biz validation.required(password); validation.email(email); falan diye flash scope'a validation error'lari atiyorduk. Ona cok uzuldum, her seyi annotation'lara dayamaya calismislar. :-( Template engine de groovy'i ozletiyor ne yazik ki zaten.

4) Ebean geldi JPA noldu:  JPA ile ilgili sayfaya bakinca gordum ki uvey cocuk muamelesi yapmaya baslamislar. Configuration'lari onceden annotationla yapardik, bunla ovunurduk onu yazmadiklarina gore ve Hibernate'i nasil XML'le config ederiz yazdiklarina gore annotation destegi gitmis mi jpa icin?

Bir de onceden User.find("username = ?" ,foo ) falan derdik simdi JPA.em().find(User.class, ...) falan tarzi klasik J2EE uygulamalari havasina sokmuslar JPA kullanimini, sanki Ebean cok cool'muscasina. Butun o basitligi ucurmuslar, zira ebean'i de konfigure etmek o kadar basit-pratik degil. Yeni Play'le ilgili gorusum Simplicity concern'inden vazgecilmis.

Ne yalan soyliyim Ebean i ilk defa duydum, duydugum gibi de neymis bu diye baktim. Edindigim ilk izlenim, kullanim acisindan JPA'dan cok bi farki olmadigi, ama ek ozellikler bakimindan play'in high-performance concern'ine daha uyumlu oldugu. Cool'luk relative bi concept!

JPA tarafinda gordugum persistence.xml zorunlu yapilmis ki bence en basindan beri oyle olmaliydi. MVC ise, M ayri olacaksa, JPA olacaksa, ayrica gelistirilebiliyor olmali. Benzer mantikla JPA varsa hem mapping-annotation hem de JPQL var demektir, o konuda bi degisiklik olabilecegini sanmiyorum. J2EE konusuna hic girmeyelim...

5) Caching templates: "Caching in templates" basligina bakarsaniz template'in bi kisminin cache'lenebilecegini soylemis. Ben bunun ne ise yarayabilecegini hala bulamadim. Statik bir div'i niye cache'leyeyim ki? Statik olmayan seyin de icine konacak seyin binding'ini controller'da yapiyorum, view render edilene kadar zaten is isten gecmis olmuyor mu cache kullanmak icin?

Ancak div'in icine koydugum dinamik variable'in, o region cached ise controller'da compute edilmesini onleyen bi sistem yazdilarsa (oha derim) o zaman ise yarar gibi duruyor.

Cache'in yapisina bagli olarak statik div'de bile bir iyilesme saglanabilir (cok ciddi olacagini sanmiyorum). View render'in controller'daki binding'ten sonra olmasi ve dinamik variable in cached bi region icinde olmasinin controller'daki compute'a engel olabilmesi aslinda ayni konuya isaret ediyor: Bildigim kadariyla play2 deki template'ler play1'dekilerden farkli olarak _derleniyorlar_ ve objeler olarak calistiriliyorlar. Teorik olarak herhangi bir blok ayri bir metot cagiracak ya da bir cache'den okunacak hale getirilebilir. "Caching Templates" konusunda bahsedilen bu olmasa bile kolaylikla oha diyeceginiz yapilar hazirlanabilir.

6) Moduller ne olacak?: Hala Play 2.0 icin hicbir modul yazilmamis. Benim kullandigim toplam 2 modul var aslinda: play-morphia ve play-rabbitmq. Bunlari da zaten modules klasorume atip calistiriyorum. Ama bunlar Play 2.0'i desteklemedikleri surece 2.0'a gecmem mumkun olmayacak :-/ 

Bu konuda olusacak problemlerle ilgili daha once konusmustuk burada, klasik geriye-donuk uyumlu olmayan yazilim problemi. Bence bir an once o modullerin gelistiricilerine ulasip 2.0'a gecis takvimlerini ogrenmeye calisin. Cunku bir ihtimalde hic gecmeyecek olmalari. 1.2 icin listede gosterilen modullerin cogu su an bile gelistirilmiyor, bir kere yapilmis ve bir daha dokunulmamis olanlar var. Onlarin 2.0 icin ugrasmayacaklari asikar. Bir secenek de 2.0'a hic gecmeyip 1.2 den devam etmek ama o da daha buyuk problemler dogurabilir. Gecen bir ablanin yazisi vardi bununla ilgili...

~o~o~

Begendigim ozellikler de cok yeni Play'de

• Action'larin static void'den throwable atmalari yerine Result dondurmeleri guzel olmus.
• Akka entegrasyonu cok hos.
• Comet genelgecer herkesin isine yaramaz saniyorum ama WebSocket destegi gayet guzel.
• Global class'i ise yarar olmus. En azindan basitce request interception yapilabilir, hatalar handle edilebilir.
• Testing'de guzel seyler var. Test esnasinda app'in icinde fake app calistirma falan yapmislar. Cool. 
• Template engine'in guzel yanlari da var kotu yanlari da. Epey trade-off olmus. Eski tag'leri ozleriz galiba
• Bu sartlar altinda 1.2.x'den 2.0'a gecebiliriz belki bir haftasonu hackathon'unda. Ama ah iste su modules meselesi...

Siz neler dusunuyorsunuz?

Ben bi 7. madde eklemek istiyorum. Gelistirme ve deneme sureci biraz yavaslamis durumda. Scala compiler, eclipse compiler'a gore cok cok cok yavas. Dolayisiyla "bir kod degistireyim hemen F5'e basayim goreyim" yapisi "bir kod degistireyim hemen F5'e basayim, 5 saniye bekliyim, goreyim" haline gelmis.

Cok acil cikmam gerekti, maili toparlayamadim, kusura bakmayin. 

Herkese kolay gelsin

--
erdem agaoglu

[Ahmet Alp Balkan]

Cok minnettar oldum cevaplariniza Erdem Bey. Gercekten Scala compiler'in yavasligini ayni sekilde gozlemleyen var mi gruptan acaba? 

-- 

Ahmet Alp Balkan

[Çağrı ÜZEL]

15 Mart 2012 Perşembe 13:37:43 UTC+2 tarihinde Ahmet Alp Balkan yazdı:

Cok minnettar oldum cevaplariniza Erdem Bey. Gercekten Scala compiler'in yavasligini ayni sekilde gozlemleyen var mi gruptan acaba? 

Fakat 2.0 ile birlikte play run yerine geçicek play ~run komutu ile çalıştırdığında refresh etmene gerek 

kalmaması lazım. Otomatik değişikleri algılayıp compile ediyor diye biliyorum. Hatta ileride direk run 

komutuna entegre edilecek. 

[Umut Gurkavcu]

Scala yapımıcısı Martin Odersky'nin 2010 Eylül ayında bu konu hakkında stackoverflowda yazdığı bir yazıyı paylaşmak istedim :

There are two aspects to the (lack of) speed for the Scala compiler.

1. Greater startup overhead

   • Scalac itself consists of a LOT of classes which have to be loaded and jit-compiled

   • Scalac has to search the classpath for all root packages and files. Depending on the size of your classpath this can take one to three extra seconds.

   Overall, expect a startup overhead of scalac of 4-8 seconds, longer if you run it the first time so disk-caches are not filled.

   Scala's answer to startup overhead is to either use fsc or to do continuous building with sbt. IntelliJ needs to be configured to use either option, otherwise its overhead even for small files is unreasonably large.

2. Slower compilation speed. Scalac manages about 500 up to 1000 lines/sec. Javac manages about 10 times that. There are several reasons for this.

   • Type inference is costly, in particular if it involves implicit search.

   • Scalac has to do type checking twice; once according to Scala's rules and a second time after erasure according to Java's rules.

   • Besides type checking there are about 15 transformation steps to go from Scala to Java, which all take time.

   • Scala typically generates many more classes per given file size than Java, in particular if functional idioms are heavily used. Bytecode generation and class writing takes time.

   On the other hand, a 1000 line Scala program might correspond to a 2-3K line Java program, so some of the slower speed when counted in lines per second has to balanced against more functionality per line.

   We are working on speed improvements (for instance by generating class files in parallel), but one cannot expect miracles on this front. Scalac will never be as fast as javac. I believe the solution will lie in compile servers like fsc in conjunction with good dependency analysis so that only the minimal set of files has to be recompiled. We are working on that, too.
   

Yani özetle scala compiler'ın hiç bir şekilde javac kadar hızlı çalışabileceği düşünülmüyor. Play scala için en son olarak sbt kullanıyor ve incremental olarak derleme yapıyor. Bu konuda yapabileceği hzılandırmayı yapmış gibi. Ama arka planda ise fsc (fast scala compiler) kullanıp kullanmadığını bilmiyorum. Fsc kullanılırak açılıştan kaynaklı yavaşlamanın önüne nispeten geçilebiliyor. Eğer kullanılmıyorsa  ileride daha hızlı olacağını bekleyebiliriz. Ama kod büyüklüğü arttıkça development ortamında giderek artan bir yavaşlamayı hissedeceğiz anlaşılan.

[Mert Kavi]

Compiler hakkında kesinlikle katılıyorum inanılmaz yavaş hatta bazen cevap vermez oluyor.Birde template engine de kullanılan syntax'ı hiç beğenmedim.1.0 daha iyiydi o konuda bence.