@wilkerlucio I love the idea of (>fn). :) That doesn't actually exist, right? And if you start a Google Doc with any thoughts on instrumentation and performance, I'd love to collaborate. I actually have a very poor understanding of how it works, and I don't even understand what "production mode" actually is and how to enable it. I'd love to learn and integrate it into the docs. Thx!!!
@wilkerlucio PS: I agree on the default settings. That was actually my first question in this channel, to the effect of "how do I actually generating a run time typing error?"
@genekim
Production mode at the moment is basically when Ghostwheel is disabled, that is – no external config exists for it in the compiler options and the JVM option "-Dghostwheel.enabled=true" isn't set.
In that situation it simply strips all gspecs at compile time and otherwise doesn't do anything that would impact a production build. However due to external dependencies being pulled in, it might still increase the size of a production build if dead code elimination fails to fully strip all the extra code (and especially if you're not using advanced compilation which is necessary for DCE).
For that reason 0.4.0 will have a separate stub package you add to your production profile/alias which has no external dependencies and the regular module will be enabled by default to make getting started easier.
@wilkerlucio
In that context enabling instrumentation by default for specced functions might actually make sense, I'll definitely give it some thought.
As for expound – that was already meant to be enabled by default, but there were some issues with how it was done, especially in connection with cljs 1.10.520 which changed the way all of this is done. It's all sorted in 0.4.0 which is slightly delayed, I expect the beginning of next month, but you can have a look at 0.4.0-SNAPSHOT
for the preview.
P.S. Actually the newest stubs module is backwards-compatible with the older ghostwheel version: https://github.com/gnl/ghostwheel.stubs