Scala: sua próxima linguagem?

Uma das mudanças mais pronunciadas no cenário da informática é a modificação no  perfil da lei de Moore. Gordon Moore, fundador da Intel, observou que o número de transistores em um microprocessador dobra a cada dois anos. Esse crescimento exponencial, até poucos anos atrás, era refletido em um aumento do clock – a velocidade – dos processadores. Mas agora o clock atingiu um limite, e o adicional de transistores é cada vez mais direcionado para aumentar o número de cores de processadores e, assim, ampliar o nível de concorrência.

O que isso tudo significa é que nós, programadores comums, não podemos mais nos dar ao luxo de ignorar as dificuldades da programação concorrente. E essas dificuldades não são pequenas, como qualquer um que já teve de programar bastante para concorrência em Java, usando as primitivas wait-notify de um monitor, deve saber. O pior: você pode errar quando definir suas regiões críticas, e isso só será descoberto quando um entrelaçamento de threads específico ocorrer, o que pode vir a demorar dias com o sistema em produção, para só então o bug aparecer.

No fundo, os problemas da programação concorrente têm origem na dificuldade em sincronizar mudanças de estado. Mas existe um estilo de programação que procura evitar ao máximo mudanças explícitas de estado: a programação funcional, que tem ganhado muita atenção para desenvolver sistemas web. Scala é uma linguagem de programação moderna – sua primeira versão é de 2003 – e procura vencer as batalhas da concorrência num campo familiar: a JVM. Comprometida com o pragmatismo, Scala não é uma linguagem funcional pura, mas híbrida, procurando unir o que há de mais avançando em orientação a objetos com conceitos funcionais. Foi criada pelo professor Martin Odersky, que tem a distinção de ser o autor do compilador de Java do JDK, e vem sendo desenvolvida pela sua equipe na universidade suíça EPFL.

Embora facilitar a programação concorrente seja uma meta declarada através de imutabilidade e outros recursos, existem motivos para se interessar por Scala mesmo para quem não pretende se aventurar além do código sequencial: Inferência de Tipos permite que se programe de maneira menos burocrática sem perder as garantias de correção, refactoring e auto complete, a que estamos acostumados quando desenvolvemos em Java, Funções Anônimas permitem um estilo de programação altamente produtivo, especialmente ao lidar com coleções, Pattern Matching ajuda a trabalhar com estruturas aninhadas, como ao fazer parsing de XML, e a sintaxe flexível é ótima para DSLs internas. Esses e outros motivos levaram o Twitter a migrar de Ruby para Scala alguns de seus subsistemas.

Código Scala compila para bytecodes java normais, e é trivial invocar código Java de Scala e vice-versa. Tamanha integração com o ambiente Java levou o criador de Groovy, James Strachan, a especular que Scala é o melhor candidato a substituir Java no longo prazo. Não contente com esta polêmica, Strachan ainda afirma que se conhecesse Scala na época, não teria enxergado a necessidade da criação do Groovy. O próprio James Gosling afirmou que escolheria por Scala se tivesse de optar por outra linguagem.

Não é de hoje que a Caelum acredita em um futuro plural, e no melhor estilo programação poliglota, já desenvolvemos partes importantes de um sistema Java em Scala, onde consideramos que ela era cabível. Para quem quiser saber mais sobre Scala, o tour da linguagem é um bom recurso para matar a curiosidade. Mas é claro que o melhor meio de conhecer uma linguagem é meter a mão na massa, e para isso recomendo o tutorial First Steps to Scala, de autoria do próprio Martin Odersky colaborando com Bill Venners e Lex Spoon. Esse tutorial foi extraído de trechos do livro Programming in Scala, dos mesmos autores.

Três últimas recomendações, agora mais sobre programação concorrente em geral: veja os slides de uma apresentação do Jonas Bonér sobre os diversos paradigmas de programação concorrente e paralela, o vídeo de uma apresentação do Guy Steele, um dos “criadores” do Java, sobre Fortress, sua linguagem de pesquisa para computação científica maciçamente paralela, e um capítulo de livro do Peter van Roy, também sobre paradigmas de programação concorrente e paralela. Pra quem prefere o bom e velho Java, vale o livro Java Concurrency in Practice, que trata o assunto a fundo e chega a detalhes da JVM e do funcionamento do pacote java.util.concurrent.

34 Comentários

  1. Fabio Kung 10/08/2009 at 03:00 #

    Como um grande entusiasta de programação funcional, também recomendo uma olhada em Erlang.

    Tem também este post interessante comparando as abordagens para concorrência de ambas: http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/

    Muito bom post Rafael!

  2. Tiago Fernandez 10/08/2009 at 06:30 #

    Bom post!

    Apenas para acrescentar que também vale a pena dar uma olhada no framework web Lift, que é escrito em Scala:

    “Lift is an expressive and elegant framework for writing web applications. Lift stresses the importance of security, maintainability, scalability and performance, while allowing for high levels of developer productivity.

    Lift borrows from the best of existing frameworks, providing

    * Seaside’s highly granular sessions and security
    * Rails fast flash-to-bang
    * Django’s “more than just CRUD is included”
    * Wicket’s designer-friendly templating style (see Lift View First)

    And because Lift applications are written in Scala, an elegant new JVM language, you can still use your favorite Java libraries and deploy to your favorite Servlet Container. Use the code you’ve already written and deploy to the container you’ve already configured!”

    http://liftweb.net

  3. William Antônio Siqueira 10/08/2009 at 12:04 #

    Todo mundo falando de Scala… Desde o post que o pessoal comentou lá no GUJ…

    http://www.guj.com.br/posts/list/131987.java

    E alguns outros artigos que tem aparecido…

  4. Luca Bastos 10/08/2009 at 12:12 #

    Já dei muitas olhadas em erlang e em Scala.

    Erlang é aquele negócio que dá um nó na nossa cabeça enquanto a gente está aprendendo. Depois pouco a pouco acha bem legal e fica louco para usar. Até hoje (uns 3 anos depois de aprender) ainda não consegui usar para nada (realmente não sou nenhum Damien Katz). Sei que que tem gente por aí que usa para estressar aplicações porque fazer um servidorzinho poderoso em erlang é fácil.

    Scala dá asas ao Java e reaproveita todo o legado. A primeira vez que li o livro do Bill Venners (ainda em beta) poucas referências haviam na web sobre Scala. Neste ano de 2009 noto um interesse crescente, vários livros foram lançados e muita gente blogando. Não é só para aplicações concorrentes que Scala pode oferecer vantagens e por este motivo voltei a estudar Scala. E o Lift contem algumas boas idéias.

    Não sei se um dia Scala atingirá um grande público porque há outras alternativas mais fáceis como Ruby/Rails ou Python/Django. Mas vale a pena estudar.

  5. Pedro Matiello 10/08/2009 at 12:52 #

    Sugiro o Scala by Example, também do Odersky, para continuar depois do First Steps. É o que eu estou usando enquanto minha cópia do Programming in Scala não chega e tenho gostado bastante.

    http://www.scala-lang.org/docu/files/ScalaByExample.pdf

  6. Alberto 10/08/2009 at 15:03 #

    Livrinho Programming in Scala já está aqui do meu lado :)

  7. Luiz Aguiar 10/08/2009 at 15:25 #

    Eu dei uma olhada bem por cima no Lift, a primeira impressão foi de um pouco “burocrático”, dependência do maven e etc, pra quem já se acostumou ao Rails é meio chatinho, mas como disse, foi bem por cima, preciso olhar mais de perto com mais cuidado.

    Excelente post!

  8. Celso Martins 10/08/2009 at 15:35 #

    Também estou estudando pelo Programming in Scala e estou gostando bastante. Me chamou a atenção a questão da programação concorrente, como dito nesse ótimo post. Unir o melhor do mundo OO com funcional também me chamou a atenção.

    Luca:
    Em que sentido a alternatica Ruby/Rails seria “mais fácil”?

    abraços

  9. Leandro Silva 10/08/2009 at 16:11 #

    Adoro Scala…

    http://leandrosilva.com.br/2008/08/27/um-pouco-de-diversao-com-scala

    http://leandrosilva.com.br/2008/08/31/mais-diversao-com-scala

    http://leandrosilva.com.br/2008/11/03/sim-programacao-funcional-e-relevante-hoje

    Mas ainda não consegui gostar de Lift. Não sei, não acho ele muito pragmático, pelo contrário, IMHO, ele é meio verboso, meio sei lá, entende? :)

    Mas justiça seja feita: Gosto da maneira como Lift trata requests HTTP, delegando o processamento e resposta a um ator e deixando a thread que recebeu o request livre para atender outras requisições. Isso dá um ganho em número de request/s incrível.

    Scala rocks!

  10. Leandro Silva 10/08/2009 at 17:37 #

    Kung, também sou fã de Erlang e assino embaixo de sua recomendação.

    E sobre comparativos entre Erlang e Scala, tem dois posts de uma minazinha griga (Susan Potter da gem Twitter4R) que acho bem interessantes:

    http://geek.susanpotter.net/2009/04/scala-vs-erlang-debate-part-1-managers.html

    http://geek.susanpotter.net/2009/04/scala-vs-erlang-debate-part-2-geek-off.html

    Acho Erlang uma linguagem belíssima e absurdamente simples — se comparada ao resultado que se pode obter com ela. Gosto muito da sua simplicidade mesmo.

    No começo é um pouco chato de entender o OTP, mas depois que você pega o jeito, já era, você tem uma metralhadora nas mãos.

  11. Luca Bastos 10/08/2009 at 19:02 #

    @Celso

    Acho que em tudo quando se trata de fazer uma nova aplicação web. Realmente me impressiona a facilidade do Rails e também do Ruby.

    Já o Scala é bem mais complicadinho de entender e de gravar as regras. Para estudar o livro Programming in Scala precisei criar um arquivinho .txt para ir anotando os termos novos e definições que ia encontrando (as pencas)

    @Leandro Silva

    Na verdade o Lift não é o melhor, é o único… mas promete algumas coisas interessantes. Por enquanto há pouca documentação além do Exploring Lift em http://tinyurl.com/nsau2x

    Parabéns a você por ter achado erlang simples…para mim tive que aprender um monte de conceitos novos e nem consegui descobrir onde usar. Quem passou a vida usando linguagens em que recursão era pouco performático e gastador de recursos, reescrever os algoritmos na cabeça para usar recursão é sofrido.

  12. Rafael de F. Ferreira 10/08/2009 at 20:09 #

    Concordo com o pessoal que Erlang também é uma linguagem interessante, principalmente do ponto de vista da prog. concorrente. Mozart/Oz e Clojure também apresentam umas idéias legais. E, claro, existem as duas linguagens canônicas qdo se fala de programação funcional: Lisp e Haskell.

    Assim como o Luiz Aguiar, eu não consegui gostar muito de Lift, mas preciso dar uma nova olhada.

    Pelo que eu notei, estamos numa terceira onda de buzz sobre Scala. A primeira foi na época do lançamento do livro beta do Odersky, depois outra foi quando o livro saiu em papel, e agora essa terceira foi deflagrada pelo Strachan.

    PS: thanks, kung!

  13. Marcio Duran 12/08/2009 at 14:42 #

    Sem maior comentário

    – Otimo post !!!!

  14. Rafael 13/08/2009 at 17:21 #

    Isso me fez lembrar a famosa entrevista do Donal Knuth (http://www.informit.com/articles/article.aspx?p=1193856)
    Além da polêmica sobre TDD ele tb tem um opinião controvérsia quando o assunto é programação concorrente!

  15. Paulo Suzart 14/08/2009 at 23:56 #

    Scala é uma linguagem fantástica e particularmente estudo desde que concluí meu curso de Design e Arquitetura na Caelum em Abril/08.
    Tenho escrito sobre a linguagem no meu blog e atualmente implemento um framework usando Scala e Rabbit MQ.
    Como já disse no stackoverflow, Scala é uma linguagem staticamente tipada com cara de dinámica, e compilada com sabor de script.

    Vale muito a pena sair na frente com Scala!

  16. bcarvalho_9@hotmail.com 21/08/2009 at 12:30 #

    bem interessante pra ler

  17. William Gouvea 26/08/2009 at 06:13 #

    Como dito acima, vale a pena olhar o Clojure!

    Baseada no velho e “concorrente” Lisp, essa linguagem possui soluções brilhantes que facilitam a vida de quem migra para o paradigma funcional:
    =>Multimethods(Polimorfismo)
    =>Estrutura de Dados Imutaveis ex: REF’s
    =>Metaprogramação extendida do LISP
    =>STM ex:Agent’s

    Alem disso, existem alguns frameworks interessantes como o Compojure,voltado para Web, baseado na API Sevlet do Java, usando o padrao REST para as rotas, sendo totalmente adaptavel, devido a grande capacidade atribuida pela metaprogramação(macros).

    Clojure resgata conceitos sobre concorrencia ja resolvidos nos anos 50 quando JohnMcCarthy, criou o LISP e usou a linguagem em pesquisas com inteligencia artificial, tendo inclusive cunhado o termo “Cloud Computing”.

    Resumindo:

    =>Linguagens como Clojure,Common Lisp,Haskell, geram codigo puramente funcional ,que é mais plugavel e facil de testar!

    =>Com Clojure você pode utilizar o pacote de concorrencia (JSR-166) de forma bem clara , inclusive englobando o padrão Fork/Join(Divisão e Conquista), Pools de Workers e Executores.

    =>Com Clojure você se beneficia de uma API explicita e mutavel para se adequar as suas necessidades de concorrencia e escalabilidade!

    Bate-Bola entre caracteristicas do Erlang e Clojure:

    Erlang: O FIlme Clojure: O Podcast
    Atribuição de Sinal Estrutura de Dados Imutaveis
    Mnesia STM
    ErlangVM JVM
    Hipe JIT
    Pattern Matching Multimethods
    Erlang Shell REPL
    Recarga de Codigo “Quente” Compilação Dinamica
    Behaviours Bastrações Extensiveis
    Recursao de Cauda recur
    fun fn
    sintaxe desde 1987 sintaxe desde 1958
    EMP2 CL smacros

    Artigo sobre Cloud Computing e Clojure
    http://amsterdaintelligence.blogspot.com/2009/08/cloud-computing-clojure-concorrencia.html

    Artigo comparando Erlang vs Clojure
    http://weblambdazero.blogspot.com/2008/08/clojure-is-here.html

    Vale a pena aprender o pradigma funcional aliado as facilidades da JVM =, inclusive ja foram registrados alguns casos em produção de sistemas usando Clojure, Scala e Erlang…Fica ao gosto a escolha!

  18. Rafael Noronha 16/09/2009 at 11:54 #

    Interessante ver ambas as plataformas apostando no paradigma funcional.
    (Em .NET começa a ganhar notoriedade o F#).
    http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/

    Acho que o Rafael Ferreira colocou muito bem, uma hora o luxo de não usar concorrência vai acabar, e as ferramentas vão precisar estar adequadas às necessidades.

  19. Oracle 22/10/2009 at 09:13 #

    Goslim e Strachan estáo certos, Scala é muito melhor que Groovy. Groovy é como um Java cheio de açùcar mas levando em consideração o invetimento que a SpringSource vem fazendo em Groovy e Grails acho que o Groovy vai suceder o Java.
    Esse apoio comercial faz com que o framework e a linguagem evoluam muito rápido sem falar em algo fundamental que scala ainda peca muito, tooling. Groovy e Grails já são bem suportados nas 3 maiores IDEs no mercado java, Eclipse(na distro da SpringSource), Netbeans e Intellij.

    A minha impressao é que Scala tem um foco muito mais matematico e academico, enquanto Groovy existe quase que unicamente pra facilitar a vida dos programadores java. Isso vai fazer um grande diferença na adoção e sucesso dessas linguagens.

  20. Marcio Duran 01/02/2010 at 17:11 #

    Ola , Oracle !!!

    Uma coisa é um acordo comercial outra coisa é a Ciência, se o proprio criador do Groovy o Sr.Strachan chegou em seu veredito sobre SCALA então não podemos descartar o que já é propriedade e merito de quem já vem com força a conquistar a real continuação de Java.
    Java é hoje em minha visão um sistema operacional dessas linguagem de meta-programação, e SCALA não é um engine é uma real-full stack nascente do proprio Java, ou melhor o back-end das aplicações legadas extendidas pra as complexidades da WEB e scripts dinamincos que necessitam se interoperabilizar da JVM sem perda de performance.

    Abraçosss

  21. Oracle 02/05/2010 at 01:12 #

    Não argumento contra a capacidade técnica do Scala(tem poucissimos argumentos contra scala aliás) mas Groovy é muito maior comercialmente e tem recebido cada vez mais apoio, pricipalmente graças ao grails.

    Acho que todos sabemos que nem sempre a linguagem mais capaz é a que domina, senão smalltalk e haskell teriam um espaço muito maior.

    O futuro mais provavel hoje é que nenhuma linguage sucederá o java, mas varias linguages coexistiram na jvm, Cada uma com seu nicho. Sob esse prisma dá para ver a vantagem do groovy e do grails de suceder o java no nicho de desenvolvimento web na jvm. Nesse nicho, o maior competidor e jruby on rails.

  22. Rahul G 03/07/2010 at 03:10 #

    Ótimo post! Continuem o bom trabalho! :)

  23. Wanderson Santos 14/06/2011 at 17:16 #

    @Oracle “A minha impressao é que Scala tem um foco muito mais matematico e academico, enquanto Groovy existe quase que unicamente pra facilitar a vida dos programadores java. Isso vai fazer um grande diferença na adoção e sucesso dessas linguagens.”

    Esta afirmação foi profética. É realmente o que está acontecendo.

    A comunidade Scala é elitista / acadêmica (leia Scala is for Good Programmers), enquanto a comunidade Groovy é humilde e se importa com as pessoas – que são os maiores valores de um sistema de informação.

    James Strachan falou bobagem ao citar que Groovy foi um erro, o tratou como um bastardo. Muito feio! James não é o pai do Groovy.

    Pai não é quem cria, mas quem estimula o filho a crescer. O pai do Groovy tem nome, aliás, tem vários: Guillaume LaForge e o Groovy Team.

    O time liderado por @glaforge (e puxado pela comunidade Grails por grandes homens como @hartsock e @burtbeckwith) elevou Groovy a um nível impressionante.

    Hoje o desempenho do Groovy 1.8 já chega muito perto de linguagens estáticas (Java/Scala), ultrapassa C não-otimizado em certos casos, e tem o melhor desempenho desempenho dentre todas as linguagens dinâmicas do mercado, a saber Ruby, Python, PHP, etc.

    Veja:http://regispires.wordpress.com/2010/10/23/comparacao-de-performance/

    Ou seja, já não é preciso escrever hot-spot code com outra linguagem: Groovy virou uma linguagem séria pra fazer desde scripting até grandes sistemas corporativos.

    Dêem uma olhada no desempenho do Grails 1.4. É impressionante! http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

    Gosta de static checking? Você tem isso com Groovy no IDEA Compiler e todas as vantagens de uma linguagem dinâmica (Scala não é dinamica) como AST e MOP. Você ainda vai ouvir falar destas siglas!

    Dá pra programar rotinas paralelas com Actors (sim!), Parallel Collections, Agents e várias outras abordagens existentes em várias linguagens, com a extensão GPars.

    Enfim, Groovy é uma grande inovação na plataforma Java porque atualmente quebra o trade-off de escolha de linguagem para a JVM.

    Existem quesitos subjetivos como “gosto pela sintaxe”, mas no ambito não subjetivo ela é melhor para equipes existentes porque você programa próximo a Java de uma forma evolutiva – dá pra usar sintaxe Java. Não é a mulher bonita ou a inteligente, é uma e outra, imbatível.

    Quem quiser aprender mais sobre Groovy e Grails terei prazer em ajudar no Twitter: @wanswins e no fórum Tectura.

    Devemos dar a parte justa a quem é devido. A SpringSource e a comunidade Groovy & Grails tem feito um belíssimo trabalho. Tenho orgulho de fazer parte desta comunidade.

    Abraço e bons códigos!

  24. Wanderson Santos 14/06/2011 at 17:24 #

    Em tempo, Programação Poliglota não é sobre fazer um sistemas com várias linguagens para o mesmo propósito, é usar linguagens específicas para cada domínio.

    Mas também isso não quer dizer que não devemos estudar outras linguagens! O que não indica que devemos utilizar de fato todas elas. A sabedoria mora no equilíbrio.

    Bons códigos!

  25. Paulo Silveira 14/06/2011 at 18:02 #

    Olá Wanderson.

    Primeiramente, parabéns pela maneira de organizar e expor suas ideias e opiniões.

    A linguagem pode ser elitista, mas não diria que tem intenção de não ser humilde… é algo que acabou acontecendo, não como objetivo.

    Foi uma infeliz citação do Strachan. Usamos no post para mostrar que Scala realmente chama atenção, não para desmerecer nenhuma outra linguagem.

    Como você bem colocou, o interessante da programação poliglota é usar cada linguagem no domínio mais interessante, e com certeza groovy e grails têm seu espaço.

    E muitos programadores Scala também defenderão que é possível para programar Java em Scala (ok, não com a exata mesma sintaxe) e aprender mais de uma maneira evolutiva.

    Sobre o static checking, numa linguagem dinamica como o Groovy haverá uma limitação. Não há como inferir os métodos de um parâmetro x que não teve seu tipo declarado… no máximo heurísticas baseadas no seu uso, que podem levar a erro. No Scala isso não ocorre, e há programadores que trabalham melhor com essa segurança da tipagem estática, por mais testes de unidade que ela faça. Alguns programadors acham essa a imbatível, mas concordo que seria uma imbatível com muitas, muitas idiossincrasias.

    Mesmo com a tipagem estática do Scala, os plugins para IDE ainda engatinham, mesmo o IntelliJ. Talvez o plugin do groovy esteja melhor, não sei dizer.

    valeu de novo pela exposição.

  26. Wanderson Santos 14/06/2011 at 19:24 #

    Paulo, eu que agradeço por equilibrar minha visão!

    São pessoas humildes como você que fazem este mundo ficar melhor. ;-)

    Sim, o suporte a Groovy é muito completo. O IntelliJ IDEA tem um suporte quase mágico, ele consegue completar até métodos dinâmicos por inferência! O plugin Eclipse não fica atrás.

    Para Grails, o IDEA Ultimate ($199) é imbatível, e vale o preço – eu acho que vale até mais! Tem o Eclipse STS (Spring Tools Suite) que é gratuito e tem bom suporte também.

    Ser livre é saber escolher e não ser escravo das paixões. Saber errar pra acertar.

    Já dizia o profeta: “Não me envergonho de mudar de opinião porque não me envergonho em pensar”.

    Muito obrigado pelo seu equilibrio!

  27. Wanderson Santos 14/06/2011 at 19:29 #

    Ah, e toda generalização é passível de erros, como eu dizer que a comunidade Scala é elitista – claro que não é todo mundo, mas é a visão de mil pés.

    Generalização não passa da abstração de um sistema, neste caso social. E por definição, toda abstração é passível de erros, é furada. Já dizia Joel Spolsky:

    Law of Leaky Abstractions
    http://www.joelonsoftware.com/articles/LeakyAbstractions.html

    Have a nice day, ever!

  28. Wanderson Santos 14/06/2011 at 19:34 #

    Desculpa a tagarelice! ;-)

    @Paulo Silveira “Não há como inferir os métodos de um parâmetro x que não teve seu tipo declarado… no máximo heurísticas baseadas no seu uso, que podem levar a erro”

    Na prática, utilizo Groovy em time há 3 anos aqui na Eteg e nunca tivemos problemas nesta área. Aliás, problemas de sintaxe são os menores.

    Ainda por cima, rs, praticamos revisão em pares, que além de resolver este problema, resolve muitos outros, como gerar backlog para workshops internos e evoluir o time.

    PS.: A gente aplica o Butcher’s Pattern: vai cortando as gorduras do código, fazendo ele ficar Groovy. Make It Work, Then Make It Right. ;-)

  29. Will 11/01/2012 at 12:44 #

    Comentário atrasado, hehe.

    Achei bem interessante o post sobre Scala e também os comentários sobre o Groovy dados pelo Wanderson. Devo dizer que na minha empresa eu trouxe o Groovy e optei pelo Groovy acima do Scala por dois motivos:

    1) Scala é mais complexo, em conceito e sintaxe. Não é sempre que você tem uma equipe de programadores Scala ou uma equipe de programadores Java disposta à aprender Scala. Temos programadores com pouco tempo de experiência.

    2) Ainda que o suporte à XML em Scala seja nativo, é menos verboso trabalhar com XML em Groovy. Nós utilizamos bastante XML e webservices.

    No meu blog falo bastante sobre as duas. Continuo pesquisando Scala e acho muito interessante.
    Outro ponto interessante são as checagens de tipagem estáticas que Groovy 2.0 vai ter, deixando o potencial do Groovy++, e de tipagem estática, nativas na linguagem.
    E IMHO a declaração do Strachan só é válida para ele. Ainda bem que ele desenvolveu o Groovy, pode deixar que a gente continua o trabalho ;-)

Deixe uma resposta