Hacker News new | comments | ask | show | jobs | submit login

Well, I do have the same problems between unchecked and checked expressions. You get the speed only with series of checked expressions, but you have to cast to any/dynamic/cons boxed type on each boundary. This is the major slowdown. When the series of expressions is too short, no transformation to native should be done, because the casting and conversion back and forth is more expensive than the win by using the specialized ops.

Similarily SBCL/CMUCL has the similar problem with polymorphic explosion of generating too many methods, which are rarely used. Javascript V8 and friends solved that better.

My speed comes from avoiding consing, my native types are bitfields. Lisp types are usually a class pointer for every cons cell. For me certain casts are permitted, which are not permitted with Typed Racket. So yes, I have to permit traditional code which worked before, esp. with inferred types from literals. Racket has the advantage of defining stricter language subsets, which we only have with Perl 6 also. There you can override even language and type semantics.

Chez has a nice tagging scheme, which should speed up Racket a lot.

Several gradually typed languages don't infer from literals, but that's one of the best speed gains. E.g. the literal 1000 is a union of int32, int64, uint32 and uint64, all possible valid integer types for a certain value. A negative number cannot be unsigned, and a too large number cannot be 32bit. Problem is that people rarely add types, you need to infer 90% of them.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact