Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp?
More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?
More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using 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.
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))
Why not just use something closer to the metal: Common Lisp, Scheme, Clojure, Racket? Especially, use a compiled language, instead of an interpreter.