1. 21
    1. 4

      Racket would have to be able to target arm64 for that to be feasible

      It does. Without JIT, only interpretation, but works fine.

      1. 2

        Interesting! I had no idea. Do you have any links I could take a look at?

        1. 2

          I don’t have any links. On normal desktop/server aarch64 platforms, you (or the OS packager) just compile it as usual (without --enable-jit) and it just works. It’s cross-platform.

          1. 3

            Sweet. I’ll have to play around with that. I’ve updated the article. Thanks!

            EDIT: Turns out there is info about cross-compilation to iOS and Android in the Racket source README:


    2. 3

      Nice architecture! I have to confess that I was a wee bit disappointed, because I misinterpreted the title. I expected a native GUI defined in Racket; but in fact it’s a platform-agnostic core written in Racket, plus a native GUI written in another language (Swift).

      Still, a very nice architecture, and I hope you get the library version with in-process interop working, too. Good luck, and have fun!

      Edit to add: your architecture, with a platform-agnostic core and a platform-specific front-end, reminded me a lot of Simon Tatham’s portable puzzle collection (enough that I went to look it up for you, and the figured I might as wel submit it to Lobsters). That project has game-specific backends, platform-specific frontends, and both-agnostic middleware that lets the games and the platforms compose to give m × n combinations. The architecture and the problem it solves are a bit different from yours, but perhaps there are enough parallels to make it relevant.

      1. 2

        Thanks! I can see how the title might be interpreted that way. I should’ve added “at their core” to the end or something.

        Those puzzles look really cool, thanks for the link.