3 ms·

Eliding the string interpolation doesn’t necessarily have to be a feature of the logging library, the language itself can have affordances for this. For exampl

Eliding the string interpolation doesn’t necessarily have to be a feature of the logging library, the language itself can have affordances for this. For example in swift, log.debug("my name is \(expensiveCalculate(name))") doesn’t have to evaluate “expensiveCalculate(name)” unless the logger actually opts to instantiate the string (which it can skip if say, debug logging is disabled.) This is because Swift’s string interpolation is implemented as lazily-evaluated closures, and all the “debug” method has to do is tag the input as an @autoclosure and it can avoid evaluation until it actually calls the closure. No templating is needed, just native string interpolation provided by the language.

dikei 5y ago
I would consider a programming language's native string interpolation as a form of templating, but to each his own.
- ninkendo 5y ago
  I was specifically responding to: > All logging libraries contain some kind of template engine as a performance optimization This doesn't need to be the case for some languages. But also, a language's native string interpolation doesn't need to be implemented as any sort of runtime template engine in the first place, because the compiler can compose the the components of the interpolated string at compile time. This compile-time/runtime split is IMO the key differentiator here, because runtime string interpolation is much more prone to bugs/RCE (since an untrusted string may show up as your template string.) To use an example, in swift, `f1("Some \(string) with \(vars)")` is fundamentally different than calling `f2("Some {} with {}", string, vars)`, because of the fact that such a method signature for "f2" may allow an untrusted string to show up as the first argument, which isn't possible in f1. (And no, an external string that happens to have \()'s in it will not be expanded... it has to be a string literal in the source code, which the compiler can see, for interpolation to happen.)
Spivak 5y ago
While nice this feature doesn't really exist in other programming languages that don't involve the caller unergonomically wrapping the parameter to defer evaluation.
andrebreves 5y ago
It's coming to Java (soon I hope): https://openjdk.java.net/jeps/8273943 https://openjdk.java.net/jeps/8273943

dikei 5y ago

I would consider a programming language's native string interpolation as a form of templating, but to each his own.

ninkendo 5y ago
I was specifically responding to: > All logging libraries contain some kind of template engine as a performance optimization This doesn't need to be the case for some languages. But also, a language's native string interpolation doesn't need to be implemented as any sort of runtime template engine in the first place, because the compiler can compose the the components of the interpolated string at compile time. This compile-time/runtime split is IMO the key differentiator here, because runtime string interpolation is much more prone to bugs/RCE (since an untrusted string may show up as your template string.) To use an example, in swift, `f1("Some \(string) with \(vars)")` is fundamentally different than calling `f2("Some {} with {}", string, vars)`, because of the fact that such a method signature for "f2" may allow an untrusted string to show up as the first argument, which isn't possible in f1. (And no, an external string that happens to have \()'s in it will not be expanded... it has to be a string literal in the source code, which the compiler can see, for interpolation to happen.)

Spivak 5y ago

While nice this feature doesn't really exist in other programming languages that don't involve the caller unergonomically wrapping the parameter to defer evaluation.

andrebreves 5y ago

It's coming to Java (soon I hope): https://openjdk.java.net/jeps/8273943 https://openjdk.java.net/jeps/8273943