The Racket folks have always been most helpful and never turned down a request to fix anything.
Apologies that may have come across as more accusative than I intended. I was just surprised that whatever missing(?) feature or behavior that would cause one to move off of Racket wouldn't be of interest to other Racket users
The big difference between SBCL and Racket today is support for parallelism, and that's about decisions made by both projects a very long time ago. Racket has incrementally added significantly more parallelism over the years, but supporting lightweight parallel tasks that do IO (as in a web server) is still not something Racket's great at.
(Source: I'm one of Racket's core developers.)
My assumption is that creating a compiler and runtime to match sbcl isn't in scope for racket, so it wouldn't be polite to request racket to do so :) there were probably other benefits of similar orthogonal features, where racket users don't necessarily need it, but another language/runtime already has it because that's where people who need that go
Isn't Racket using the (also) very fast Chez Scheme underneath?
SBCL is disgustingly performant, and while Racket is fine for most applications you'll still notice sometimes that it's executed on a VM and hasn't prioritised speed to the same degree.
In addition, Common Lisp provides standardized ways to get fast code: OPTIMIZE policy, type annotations, stack allocations, disassemblies, etc. This is all there before you get to SBCL's specific tools for optimization and profiling.
Chez compiles, I think, its not a VM. It’s not as fast as SBCL of course, but it’s not interpreted.
It's what they consistently call it here, VM and bytecode:
https://docs.racket-lang.org/guide/performance.html
As I understand it the difference between raco make and raco exe is that the latter bundles a VM.
I don't really care about these minutiae, it's a great platform for GUI development that consistently builds as well on Debian as Windows.
From this very page you've linked to
"Every definition or expression to be evaluated by Racket is compiled to an internal bytecode format, although “bytecode” may actually be native machine code. In interactive mode, this compilation occurs automatically and on-the-fly. Tools like raco make and raco setup marshal compiled bytecode to a file, so that you do not have to compile from source every time that you run a program. ... For the CS implementation of Racket, the main bytecode format is non-portable machine code."
There's more about what this entails here and how to view the generated assembly: https://docs.racket-lang.org/reference/compiler.html#(part._...
>it's s a great platform for GUI development
Can you elaborate on that? I'm interested in deciding on a good tech stack for desktop GUI app development for personal projects, so was interested in your comment.
Sure. There is a rather extensive toolkit that comes with the basic distribution, https://docs.racket-lang.org/gui/. For that you can use MrEd to build your layouts if you want, https://github.com/Metaxal/MrEd-Designer.
The problem with that approach is that you need to figure out some parts on your own, like state management. If you need that flexibility it's still a good option, or you'd opt for gui-easy, a library on top of the GUI toolkit that adds observables for state management and a more declarative API, https://docs.racket-lang.org/gui-easy/index.html.
I haven't managed to get cross-compilation going but I've had no problem just copying my Racket files to another computer and build there. It's supposed to be possible however, you'll probably manage to figure it out if it's important to you.
The gui-easy library makes it trivial to pack up some small tool in a GUI in a few tens of lines of code. I'm guessing there is a way to prune the binaries but don't really care about it myself, I just go with the default ~20 MB executables.