Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: