Asami is both similar to and different from other graph databases. Some of the goals of the project are:

Schema-less data. Data can be loaded without prior knowledge of its structures.
Stable. Storage uses immutable structures to ensure that writes cannot lead to data corruption.
Multiplatform. Asami runs on the Java Virtual Machine and on JavaScript platforms (browsers, node.js, etc).
Ease of setup. Asami managed storage requires no provisioning, and can be created in a single statement.
Pluggable. Storage is a pluggable system that allows for multiple storage types, both local and remote.
Analytics. Graph analytics are provided by using internal mechanisms for efficiency.

Asami is a schemaless database, meaning that data may be inserted with no predefined schema. This flexibility has advantages and disadvantages. It is easier to load and evolve data over time without a schema. However, functionality like upsert and basic integrity checking is not available in the same way as with a graph with a predefined schema. Optional schemas are on the roadmap to help with this.

Asami also follows an Open World Assumption model, in the same way that RDF does. In practice, this has very little effect on the database, beyond what being schemaless provides.

If you are new to graph databases, then please read our Introduction page.

Asami has a query API that looks very similar to a simplified Datomic. More details are available in the Query documentation.

Sayid (siy EED) is an omniscient debugger and profiler for Clojure. It extracts secrets from code at run-time.

Sayid works by intercepting and recording the inputs and outputs of functions. It can even record function calls that occur inside of functions. The user can select which functions to trace. Functions can be selected individually or by namespace. The recorded data can be displayed, queried and profiled.

This is a companion post to my discussion with Craig Andera on Relevance Podcast Episode 32 and my Clojure/West talk Clojure in the Large. I've talked about various bits and pieces of this workflow at other times, too, but I'll try to bring it all together here in the hopes that others will find it useful.

One of the great pleasures of working with a dynamic language is being able to build a system while simultaneously interacting with it. To make this possible, first you need the ability to redefine parts of the program while it is running: Clojure provides this capability admirably. However, some aspects of Clojure's runtime are not quite as late-binding as one might wish for interactive development. For example, the effect of a changed macro definition will not be seen until code which uses the macro has been recompiled. Changes to methods of a defrecord or deftype will not have any effect on existing instances of that type.

Deep in your innermost being, you’ve always known you were destined to learn Clojure. Every time you held your keyboard aloft, crying out in anguish over an incomprehensible class hierarchy; every time you lay awake at night, disturbing your loved ones with sobs over a mutation-induced heisenbug; every time a race condition caused you to pull out more of your ever-dwindling hair, some secret part of you has known that there has to be a better way.

Now, at long last, the instructional material you have in front of your face will unite you with the programming language you’ve been longing for.

Fast serialization library for Clojure

Clojure's rich data types are awesome. And its reader allows you to take your data just about anywhere. But the reader can be painfully slow when you've got a lot of data to crunch (like when you're serializing to a database).

Nippy is a mature, high-performance drop-in alternative to the reader.

It is used at scale by Carmine, Faraday, PigPen, Onyx, XTDB, Datalevin, and others.

Why Nippy?

• Small, simple pure-Clojure library
• Terrific performance: the best for Clojure that I'm aware of
• Comprehensive support for all standard data types
• Easily extendable to custom data types
• Robust test suite incl. coverage of every supported type
• Mature and widely used in production for 12+ years
• Optional auto fallback to Java Serializable for safe types
• Optional auto fallback to Clojure Reader (including tagged literals)
• Optional smart compression with LZ4 or Zstandard
• Optional encryption with AES128
• Tools for easy + robust integration into 3rd-party libraries, etc.
• Powerful thaw transducer for flexible data inspection and transformation

Fast Idiomatic Pretty-Printer

Fipp is a better pretty printer for Clojure and ClojureScript.

Like clojure.pprint, this pretty printer has a linear runtime and uses bounded space. However, unlike clojure.pprint, Fipp's implementation is tuned for great performance and has a functional, data-driven API.

The data interface is agnostic to the source language. Printers are included for Edn data and Clojure code, but it is easy to create a pretty printer for your own language or documents: Even if they're not made out of Clojure data!

Fipp is great for printing large data files and debugging macros, but it is not suitable as a code reformatting tool. (explanation)

Criterium measures the computation time of an expression. It is designed to address some of the pitfalls of benchmarking, and benchmarking on the JVM in particular.

This includes: - statistical processing of multiple evaluations - inclusion of a warm-up period, designed to allow the JIT compiler to optimise its code - purging of gc before testing, to isolate timings from GC state prior to testing - a final forced GC after testing to estimate impact of cleanup on the timing results.

The claypoole library provides threadpool-based parallel versions of Clojure functions such as pmap, future, and for.

A Clojure/Datomic library for idempotently transacting datoms (norms) into your database – be they schema, data, or otherwise.

In the simplest sense, conformity allows you to write migrations and ensure that they run once and only once.

In a more general sense, conformity allows you to declare expectations (in the form of norms) about the state of your database, and enforce those idempotently without repeatedly transacting schema, required data, etc.

This library is a full implementation of Facebook's GraphQL specification.

Lacinia should be viewed as roughly analogous to the official reference JavaScript implementation. In other words, it is a backend-agnostic GraphQL query execution engine. Lacinia is not an Object Relational Mapper ... it's simply the implementation of a contract sitting between the GraphQL client and your data.

Lacinia features:

• An EDN-based schema language, or use GraphQL's Interface Definition Language.
• High performance parser for GraphQL queries, built on Antlr4.
• Efficient and asynchronous query execution.
• Full support for GraphQL types, interfaces, unions, enums, input objects, and custom scalars.
• Union types in SDL now support an optional leading vertical bar (|) before the first member, following the GraphQL specification. For example:

  union Searchable =
    | Business
    | Employee

• Full support for GraphQL subscriptions.
• Full support of inline and named query fragments.
• Full support for GraphQL Schema Introspection.

A lot of us feel a little lost as we start to use Clojure and try to make sense of how we should model data. If we came from a schema or type-based system many of us are tempted to apply those skills directly. We have a notion (reinforced by talks we watch) that these namespaced keywords are important, but we often struggle to apply those concepts pragmatically.

In this talk, I’ll discuss how the ideas of context-free federated names (a.k.a. namespace-qualified keywords) have become more concrete and pragmatic to me during my use of them at NuBank. I’ll talk about my realizations on how they can be used in practical ways that lead to a high level of clarity in our data models and communication systems, and open up better flexibility and reach.

Finally, I’ll relate these concepts to recent advances in the communication of this kind of data at the systems level as a graph, and show how industry standards like GraphQL continue to suffer from problems of composition and generality, while Clojure’s approach leads to an open information system with maximal utility: the Maximal Graph.

This is a stand-alone developer’s guide for version 3 of Fulcro. It is intended to be used by beginners and experienced developers and covers most of the library in detail. Fulcro has a pretty extensive set of resources on the web tailored to fit your learning style.

There is this book, the docstrings/clojure docs, and even a series of YouTube videos. Even more resources can be reached via the Fulcro Community site.

A lot of time and energy went into creating these libraries and materials and providing them free of charge. If you find them useful please consider contributing to the project.

Of course fixes to this guide are also appreciated as pull requests against the github repository.

This book includes quite a bit of live code. Live code demos with their source.

• fulcro by fulcrologic
• GitHub - fulcrologic/fulcro: A library for development of single-page full-stack web applications in clj/cljs · GitHub

jank is a general-purpose programming language which embraces the interactive, value-oriented nature of Clojure as well as the desire for native compilation and minimal runtimes. jank is strongly compatible with Clojure and considers itself a dialect of Clojure. Please note that jank is under heavy development; assume all features are planned or incomplete.

Where jank differs from Clojure JVM is that its host is C++ on top of an LLVM-based JIT. This allows jank to offer the same benefits of REPL-based development while being able to seamlessly reach into the native world and compete seriously with JVM's performance.

Still, jank is a Clojure dialect and thus includes its code-as-data philosophy and powerful macro system. jank remains a functional-first language which builds upon Clojure's rich set of persistent, immutable data structures. When mutability is needed, jank offers a software transaction memory and reactive agent system to ensure clean and correct multi-threaded designs.

If Emacs’s editing model and keybindings are so atrocious, then why not reprogram it? Evil is an Emacs extension that implements Vim in Emacs. It’s been around for a while, and from what I can gather, it’s quite complete. You have all the basic editing commands, can define leader key combinations, the ex commands (the : prompt) are implemented. An advanced Vim user will probably find some things missing. If that’s you please do let me know what it is! I’ve been asking my Vimmy friends and so far haven’t gotten much concrete feedback.

For an upper intermediate user it seems Evil is more than good enough, and it’s only getting better.

YS (aka YAMLScript) is a new YAML loader for 15 (and counting) programming languages:
C#, Clojure, Crystal, Go, Haskell, Java, Julia, Lua, NodeJS, Perl, PHP, Python, Raku, Ruby and Rust.

Try using YS in place of your current YAML loader!

• It's as easy to use as your current YAML loader
  • Loads your existing YAML files properly
• It works the same way in every programming language
  • Same API, same features, same bugs, same bug fixes
• YS has optional functional programming features
  • File imports, string interpolation, standard library, etc
  • Everything a compiled programming language has

How can YS offer all this?

83 languages for you to master

Become fluent in your chosen programming languages by completing these tracks created by our awesome team of contributors

This page collects advice and resource for those new to programming (where Clojure is one of their first programming languages).

Electric is a new way to build rich, interactive web products that simply have too much interactivity, realtime streaming, and too rich network connections to be able to write all the frontend/backend network plumbing by hand. With Electric, you can compose your client and server expressions directly (i.e. in the same function), and the Electric compiler macros will infer at compile time the implied frontend/backend boundary and generate the corresponding full-stack app.

Missionary is a reactive dataflow programming toolkit providing referentially transparent operators for lazy continuous signals, eager discrete streams, and IO actions. Missionary aims to improve over state-of-the-art reactive systems, it can be used as a general-purpose asynchronous programming toolkit but also as a basis for event streaming and incremental computations.

Graph is a simple, declarative abstraction to express compositional structure.

Declarative means that we should explicitly list a system’s components and dependencies in a way that is accessible to our tooling. This solves the issues of the previous section, enabling abstractions over a system’s components as well as reasoning about the composition as a whole. Of course, this idea is not new; for example, it is the basis of graph computation frameworks like Pregel, Dryad, and Storm, and existing libraries for system composition such as react.

Our primary objective in Graph is to distill this idea to its simplest, most idiomatic expression in Clojure, our language of choice. Concretely, a Graph is just a Clojure map of functions that can depend on the outputs of other functions. Because Graphs are just ordinary data, we can manipulate them for free using our favorite existing tools, making Graphs trivially easy to create, modify, run, reason about, test, and build upon. Put simply, Graph is an [FCA][swe] for composition.

It is better to have 100 functions operate on one data structure than 10
functions on 10 data structures.
  -- Alan Perlis

As a first attempt in this direction, we could rewrite our stats example as a Clojure map, turning let variables into keywords and wrapping each of the corresponding value expressions in anonymous functions.

This gets us 90% of the way there. The individual components of the computation are now explicit, but the dependency information is still missing. For instance, there’s no way for our tools to know that the m in the arguments to the :v function refers to the mean computed in the second step of the graph – after compilation, it’s just the first argument to an anonymous function.

• GitHub - plumatic/plumbing: Prismatic's Clojure(Script) utility belt · GitHub
• Plumbing 0.4.0 API documentation