racket-gui-easy VS racket-binfmt

Looks like you're already in Emacs. I strongly recommend racket-mode as mentioned in another thread.

With regard to prototyping GUI's I'd suggest taking a look at https://github.com/mfelleisen/7GUI. https://github.com/Bogdanp/racket-gui-easy could also be a good place to start.

With regard to Racket more generally, I'm probably not the best person to ask since I had a very high friction start where I just banged my head against the wall until things made sense.

I took a similar approach in my Racket library, gui-easy[1,2]. Though I opted to not defer any computations, any observable (similar to a signal from the post) update propagates to observers immediately, and there's no incrementality -- observables are just boxes whose changes you can subscribe to. Regarding the disposal problem, I used weak references and regarding the where to take observables and where to take concrete values as input question, I decided that any place an observable can go in, a concrete value can as well and it's been a convenient choice so far. For fun, here's an example[3] that builds the todo UI from the post.

[1]: https://docs.racket-lang.org/gui-easy/index.html

For native apps, I would devote coding resources to the Guile-GI project which generates Guile bindings to the cross-platform Gtk C library by way of the Gnome Object Introspection and Reflection library. I would also port the Racket gui-easy library over to Guile-GI so declarative GUIs could be written.

There is also gui-easy a declarative gui framework: https://docs.racket-lang.org/gui-easy/index.html

It’s not the only version either

See https://github.com/Bogdanp/racket-gui-easy/tree/master/examp...

  },

Racket internalizes Extra-linguistic mechanisms https://felleisen.org/matthias/manifesto/sec_intern.html

Also the fact that various DSLs can inter-op with each other directly, so that you can use something like a binary parser description, as if it was just another Racket library. For example this description of the format https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-..., is directly included in another file as a regular library https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-...

I agree that startup time is not a winning aspect of Racket. My naive understanding is because Racket is not a direct bytecode interpreter like CPython, but actually has to run a compile step to native code, and doing that for programs + their required libraries necessarily takes at least a couple of hundred milliseconds even before anything can start running, while CPython can pretty much start executing from the get go.