> Are there Python language features I can't use in Hy?

At the semantic level, no. I work to cover 100% of Python AST node types with Hy's core macros. It does take me a little bit to implement a new core macro after the CPython guys implement a new feature, but you can always use the `py` or `pys` macros to embed the Python you need, should it come to that.

> Or performance penalties in using Hy?

Compiling Hy (that is, translating it to Python AST) can be slow for large programs (I've seen it top out at about 3 seconds), but at runtime you shouldn't see a difference. Hy always produces bytecode, which can be used to skip the compilation step if the code is unchanged.

You take a little performance hit upon initial startup (from a clean filesystem, while __pycache__ folders are created). Other than that, mostly everything is the same.

I'm now figuring out how to pack images to OpenAI REST calls (using my own REST wrapper), and everything is peachy. Here's my test snippet (mostly to b64encode the file):

    (import aiohttp [ClientSession]
            base64  [b64encode]
            asyncio [run])

    (defn :async pack-image [filename]
      (with [h (open filename "rb")]
        {
          "type" "image_url"
          "image_url" { "url" f"data:image/jpeg;base64,{(.decode (b64encode (.read h)) "utf-8")}" }
        }))

    (defn :async main[]
      (print (await (pack-image "request.hy"))))

    (run (main))

This shows you async, context managers, selective imports, f-strings... etc. All that you need, really.

Lack of self-contained tooling. Idle doesn't work with Hy. You'll probably need to fiddle with Emacs to set your environment first, before being able to do anything beyond playing with the language in the REPL.

IDLE is not designed for this, obviously. But you can debug Hy using standard Python tools.

Sure - you are piling another transpilation layer on top of already slow Python.

Why not just use something closer to the metal: Common Lisp, Scheme, Clojure, Racket? Especially, use a compiled language, instead of an interpreter.

If I were to guess, it's to be able to use the all the packages in the Python ecosystem, directly. It's for situations in which Python is already a given. In fact, it's probably the case that many Python programmers can't even use this, due to being in a situation in which even the poor syntax is nonnegotiable.

I do use Racket. And over half the time I switch to Python because I don't want to author libraries that already exist in Python.

this 100%. We have some options today to run Python from CL when necessary:

https://github.com/digikar99/py4cl2-cffi

https://github.com/marcoheisig/lang