I have found it easier to control my program at the byte level in SBCL than in racket although I have pursued that more in SBCL than I have in racket. I would expect you can get them both to run pretty pretty fast if you try but the model of common lisp is much closer to the way a computer actually works than scheme

You can write programs at quite a low level in Racket. In some places it can be a bit harder to predict the assembler output than in SBCL, I think, and there are some low-level operations that aren’t provided, and some that maybe don’t generate as good code as you might want. But in general the situation between Racket and SBCL is similar.

Does using Typed Racket allow for optimizations similar to what you’d get with declare in SBCL? In standard Racket I’ve used various unsafe- functions to improve speed, but without a way to declare a variable’s type I felt like I was always guessing.

Yes, Typed Racket optimized based on types. However, SBCL declare can do more than just optimize based on what the type is, it will also change the behavior, eg with fixnums you get wraparound instead of bignum promotion.

Thanks for the response. Does Typed Racket make any optimizations that a programmer couldn’t make manually using just standard Racket? Obviously Typed Racket would be a safer and easier way to accomplish this, but just curious. I haven’t delved into Typed Racket yet.

No, everything you can do with Typed Racket you could do yourself (Typed Racket is just a library, so this has to be true).

And if this :point_up: doesn’t blow your mind, I don’t know what does

Ok, that is what I expected to hear. Thanks! (but it is kind of mind blowing anyway when you think about this compared to other languages.)

Thanks for replying guys

There’s also the FFI, so you can write parts in any language that are compatible with C-bindings, right? Though IIRC the FFI has overhead?

Speaking in generalities, but most FFI overhead is in the coercion of types (to native types and from native types). This is compounded when talking about threading or the need to freeze memory locations and such. The overhead costs can be easily amortized as long as the calls themselves are somewhat large. For example, calling a vec3_dot_product C function would likely be horrifically bad compared to just doing it in Racket. But, calling blit_sprite would be a huge win.