HN user

LiberalArtist

4 karma
Posts0
Comments3
View on HN
No posts found.

But that is also merely a JS only forum, so not ideal. There used to be the Google groups thingy including a mailing list. Google, so not ideal either. But at least it had a mailing list.

I was a long-time skeptic of moving away from the Google Groups list, so I try to be equally vocal in saying that the move to Discourse was handled really well IMO. In fact it is not "a JS-only forum": you do need to sign up in the web UI, but, after that, you can put it in "mailing-list mode" and ignore the website completely, including for starting new threads (see <https://racket.discourse.group/t/how-to-enable-mailing-list-...>). The email interface is important to many Racketeers; if other Discourse instances don't enable it, that's their admin's choice. The Google Groups list had been rendered nearly unusable by spam, and it was never free and open-source software, which Discourse is. (I wrote more detailed thoughts at the time in <https://groups.google.com/g/racket-users/c/RnIAQnZpvh0/m/A78...>.)

On the other hand, I share some of your concerns about Discord (the similar names are unfortunate). But there was never an organized "move to Discord": some people just started talking about Racket there, as people had before, and still do, on IRC and Slack and all sorts of places. People are also regularly nudged to move non-transient conversations to searchable and archived venues.

FYI, Racket has a `get-handle` method to get a native handle from a `window<%>`: https://docs.racket-lang.org/gui/window___.html#%28meth._%28...

There are ways to optimize executable size with various tradeoffs, though they require compiling Racket yourself or using a Racket BC distribution. By default, Racket generates machine code (including natively on M1), which tends to be larger than bytecode. That's only been the default since February 2021, so I'd bet there's still room for improvement in code size for the default configuration.

I think "Programming Languages: Application and Interpretation" does much of what you want: in particular, it takes the view that "from our perspective parsing is mostly a distraction, because we want to study the parts of programming languages that are not parsing." The author, Shriram Krishnamurthi, puts the complete text online for free at http://cs.brown.edu/courses/cs173/2012/book/