Podobnie jak wiele innych, zawsze mam rację, że "czysty kompilator nigdy nie będzie istniał dla Ruby, ponieważ język jest zbyt dynamiczny, aby mógł działać statyczny kompilator."Ktoś wypróbował Crystal Programming Language (kod maszynowy skompilowany Ruby)?
Ale niedawno natknął nich:
The Crystal programming language at GitHub
Oba projekty wydają się być bardzo interesująca. Moglibyśmy dać nam szybkość języka w języku ojczystym (i często wymaganego w handlu, zaciemnionego kodu skompilowanego języka) przy zachowaniu wszystkich (lub większości) elegancji i elastyczności Rubiego. Dodaj dobrą bibliotekę wsparcia (lub, co bardziej prawdopodobne, możliwość dostępu do istniejących bibliotek C++) i łatwo zrozumiesz, dlaczego te rzeczy mogą być interesujące.
Czy ktoś próbował języka Crystal? (Jeszcze nie, z powodu kompilacji problemów z ruby-llvm)
Jakie było jego/jej odczucie na ten temat?
Czy sądzisz, że biorąc pod uwagę te wybory projektowe, możliwe byłoby stworzenie kompilatora kodu natywnego (maszynowego) dla Rubiego (z rozsądnym wysiłkiem i w rozsądnym czasie)? Czy będzie to znaczące?
W jaki sposób kompilator może nie być znaczący, jeśli jest poprawny? – Marcin
Czy byłby to znaczący (to znaczy: _użyteczny_) _do opracowania takiego kompilatora, oczywiście. Jak mogłem być tak idiotą, aby myśleć, że kompilator nie może być znaczący (to znaczy poprawny). – AlexBottoni
Podobno JRuby działa tak szybko, jak każda inna aplikacja Java (waga na wagę). Kiedyś używałem Smalltalk i myślałem, że to było _slow_ ...Jednak rzeczywiście było to IDE, które mieliśmy, było opóźnieniem. Rzeczywiste moduły Smalltalk zostały użyte z czasów uruchamiania C i C++. Mówię tylko, że języki ezoteryczne mogą być szybkie; to wspomniany już 99% potu. – will