添加一个通用code-gen后端以Juliago和chez-scheme脉络(即没有LLVM)将有多困难。
LLVM会是一个更好的方法吗 - 考虑到rust和crystal也几乎完全是自托管的，他们可以利用LLVM发出二进制文件，甚至交叉编译。
作为背景，我在这里问了一个关于各种LLVM前端code-gen的问题 在LLVM上实现自托管语言时面临哪些问题？
Julia 确实有一种形式的代码生成，即其类型化的 AST。可以在任何函数调用前面使用@code_typed查看键入的 AST。从理论上讲，您可以使用它向任何 IR 发出，Julia 出于其他地方说明的原因选择了 LLVM IR。Transpiler.jl 是一个软件包，它这样做是为了从 Julia 函数输出 OpenCL 代码等内容。
您可以使用 LLVM IR 发出其他字节码。CUDANative.jl 使用 LLVM 的 .ptx 后端直接从 Julia 函数发出 CUDA 内核。@polly项目正在寻求做类似的事情，即宏将允许 Julia 自动加速 GPU 上的某些代码(我承认对此知之甚少，除了阅读建议它的帖子和后续内容。这被选为LLVM的GSoC项目)。
rustc 链接并使用 LLVM，通过 LLVM C API 和 C++ 中的扩展包装器，作为 C ABI 公开。我不了解水晶，但有些语言确实直接针对文本或字节码LLVM IR，这有一些潜在的优势，但也存在性能和兼容性问题。
至于"有多难"：NaN，我猜？最直接的方法是从Julia的类型推断降低形式开始，它已经接近SSA。具有良好编译器背景的人可能会在短时间内(~几个月)编写一个未优化(溢出，无代码移动等)，一个架构模板汇编器。没有编译器背景的人可能需要大量的研究才能正确表述问题。