Credo che sia una combinazione di cose:
- Rubino viene interpretato, e l'interprete potrebbe essere migliorata. Ad esempio, altri linguaggi interpretati come JS o Java hanno un ottimo compilatore VM e JIT.
- Molti controlli di Ruby eseguiti in fase di esecuzione, in Crystal vengono eseguiti in fase di compilazione. Ad esempio, una semplice chiamata di metodo in Ruby termina con una ricerca di metodo. Anche con una cache non batterà una chiamata di funzione nativa. O quando Ruby decide di fare cose diverse in base al tipo di argomento, questi controlli vengono eseguiti in fase di runtime. In Crystal sono noti al momento della compilazione, quindi questi controlli scompaiono. Senza questi controlli il compilatore può effettuare chiamate in linea e fare cose piuttosto folli (grazie a LLVM). Oppure, per esempio, la ricerca di un caso di istanza è una ricerca di hash in Ruby (per quanto ne so), mentre in Crystal è solo una memoria indiretta e carica.
- In Crystal cerchiamo di evitare allocazioni di memoria aggiuntive. Ad esempio,
to_s(io) scrive su un IO invece di convertire l'oggetto in una stringa in memoria. Oppure abbiamo tuple per array di dimensioni fisse che sono allocati nello stack. Oppure puoi dichiarare un tipo come struct per evitare allocazioni di heap.
- Le chiamate a C vengono eseguite direttamente, senza wrapper. Bene, potresti avere un wrapper, ma questo sarà sottolineato da LLVM. In Ruby è sempre necessario risolvere prima un metodo Ruby.
Probabilmente ci sono molti altri motivi, ma sono correlati.