anchor.diff:  Note that all of these are eager transformations - they produce the output vector when you invoke them. The original sequence version `(map inc (filter odd? [1 2 3]))` is lazy and will only produce values as needed (with chunking under the hood for greater performance). Neither of these is right or wrong, but they are both useful in different circumstances.
   
   [[transducers_vs_seqs]]
  -**What are good use cases for transducers?**
  +**<<faq#transducers_vs_seqs,What are good use cases for transducers?>>**
   
   When performing a series of transformations, sequences will create an intermediate (cached) sequence between each transformation. Transducers create a single compound transformation that is executed in one eager pass over the input. These are different models, which are both useful.
   
  
positive.code: == Compiler
  
  [[direct_linking_repl]]
  **How does direct linking affect the REPL experience?**
  
  Anything that has been direct linked will not see redefinitions to vars. For example, if you redefine something in clojure.core, other parts of core that use that var will not see the redefinition (however anything that you newly compile at the REPL will). In practice, this is not typically a problem.
  
  
negative.code: == State and Concurrency
  
  [[concurrency_features]]
  **<<faq#concurrency_features,What are the trade-offs between reducers, core.async, futures, and pmap?>>**
  
  Each of these really addresses a different use case.
  
  - Reducers are best for fine-grained data parallelism when computing a transformation over existing in-memory data (in a map or vector). Generally it's best when you have thousands of small data items to compute over and many cores to do the work. Anything described as "embarrassingly parallel".
  - futures are best for pushing work onto a background thread and picking it up later (or for doing I/O waits in parallel). It's better for big chunky tasks (go fetch a bunch of data in the background).
  - core.async is primarily used to organize the subsystems or internal structure of your application. It has channels (queues) to convey values from one "subprocess" (go block) to another. So you're really getting concurrency and architectural benefits in how you break up your program. The killer feature you can really only get in core.async is the ability to wait on I/O events from multiple channels for the first response on any of them (via alt/alts). Promises can also be used to convey single values between independent threads/subprocesses but they are single delivery only.
  - tools like pmap, java.util queues and executors, and libraries like claypoole are doing coarse-level "task" concurrency. There is some overlap with core.async here which has a very useful transducer-friendly pipeline functionality.
  
  [[write_skew]]
  **<<faq#write_skew,Why does the Clojure STM does not guarantee serializability but only snapshot isolation?>>**
  
  If reads were included by default, then STM would be slower (as more transactions would require serializability). However, in many cases, reads do not need to be included. Thus, users can choose to accept the performance penalty when it is necessary and get faster performance when it is not.
  
  == Namespaces
  
  [[ns_file]]
  **<<faq#ns_file,Do namespaces map 1-to-1 with files?>>**
  
  No (although that is typical). One namespace can be split across multiple files by using `load` to load secondary files and `in-ns` in those files to retain the namespace (clojure.core is defined in this way). Also, it is possible to declare multiple namespaces in a single file (although this is very unusual).
  
  [[ns_as_fn]]
  **<<faq#ns_as_fn,Do namespaces work like regular functions? Looking at the syntax, it seems ns could be returning a function that makes a namespace, and then if you just stick parens around the contents of the file, that would be a regular S expression too. Does that imply you can put more than one in a file?>>**
  
  ns is a macro that does a number of things:
  
  