>I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong.

When I was working on Hy, almost 10 years ago, there was a couple of Hy core devs that had managed to push some Hy code into production. I won't name names, but a known company used Hy when processing firewall rules (if i recall correctly).

I doubt that code is still being used, and I'm not aware of anyone beyond a couple of previous Hy core devs that managed to push Hy into production.

> You can transpile to Python

I can imagine speed being a real problem in production?

You can take the AST produced by Hy and produce Python with `ast.unparse`. https://docs.python.org/3/library/ast.html#ast.unparse

People use Python in production, why not Hy?

There are plenty of reasons not to add a transpilation step to production code:

* Looking at stack traces is suddenly so much harder and involves reverse-engineering the transpiler unless your transpiler is sophisticated enough that it can de-transpile the stack traces back to the source language.

* You're adding a step to your build pipeline.

* You're taking on the risk of bugs or security issues that may exist or be introduced to the transpiler itself.

* Your developers need to learn both the source and target languages.

* If the transpiler project is abandoned, you have to begin maintaining it yourself, or you need to de-obfuscate your transpiled code enough to make it your canonical code.

I think that anyone who used CoffeeScript in the late 2000s / early 2010s understands the pain of using a transpiled language that wasn't worth the trouble.

Not to say that one should never transpile, or that Hy's not worth it or not production ready! Just that, there are things to consider, and how much you need to consider them depends on what your "production" is.

Hy isn't transpiled though, it's compiled into valid python bytecode so some of the traditional issues around transpilation doesn't apply to Hy.

Hylang doesn't add anything to your build pipeline, because of some tricks. Stack traces aren't that useful in Lisp but the bytecode refers to the actual source code positions.

Multiple languages are less of an issue when you have a small team or a team of one.

I'd be willing to use Hylang in production. I wouldn't go all-in, but rather pick something that looks like it needs a DSL. You can still interface with Python code interchangeably whenever you want, so there really is not much pain to abandon the attempt completely.

If you write your code in Python, many team members or new hires will already know Python and hence be able to dive right in to the code base.

If you write your code in Hy, many people are going to have no idea. Small chance they already know it. A minority of people will have some background in Lisp, and if you already know both Python and another Lisp, learning Hy should be straightforward. But for a Lisp-naive developer, it is a big speed bump.

Also there is a lot of existing tooling around Python code – static analysis, etc – which might not be able to handle Hy. Sure, it can process the transpiled Python, but that produces a lot less pleasant experience for the developer. You really want native Hy tools, which are going to be behind native Python tools.