[HN Gopher] Hoot: Scheme on WebAssembly
___________________________________________________________________
Hoot: Scheme on WebAssembly
Author : AlexeyBrin
Score : 152 points
Date : 2026-02-07 12:18 UTC (10 hours ago)
(HTM) web link (www.spritely.institute)
(TXT) w3m dump (www.spritely.institute)
| NeutralForest wrote:
| It's such an amazing project, I wish it used something other than
| Guile but you can't have everything.
| Zambyte wrote:
| Other than Guile as in different Scheme implementations? It's
| usually not too difficult to port things between Schemes.
| Especially if you use standard R6RS or R7RS library syntax.
| noosphr wrote:
| Guiles debugging has been a nightmare in the 3.x series.
| Which is rather surprising since it was probably the easiest
| scheme to debug in the 1.x days.
|
| It got so bad I moved to racket as my daily driver.
| feastingonslop wrote:
| Which LLM works best for Racket?
| davidelettieri wrote:
| I found gemini 3 pro to be pretty good.
|
| Overall understanding of the code, code generation
| capabilities and ability to explain are all pretty good.
| wwfn wrote:
| Can you say more? Guile's the only scheme I've tried
| (attempts at packaging for Guix). Debugging has been
| difficult, but I figured it was me struggling with new
| tools and API. Does racket have better facilities for
| introspection or discovery at the REPL?
| pjmlp wrote:
| Yes, since years, all the way when it was still known as
| Dr. Scheme.
|
| It has a graphical experience similar to the survivors
| from Lisp is Great days, like LispWorks and Allegro
| Common Lisp, or Clojure with Cursive.
| pjmlp wrote:
| Even better than PLT Scheme with Dr. Scheme, now Raket has
| ever been?
|
| I have my doubts, given its age.
| NeutralForest wrote:
| A different scheme that has great debugging and testing and
| also better docs.
| zelphirkalt wrote:
| Guile has lots of libraries though, and is the language of
| Guix. This makes it more likely for people to package their
| stuff via Guix. Guix itself enriches the ecosystem, and Guile
| projects can use Guix to make them reproducible.
|
| A few problems remain though. A good debugger, a good macro
| expander (geiser in Emacs is able to expand somehow), and
| solving the issues with R6RS library syntax and standard
| library bindings, are what comes to mind.
|
| Racket's multi-core abilities for a long time were mostly heavy
| weight (places, starting whole new Racket VMs), except for
| their implementation of futures, but that one was not always
| useful. I think recently the situation in Racket has improved,
| but I don't know, whether it is as good as Guile fibers and
| futures (which are different from futures in Racket).
| NeutralForest wrote:
| Aside from the debugging & testing I already mentioned, going
| only through guix is a tough sell considering the very tiny
| amount of people that use it. It's also incredibly slow and
| doesn't have many packages available. Even for Emacs, it has
| this weird way of going around Emacs-installed packages (GNU
| or MELPA channels). Just like Guile docs, it also doesn't
| tell you of a good way to do things, it only says "here is
| what exists" with too little guidance imo. It means people
| have to figure out how to setup things properly on top of all
| the rest. It makes for a terrible onboarding.
| nerdponx wrote:
| If Guile had more of the "batteries" from the Gauche standard
| library it might be the perfect all-purpose Scheme. But for
| just writing a simple application quickly and easily it's
| been impossible to beat Gauche for me, it's on par with
| Python and Ruby in that regard IMO.
| terminalbraid wrote:
| > Guix itself enriches the ecosystem
|
| Except that ecosystem Guix provides is not on Windows nor
| MacOS, making a serious limitation to anyone who wants to
| develop guile on those platforms.
|
| I support GNU's mission in general, but I find it ironic that
| when they push freedom of choice you're forced to make the
| "right" choice or you're left twisting in the wind.
| threemux wrote:
| Very cool! Would this work with Cloudflare Workers potentially?
| sheepscreek wrote:
| I love this so much! It got me thinking about the future we're
| heading towards, that took me down a rabbit hole.
|
| As agents become the dominant code writers, the top concerns for
| a "working class" programming language would become reducing
| errors and improving clarity. I think that will lead to languages
| becoming more explicit and less fun for humans to write, but
| great for producing code that has a clear intent and can be
| easily modified without breaking. Rust in its rawest form with
| lifetimes and the rigmarole will IMO top the charts.
|
| The big question that I still ponder over: will languages like
| Hoot have a place in the professional world? Or will they be
| relegated to hobbyists, who still hand-type code for the love of
| the craft. It could be the difference between having a kitchen
| gardening hobby vs modern farming...
| billythethird wrote:
| I have been wondering what an AI first programming language
| might look like and my closest guess is something like
| Scheme/Lisp. Maybe they get more popular in the long run.
| spankalee wrote:
| I'm working on what I hope is an AI-first language now, but
| I'm taking the opposite approach: something like
| Swift/DartTypeScript with plenty of high level constructs
| that compactly describe intent.
|
| I'm focusing on very high-quality feedback from the compiler,
| and sandboxing via WASM to be able to safely iterate without
| human intervention - which Hoot has as well.
| xkriva11 wrote:
| Smalltalk offers several excellent features for LLM agents:
|
| - Very small methods that function as standalone compilation
| units, enabling extremely fast compilation.
|
| - Built-in, fast, and effective code browsing capabilities
| (e.g., listing senders, implementors, and instance variable
| users...). This makes it easy for the agent to extract only
| the required context from the system.
|
| - Powerful runtime reflectivity and easily accessible
| debugging capabilities.
|
| - A simple grammar with a more natural, language-like feel
| compared to Lisp.
|
| - Natural sandboxing
| cess11 wrote:
| If someone wants to try it out, both Glamorous Toolkit and
| plain Pharo have tooling that allows integration of both
| local and remote LLM services.
|
| Some links to start off with:
|
| https://gtoolkit.com/
|
| https://github.com/feenkcom/gt4llm
|
| https://pharo.org/
|
| https://omarabedelkader.github.io/ChatPharo/
|
| Edit: I suppose the next step would be to teach an LLM
| about "moldable exceptions",
| https://arxiv.org/pdf/2409.00465 (PDF), have it create its
| own debuggers.
| zozbot234 wrote:
| LLM's are mainly trained on English natural language text, so
| you'll want a language that looks as much as possible like
| English. COBOL is it, then.
| bloppe wrote:
| I think the bitter lesson has an answer to that question. The
| best AI language is whichever one has the largest corpus of
| high quality training data. Perhaps new language designers
| will come up with new ways to create large, high quality
| corpi in the future, but for the foreseeable future it looks
| like the big incumbents have an unassailable advantage.
| t1amat wrote:
| Perhaps the opposite: a language small enough that its
| entirety can easily be stuffed in context.
| behnamoh wrote:
| This is what JavaScript was supposed to be until Netscape forced
| the dude to use a C/Java-like syntax.
| xbumblefudgex wrote:
| woot
| veqq wrote:
| It's fascinating how much development's occurring in Guile
| recently. Unfortunately, a lot seems to be ex-Racketers moving
| over. The splitting of community effort's sad (particularly as
| Guile e.g. greatly lags Racket performance or lacks nice
| libraries like Gauche).
| neilv wrote:
| I'm happy for Guile to be getting more attention, but wouldn't
| write off Racket. A few quick thoughts...
|
| * The recent Guile work on WASM is promising. (Note also Jens
| Axel Soegaard's recent work on WASM with a Racket-related
| compiler.)
|
| * Racket's rehosting atop Chez seems like a good idea, and I'd
| guess that the Racket internals are now easier to work with
| than Guile's.
|
| * Racket has done a lot of great work, and is a nice platform
| for people who can choose their tools without worrying about
| employability keywords for their resume. It made some missteps
| for broader adoption when it had a chance, and several of the
| most prominent industry practitioner contributors left.
|
| * Racket still has the best metaprogramming facilities, AFAIK.
| But even more important than `syntax-parse` and `#lang`, one
| thing I'd really like from Guile and other Schemes is to
| support Racket's module system.
|
| (I really like the ability to define Racket submodules inline,
| in fragments, for things like embedded unit tests
| <https://docs.racket-lang.org/overeasy/> and embedded API docs
| <https://docs.racket-lang.org/mcfly/>.)
|
| (I also wanted to play with Racket's module system for PL
| research compilers: having early compiler implementation for a
| new language first expand into Scheme code, and then later
| (with submodules) also do native/VM code generation, while
| keeping the option to still expand to Scheme code (for better
| development tools, or for when changing the language). For
| example, imagine targeting a microcontroller or a GPU.)
|
| * Right now, any Scheme is for people who don't have to do
| techbro/brogrammer interviews. The field has been in a bad
| place for awhile, professionalism-wise, and the troubled
| economy (and post-ZIRP disruption of the familiar VC growth
| investment scams) and the push to "AI" robo-plagiarism (albeit
| with attendant new investment scams) are suddenly making the
| field worse for ICs.
| veqq wrote:
| > write off Racket
|
| I wrote that Guile "greatly lags" Racket.
| b00ty4breakfast wrote:
| Glad to see stuff like this, it seemed like the hype for
| compiling to wasm died out a while ago. Hope we keep seeing more
| wasm languages so I can continue to avoid using javascript, ha!
___________________________________________________________________
(page generated 2026-02-07 23:00 UTC)