9 ms·

> Because Askama will generate Rust code from your template files, the crate will need to be recompiled when your templates change. Being Swift a compiled lang

> Because Askama will generate Rust code from your template files, the crate will need to be recompiled when your templates change. Being Swift a compiled language just like Rust, why can we modify the templates (Stencil, Mustache) in Swift without recompiling the app but not in Rust?

tyoverby 10y ago
Does Mustache compile into .swift files that need to be typechecked and linked into the binary?
orf 10y ago
Is the answer not in the section you quoted?
zacmps 10y ago
Are they dynamically linked?
zacmps 10y ago
Are they dynamically linked?
detaro 10y ago
Stencil and Mustache do that because they don't compile to Swift, but load and parse templates dynamically. That kind of template language implementation of course exists for Rust as well. (And the other way round, you could have a system that's like this submission for Swift, if there isn't one already)
- Entangled 10y ago
  That's exactly the point, why do that in Rust when it can be done without the need for compiling it? That's the explanation I want to hear. Having to recompile the whole app just to test changes in the template is absurd in my handbook.
  - sinhpham 10y ago
    Because you can then catch errors at compile time instead of run time.
  - detaro 10y ago
    Performance, type-safety. Is it worth it? No idea, haven't tried it, and probably depends a lot on your use case and development process.
  - dochtman 10y ago
    My main reason was type safety; getting early feedback from the compiler is really valuable to me. I don't see compiling them as a big downside, either. What problems do you see with that? Tera (https://github.com/Keats/tera https://github.com/Keats/tera) exists already if that's more your cup of tea.
  - db48x 10y ago
    Parsing templates at run-time is a run-time cost, possibly amortized by caching. If it's done at compile time then it only has to happen once (or anyway a lot less frequently than your program will be run). On the other hand, perhaps it could parse them dynamically in debug mode (and statically in release mode), but notice that the library creates a structure to hold the data that is inserted into the template. In debug mode it would have to do dynamic lookups into that structure, which means capturing its layout for use at run time. All the other template features would likewise need some run-time implementation. You'd end up writing everything twice. If you're willing to do that extra work, you might instead think about writing a JIT compiler for your template language. Instead of caching the AST of a template, a JIT implementation would generate and cache runnable code. On the gripping hand, one of the things that makes static compilation possible here is that the template compiler uses macros to generate Rust code, which the Rust compiler then compiles. To do a JIT you would either have to write your own compiler, or embed all of Rust (and LLVM) into the application. You wouldn't be the first to make a language that makes the entire compiler available at run time, but there's always a cost to that.

tyoverby 10y ago

Does Mustache compile into .swift files that need to be typechecked and linked into the binary?

orf 10y ago

Is the answer not in the section you quoted?

zacmps 10y ago

Are they dynamically linked?

zacmps 10y ago

Are they dynamically linked?

detaro 10y ago

Stencil and Mustache do that because they don't compile to Swift, but load and parse templates dynamically. That kind of template language implementation of course exists for Rust as well. (And the other way round, you could have a system that's like this submission for Swift, if there isn't one already)

Entangled 10y ago
That's exactly the point, why do that in Rust when it can be done without the need for compiling it? That's the explanation I want to hear. Having to recompile the whole app just to test changes in the template is absurd in my handbook.
- sinhpham 10y ago
  Because you can then catch errors at compile time instead of run time.
- detaro 10y ago
  Performance, type-safety. Is it worth it? No idea, haven't tried it, and probably depends a lot on your use case and development process.
- dochtman 10y ago
  My main reason was type safety; getting early feedback from the compiler is really valuable to me. I don't see compiling them as a big downside, either. What problems do you see with that? Tera (https://github.com/Keats/tera https://github.com/Keats/tera) exists already if that's more your cup of tea.
- db48x 10y ago
  Parsing templates at run-time is a run-time cost, possibly amortized by caching. If it's done at compile time then it only has to happen once (or anyway a lot less frequently than your program will be run). On the other hand, perhaps it could parse them dynamically in debug mode (and statically in release mode), but notice that the library creates a structure to hold the data that is inserted into the template. In debug mode it would have to do dynamic lookups into that structure, which means capturing its layout for use at run time. All the other template features would likewise need some run-time implementation. You'd end up writing everything twice. If you're willing to do that extra work, you might instead think about writing a JIT compiler for your template language. Instead of caching the AST of a template, a JIT implementation would generate and cache runnable code. On the gripping hand, one of the things that makes static compilation possible here is that the template compiler uses macros to generate Rust code, which the Rust compiler then compiles. To do a JIT you would either have to write your own compiler, or embed all of Rust (and LLVM) into the application. You wouldn't be the first to make a language that makes the entire compiler available at run time, but there's always a cost to that.