<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 9:03 AM, Nicola Larosa <span dir="ltr"><<a href="mailto:nico@teknico.net" target="_blank">nico@teknico.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":23f" class="a3s" style="overflow:hidden">Mentre immagino che Go sia off limits, giusto?<br></div></blockquote></div><br>Non che io sappia. Il problema piu' grosso che vedo in Go e' eventualmente relativo al fatto che ci deve essere un po' di esperienza nel team sull'argomento. Scala e' piu' facile da tirar dentro perche' almeno per CR e quick-fix masticare un po' di Java e' quasi sempre stato sufficiente. L'altro win e' sulle librerie... quasi sempre abbiamo librerie in Java per fare cose, e chiamarle da Scala, sebbene a volte sub-ottimale, funziona piuttosto bene. </div><div class="gmail_extra"><br></div><div class="gmail_extra">L'altro grosso vantaggio che vedo in Scala e' che da un punto di vista di system engineering riusi molto la conoscenza di Java. I deployment sono quasi analoghi. Le infrastrutture molto simili. Hai sempre la JVM cui chiedere metriche, puoi aspettarti sintomi molto sintomi di problemi comuni. Etc etc etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nota, non sto dicendo che fare la stessa cosa in Go sia piu' difficile, complicato o peggiore. Semplicemente e' un mondo un pochetto diverso.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Poi anche li, quando fai un handover di un progetto in Scala ad un team che non ha conoscenza di Scala i problemi ci sono eccome. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Tutto questo ovviamente in un contesto generico, non posso e non voglio parlare di cose specificamente accadute.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><br></div>-- <br> .<br>..: -enrico-
</div></div>