Deep Diamond: Clojure Tensors on DNNL and CUDA
A fast Clojure Tensor & Deep Learning library
At a glance
- What is it?
- Deep Diamond is a Clojure library that wraps native CPU and GPU computation routines for tensor and neural network work. The repository tells you which artifacts exist and which repositories to add, but the README itself is thin on API detail, so the adoption decision rests on how comfortable you are with native dependencies.
- Who is it for?
- Adopt Deep Diamond if your computation already lives in Clojure and you are willing to manage native CPU or GPU libraries as part of your build. Do not adopt it if you need a pure JVM dependency with no native components, or if you want the library's own documentation to teach you the API.
- Can I use it commercially?
- Yes, with conditions. EPL-1.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly Clojure, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Deep Diamond Is Actually For
The README describes Deep Diamond as a Clojure library for fast tensors and neural network related computations, built on highly optimized native libraries and computation routines for both CPU and GPU. That sentence is the whole scope statement. The project targets people writing numerical and deep learning code in Clojure who do not want to leave the language to get near-native throughput. It is not a general-purpose array library for Java interop, and it is not a framework that ships pretrained models or a training loop you configure with a few keywords. The repository topics list clojure, cuda, deep-learning, deep-neural-networks, dnnl, gpu, java and nvidia, which tells you where the performance is expected to come from: native code paths, not JVM loops. The homepage field points at aiprobook.com, and the README opens with two book covers, Deep Learning for Programmers and Numerical Linear Algebra for Programmers. The author's documentation strategy is the books. If you are evaluating this library, budget for the possibility that the API explanation you need lives behind a subscription rather than in the repository.
The Artifact Split Is the Architecture
The most concrete design decision visible in the README is that Deep Diamond is published as several artifacts rather than one. Alongside the aggregate coordinate uncomplicate/deep-diamond, Clojars carries org.uncomplicate/deep-diamond-base, org.uncomplicate/deep-diamond-dnnl, org.uncomplicate/deep-diamond-cuda and org.uncomplicate/deep-diamond-bnns. The naming maps onto the native backends named in the project description and topics: DNNL for CPU, CUDA for GPU, BNNS on the Apple side, with a base layer underneath. This is a deliberate separation. A build that only needs CPU tensor math should not be forced to pull GPU bindings, and a GPU build should be able to select its backend explicitly. The trade-off is that dependency selection becomes your problem. You have to know which backend your target machine can actually run before you add a coordinate, and a project that mixes them needs a story for machines that lack the hardware. The README does not explain how the artifacts relate to each other beyond listing them, so the mapping from artifact to supported platform is something you confirm from the example project rather than from prose.
Getting It Into a Build
The installation instructions are short. The README says the library is in Clojars and shows the version badges for uncomplicate/deep-diamond and for the four org.uncomplicate artifacts. It then states that you also need to add 2 maven central repositories to your project, and points at the hello-world-aot example at examples/hello-world-aot/project.clj in the repository as the place to see how. That example is named for AOT, ahead-of-time compilation, which is a meaningful hint: a project that loads native libraries and is consumed from a JVM typically wants compilation ahead of time rather than relying on runtime class loading. The README does not reproduce the repository declarations inline, so the exact repository URLs and the exact dependency vector are things you copy from that file. Two facts are worth noting before you start. First, the presence of a hello-world example specifically labelled AOT suggests the plain REPL path may not be the intended first experience. Second, the README gives no version number in text, only badges, so the version you pin comes from Clojars at the moment you look. Nothing in the supplied material describes a lein or deps.edn template beyond that one project.clj reference.
Where the Documentation Stops
The README is roughly a page long and contains no API examples, no function signatures, no shape conventions, no dtype list and no explanation of how a tensor is constructed or how a network layer is defined. It contains no benchmarks, so any performance claim you have seen elsewhere is not traceable to this file. It contains no release notes, and the material supplied lists no recent releases at all. For an engineer deciding whether to adopt, that is the central risk: the repository signals intent and packaging, not usage. The README explicitly directs readers to books available for subscription at aiprobook.com, and also to a Patreon page. That is a legitimate funding model for a one-author numerical library, and the author is named in the licence line as Dragan Djuric with copyright 2019-2025. It does mean the free surface is small. If your team cannot commit to reading a book or to reverse-engineering the example, the cost of the first working tensor is higher than the artifact list suggests.
Native Backends and the Failure Modes They Bring
Because the computation routines are native, the failure modes are native too. A build that references the CUDA artifact on a machine without a suitable NVIDIA driver will not degrade into a slow CPU path on its own; the dependency is there whether or not the hardware is. The same logic applies to the DNNL artifact on a platform where that library is not available. The README does not describe a fallback mechanism, a runtime capability check, or a documented error message for a missing backend, so treat backend selection as a deployment decision rather than something the library resolves for you. The AOT example in the repository is consistent with this: ahead-of-time compilation reduces the surface where class loading and native linking can go wrong at runtime. A second limitation is portability of the build itself. Teams that ship a single JVM artifact across mixed hardware now have more than one dependency profile to maintain, and CI needs a machine that matches each profile. None of this is unusual for a library that wraps DNNL and CUDA, but it is the part the README does not prepare you for.
How It Differs From Neanderthal and DJL
The nearest comparison inside the same ecosystem is Neanderthal, the author's own Clojure library for native matrix and linear algebra work. The difference in approach is scope and abstraction level. Neanderthal targets dense linear algebra: matrices and vectors, BLAS and LAPACK style operations. Deep Diamond sits above that territory and targets tensors and neural network related computations, which means higher-rank arrays and the operations a network needs, dispatched to DNNL, CUDA or BNNS depending on the artifact you chose. If your work is solving linear systems or doing statistics, Neanderthal is the closer fit and Deep Diamond is extra machinery. If your work is a network, the tensor abstractions and the backend split are the reason to be here. The other comparison worth naming is DJL, the Java deep learning library, whose approach is to load engines such as PyTorch or TensorFlow through a Java API and to expose model loading and inference as first-class operations. Deep Diamond does not present itself that way. It is a Clojure-first tensor library over native routines, not a model zoo or an engine-agnostic inference layer. Choose based on whether you want to write the computation or load someone else's model.
Maintenance, Licence and the Cost of Upgrading
Deep Diamond is distributed under the Eclipse Public License, version 1.0 or, at your option, any later version. The copyright line reads 2019-2025 Dragan Djuric. EPL-1.0 is a file-level copyleft licence with a patent grant, and it is the same family used across much of the Clojure ecosystem, so it is unlikely to surprise a Clojure team. It is not a permissive licence in the MIT sense, and if your organisation has rules about copyleft dependencies, that is a question for your own counsel rather than something this article can settle. On maintenance: the repository is not archived and the last push recorded is 2026-08-19, so the project is active. The material supplied lists no recent releases, which makes it hard to say how often versions land or what an upgrade path looks like. Practically, the upgrade cost is dominated by the native backends, not by the Clojure code. When DNNL or CUDA moves, the artifact that binds to it has to move too, and your pinned version is the thing that decides whether you get that. Pin explicitly, and re-check the hello-world-aot project file when you bump, because that file is the only build reference the README offers.
Editorial conclusion
Adopt Deep Diamond if your computation already lives in Clojure and you are willing to manage native CPU or GPU libraries as part of your build. Do not adopt it if you need a pure JVM dependency with no native components, or if you want the library's own documentation to teach you the API. Before writing code, verify three things: which artifact matches your hardware target, that the two Maven Central repositories are declared in your project file, and that the EPL-1.0 terms fit how you distribute the result. The README is a pointer to the books and the hello-world-aot example, not a reference manual.
Community notes