O Melhor de Dois Mundos
Propaganda
JRuby O Melhor de Dois Mundos www.akitaonrails.com Baseado na apresentação da Mountain West Conf. Termos Gerais • MRI - Matz Runtime Interpreter • C Ruby - mesmo que MRI • GC - Garbage Collector • JIT - Just In Time • AOT - Ahead of Time • JVM - Java Virtual Machine 2002 Charles Nutter Thomas Enebo Setembro de 2006 Sun Senior Engineers Objetivos: • Compatibilidade com Ruby • Facilidade de Integração • Ruby como Linguagem de 1o. Nível • JVM melhor para Linguagens Dinâmicas JRuby é sobre Ruby Por que Ruby no Java? Problemas no Design do Ruby Threading • 1.8 • ‘Green’ Threads • Não escala • Bibliotecas C travam threads Ruby Threading • 1.9 • Threading não-paralelo • Bibliotecas internas não thread-safe • Global Locking • Pode quebrar extensões Unicode ‘Em que ano estamos ?’ Unicode • 1.8 • Decreto da W3C • Suporte parcial, mas não consistente • Suporte por aplicação: Rails MultiByte Unicode • 1.9 • Suporte completo • Quebra muita coisa • Cada String pode ter sua codificação • Comportamento imprevisível Performance • 1.8 • Fato: mais lento que outras linguagens • ‘Rápido o suficiente’ • Acaba em último nos benchmarks • Esta versão não vai mudar Performance • 1.9 • Melhor, mas nem tanto • 3 a 4x mais rápido em alguns casos • Muita coisa não muda • Beta somente no fim de 2007 Gerenciamento de Memória • 1.8 • Design simples • Razoavelmente bom, mas não escala • GC do tipo ‘Pausa no Mundo’ Gerenciamento de Memória • 1.9 • Nenhuma mudança • Se a performance realmente aumentar, significa mais lixo • Problemas na GC serão mais visíveis Extensões • 1.8 • Problema: C • Crash • Threading, GC • Recompilar • Segurança Extensões • 1.9 • Não muda • Extensões limitam mudanças • “performance = escrever em C” “Quem quer escrever C ?” Política • Cultura corporativa • Java e .NET vistos como ‘estáveis’ • Empresas Grandes • Empresas Lentas Legado • Muito código Java existente • Gigantesca Comunidade Java • Grandes Investimentos em Infra Resumindo • Problemas: • Green Threads • Unicode parcial • Performance • Gerenciamento de Memória • Extensões em C • Choque de Cultura O Caminho JRuby Threading • Threads Nativos • Escala em múltiplos processadores e múltiplos sistemas • Execução Paralela • Sistema agenda Threads • Garante nível de segurança Unicode • Classe Mundial • Suporte Nativo • Garante compatibilidade Performance • Escalável • Não há porque JRuby ser mais lento que MRI 1.8 • Suporte do bytecode do MRI 1.9 • Compilação para bytecode Java Gerenciamento de Memória • Gerenciamento da JVM • Melhor GC do mundo • Diversas opções • Altamente escalável • Testado no mundo todo Extensões • Escritas em Java • Mais simples que C • Quase impossível derrubar JVM • Portável • Todas as funcionalidades do Java • Sem problemas de GC, threading • “Todo mundo” sabe Java Política • JRuby: apenas “mais um” pacote Java • Mais fácil trocar de framework do que de arquitetura • Impacto nível na operação • 10 anos de Java Legado • Integração instantânea • Chamar Java a partir do Ruby • Implementar serviços em Ruby • Implantar em Infra existente • Todas as vantagens da JVM O que JRuby pode fazer ? • Na maior parte: “simplesmente roda” • Compatível com MRI 1.8.5 • Quase 100% compatível com Rails Ruby + Java = Incrível Java dá o que Ruby precisa • Virtual Machine • Bibliotecas numerosas e flexíveis • Java pode ser complicado • Bom para escrever biblioteca • Ruim para “grudar” os componentes? Ruby dá o que falta a Java • Metáfora Unix • Bibliotecas em C, aplicativos em Dynlangs • JVM é o novo kernel, Java é o novo C • Ruby completa o Java “O Todo é maior que as Duas Metades” Exemplos: Swing: Pensado para ter Extensibilidade e Flexibilidade Infinitas Geralmente não precisamos de extensibilidade e flexibilidade infinitas Problema do Mundo Java: Muita atenção aos casos extremos “Just in Case” JRBuilder “SwingBuilder” NetBeans Tor Norbye • Disponível no “Update Center” • Coloramento de Sintaxe • Auto-complete • Renomeamento de Variáveis • Hyperlinking • Roda scripts • WEBRick dentro da IDE Muito mais opções • Para quem não pode usar TextMate: • Eclipse/Aptana • Ruby in Steel • IntelliJ • jEdit • JBuilder • JDeveloper Medindo Compatibilidade • MRI • Não existe especificação • Não existe suíte de testes completa • Suítes parciais • Testes do MRI, BFTS, Rubicon, ruby_test • Suítes de aplicações (RSpec, Rails) • Suíte própria • Outras implementações (Rubinius) • Community Test • www.headius.com/rubyspec • JRuby mailing list • www.headius.com/jrubywiki Testes (pré 1.0) • Ruby Samples Test • 95% para cima • Ruby Unit Tests • 90% para cima • Rubicon • cerca de 80% Rails 1.2.1 • ActiveSupport 99,19% • ActionPack 99,30% • ActionMailer 90,63% • ActionWebService 100% • ActiveRecord 95,35% Rails 1.2.1 • 2827 testes, 62 falhas ou erros (97,70%) Outros Testes • BFTS (quase 90%) • ruby_test (incerto ainda) • RSpec (99%) • Suíte próprio (100% !) • cobertura excede 80% ActiveRecord-JDBC • Usa drivers JDBC no back-end • Suporte quase completo para os principais bancos de dados Medindo Performance • Não temos padrão de Benchmark • Alioth ‘Shootout’ tests • Ruby 1.9 benchmarks • Rails requests-per-second Rails req/seg (WEBRick) • Ruby 1.8.4 • estático: 301.09 • dinâmico: 121.74 Rails req/seg (WEBRick) • Boa parte interpretado • Pequena parte usando JIT • JRuby 0.9.8 (Jave 6 Server VM) • estático: 180,03 • dinâmico: 50.53 JRuby Compiler • Ahead-of-Time • Just-In-Time • Design Incremental Outro exemplo • fractal.rb • MRI (1.8.5) • 6.7 seg • JRuby (1.0 RC3) • 68.7 seg Outro exemplo Outro exemplo • MRI 1.8.6 • 6.9 seg • JRuby (RC3) • 6.4 seg (5.6 na décima interação) O que vem por aí ? • Viável hoje • Aproximando do MRI rápido • Muitas capacidades acima do MRI • Mais e mais aplicações já rodando • “Teste a sua aplicação hoje!” ThoughtWorks 40% dos projetos em Rails Obrigado!
