DSLCAD: a Rust scripting language for building 3D models

A scripted CAD language with a Rust core

DSLCad, pronounced DieselCAD, is a programming language and interpreter for building 3D models. It is inspired by OpenSCAD, in the sense that you describe a part in source code and the tool produces the geometry, but the implementation is different in every layer below that idea.

The primary language of the repository is Rust, and the repository layout makes the structure of the workspace explicit. The Cargo.toml declares four members:

[workspace]
resolver = "2"
members = [
    "crates/dslcad",
    "crates/dslcad_occt",
    "crates/dslcad_storage",
    "crates/dslcad_viewer",
]

So there is a core crate for the language and the CLI, a crate that wraps OCCT, the Open CASCADE geometry kernel, a storage crate, and a separate viewer crate. Splitting the viewer out is what lets the same language run in a terminal and in a browser window without dragging the UI into the interpreter.

The geometry kernel is the reason this project is not a weekend project. OCCT is a large C++ library, and the justfile shows the author working around its build requirements. The CMAKE_POLICY_VERSION_MINIMUM is set to 3.5 because OCCT's vendored CMake project still asks for compatibility with CMake below 3.5, which newer CMake versions refuse to configure without that override. The CMAKE_BUILD_PARALLEL_LEVEL is set from nproc, and the target triple is derived from rustc at build time.

The audience is someone who scripts geometry rather than draws it, and who wants a modern toolchain around a language they already think in.

Building with just, and the OCCT cache that hides the pain

The build instructions are short because the build system does the work. The stated dependencies are Rust and Just, the command runner at github.com/casey/just, and the build command is:

just build

The README explains what that does. It first builds OCCT if needed, then builds the rest of the application, and OCCT is cached in the occt_prebuilt folder. That cache is the difference between a build that takes minutes and one that takes hours, and it is the single most important practical fact about compiling this project.

The justfile also shows that the build is a multi-target affair rather than a single binary. There is a build target for the main dslcad binary, a build-examples target that zips the examples directory, a build-vscode-extension target that packages the editor extension with vsce and renames the result to dslcad.vsix, and a separate build-viewer target for the viewer crate.

The target selection is where the interesting constraints live. The wasm32-unknown-emscripten target is handled specially, because emcc does not link the C++ runtime by default and the C++ sources in dslcad-occt and OpenCASCADE need it for exceptions and the standard library, so the build sets DEFAULT_TO_CXX. The comment in the justfile records why CI pins Rust 1.92 for that target, because 1.93 and later enable WebAssembly exception handling by default and the result is currently miscompiled for OpenCASCADE, with an invalid br_table.

That level of detail in a build file is a good sign of what you are getting into: the browser build is supported, but it rests on a specific toolchain combination that the author has had to pin.

The syntax choices that differ from OpenSCAD

The FAQ explains that DSLCAD aims to build upon the formula established by OpenSCAD while keeping a more limited scope, no text editor, and offering a viewer for rapid part development plus a CLI for automation. The listed novel ideas are where the language actually differs.

Two are geometric operators, chamfer and fillet, described as a way to simplify part creation. Both of these are things a human doing CAD in a GUI reaches for constantly and that a pure OpenSCAD-style CSG approach makes awkward, so having them in the language is a genuine ergonomic gain for the target workflow.

Three are language and workflow changes. The ability to create multiple parts, in other words several 3D models, from a single file changes the shape of a project directory, since a related set of parts can live in one source file rather than in several. Object style properties give access to variables through the object, written in the documentation as my_gear.radius, which is a readability change rather than a capability one. And top to bottom readability using pipes, the -> operator, to reduce nesting complexity, which is the clearest departure from the OpenSCAD habit of deeply nested blocks.

Two more are packaging decisions. A single binary per platform for portability, and a focused workflow with the aim of using the 2D first then 3D part design flow, which is the sketch-then-solid path most people actually want but rarely take.

The examples directory shows the language in use, with files named cube.ds, gear.ds, fillet_edges.ds, sketch.ds, slice.ds, solids.ds, dimensions.ds, points.ds, properties.ds, options.ds and fidget_cube.ds, alongside the advanced.ds and resources.ds files and directories such as barn, fastener, res, step_import and svg_import. The import directories tell you STEP and SVG are supported as inputs, which is how you get existing parts into the workflow.

Two applications, and the author says which one matters

The FAQ on focus is the most honest passage in the README. There are two apps, the DSLCAD CLI and the DSLCAD Editor. The author states that the focus is on the CLI, and that there is currently no energy to develop for the editor, with an invitation for anyone who wants to contribute.

That is worth taking at face value, because it determines what you should adopt. If you want a scriptable modelling language and a command line you can run in a build or a pipeline, this repository delivers that today. If you want a graphical editor for sketching parts interactively, the project is not where you should start, and the author is not going to pretend otherwise.

The documentation lives on a separate site, the dschroer.github.io/dslcad pages, and the repository carries a mkdocs.yml with a docs/ directory and a docs_theme/ directory, so the docs are built from the repository with a custom theme. There is also an extensions/ directory with a vscode extension, which gives you syntax support for the.ds files in an editor you already use, and that is a reasonable answer to the missing integrated editor.

The pre-built binaries are listed for Windows, MacOS, Linux and browsers through WebAssembly, and the README points at the Releases tab for the download. One detail to note: the release link in the README points at a repository named model-script rather than dslcad, which suggests the releases live under a different repository name than the one you are reading.

The licence is LGPL-2.1, which is a mild obligation on a derived work rather than a strict copyleft of your whole product.

Version 0.0.6 and what that number implies

The release history is v0.0.6 on 2026-09-23, v0.0.4 on 2025-01-29 and v0.0.3 on 2024-01-14, and the last push to the repository was on 2026-09-30. The version numbering is the clearest signal about where the project stands.

A 0.0.x version in the Rust ecosystem is the conventional way of saying that the public API is not yet stable and may change without a major version bump. For a language with an interpreter, a storage format and a viewer, that means the language surface, the file formats and the crate APIs are all fair game to change. The CHANGELOG.md at the repository root is where you would look for what changed, and the fact that there is a CHANGELOG is a point in the project's favour.

The gap between the release dates is also telling. v0.0.3 to v0.0.4 is a year, v0.0.4 to v0.0.6 is twenty months, and the v0.0.5 release is not in the list. So development is continuous but the release cadence is irregular, which is a normal shape for a solo-maintained language project and a poor shape for a dependency in a production pipeline.

The repository also carries a TODO.md, which for a project at this stage is arguably more informative than the README about where the author is heading, and a renovate.json, which suggests dependency updates are handled automatically rather than by hand. There is a .opencode/ directory and a .rusty-hook.toml at the root, so some of the author's own tooling is committed alongside the project.

Where a different tool is the better answer

There are three situations where this project is not the right choice, and they are worth naming before you invest in porting anything.

The first is when your work is interactive rather than scripted. A viewer and a CLI do not replace a parametric modelling environment where you change a dimension and watch the model update, with the whole tree of features and constraints laid out in front of you. OpenSCAD's editor and the wider OpenSCAD ecosystem exist for that, and the author says as much when he states the limited scope and the absent text editor.

The second is when you rely on the shared model ecosystem. A large part of OpenSCAD's value is the collection of published models and the community around them. Porting to a new language means porting that content, and the .ds examples in this repository are instructive precisely because they are hand-written rather than imported from a large library.

The third is the build weight. The geometry kernel is OCCT, the C++ library with a heavy build, and the WebAssembly path needs a pinned Rust version and a specific emcc configuration. If your environment cannot build OCCT or cannot host a Rust toolchain, this project is not reachable, whereas a scripting approach on top of an existing CAD kernel would be.

There is also a design-level limit that is inherent rather than a gap to be filled. A CSG-and-primitives language, which is what OpenSCAD established and what DSLCAD builds on, is not a substitute for a constraint or assembly modeller. If your parts are assemblies of constrained components rather than solids described by operations, the language model itself is the mismatch, and no amount of operator sugar changes that.

Editorial conclusion

Adopt DSLCAD if you script your parametric 3D models and want OpenSCAD's idea without OpenSCAD's toolchain, and you are willing to work from a language at version 0.0.6 with an editor the maintainer is not working on. Do not adopt it if you need a mature text editor, a large community of shared models, or a stable language specification. Verify first that your OpenSCAD models port, that the just build step compiles OCCT on your machine, and that the CLI is the path you want, because the author states the focus is on the CLI and the editor is not being developed.

Frequently asked questions

Official sources

1. DSchroer/dslcad on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases