HN Debrief

Show HN: Woxi - Open-source Mathematica / Wolfram Language reimplementation

  • Open Source
  • Programming
  • Developer Tools
  • Science

Woxi is an open-source interpreter for the Wolfram Language written in Rust, paired with a Mathematica-like GUI called Woxi Studio and exposed through a CLI, Jupyter kernel, Python package, npm package, and WASM module. The project is aiming at a hard target: keep enough Wolfram Language compatibility to run real code, while improving the parts that matter in modern use like startup speed, embeddability, and open deployment. The author says conformance is backed by roughly 26,000 unit tests and 900 script snapshot tests, and that support now reaches almost everything up to Mathematica 6.0 with some notable gaps such as MathLink and the parallel APIs.

If your team touches symbolic math, scientific tooling, or notebook-heavy internal workflows, Woxi is worth watching as a practical way to embed Wolfram-style computation without a proprietary runtime. The adoption blocker is no longer basic legitimacy but compatibility depth, frontend polish, and whether it can cover the specific domains you rely on like PDEs, control systems, or rich math input.

Discussion mood

Strongly positive. People who know Mathematica see real value in an open, faster, embeddable implementation of the Wolfram Language, especially because they dislike the fragmented feel of Sage and SymPy. The main reservations were missing advanced features, frontend gaps, and concern about the legal risk of reimplementing a proprietary language.

Key insights

  1. 01

    Why Mathematica users stay loyal

    What keeps people paying for Mathematica is not only symbolic math performance. It is the fact that the language, libraries, and naming all fit together as one system. Comments about Sage and Python-based stacks landed on the same complaint: they feel like wrappers around disconnected tools, so users spend effort translating between interfaces instead of thinking about the math. That frames Woxi's target correctly. Matching the integrated experience matters more than merely matching isolated functions.

    If you are building technical software, integration quality is a product feature in its own right. Evaluate Woxi on whether it preserves one consistent mental model across notebook, scripting, and APIs, not just on benchmark snippets.

      Attribution:
    • xvilka #1
    • ykonstant #1
    • yaroslavvb #1
  2. 02

    Compatibility fails at the boring edges

    The most useful early adopter report was not about fancy algebra. It was about mundane runtime details like $VersionNumber and $InputFileName breaking a downstream tool, wljs. That is exactly the sort of issue that decides whether a language clone works in practice, because ecosystem code often depends on system variables, file semantics, and undocumented expectations as much as core math functions.

    If you trial Woxi against existing Wolfram code, start with your actual scripts and toolchain glue. Expect the first blockers to be runtime semantics and environment assumptions, not headline math features.

      Attribution:
    • bobajeff #1
  3. 03

    It can already run real workloads

    The encouraging signal was that people were not limited to toy examples. One person got multivariable calculus visualizations from a university course site to display in Woxi Studio. The author also said Rubi mostly works, which points to nontrivial compatibility with a well-known rule-based integration system. That does not prove parity, but it does show the project has crossed from demo status into partial execution of existing Wolfram artifacts.

    This is mature enough for targeted pilot use. Test it on a narrow slice of your current notebooks or symbolic workflows instead of waiting for full parity before touching it.

      Attribution:
    • ethanc8 #1
    • adius #1
  4. 04

    Frontend input may decide adoption

    For at least one paying Mathematica user, the blocker was not algebra coverage but interactive 2D math input. The author's response made clear that this is not a personal priority, which exposes a gap between hacker-friendly ASCII workflows and the expectations of many notebook users. The TeXmacs suggestion reinforced that the front end could be modular rather than rebuilt entirely inside Woxi Studio.

    If your users enter math visually, track the frontend story as closely as language compatibility. A strong bridge to TeXmacs or another notation editor could matter more than another batch of core functions.

      Attribution:
    • dataminded #1
    • adius #1
    • lejalv #1

Against the grain

  1. 01

    A clone can trap you in old UX

    The sharpest pushback was that recreating Mathematica may preserve a powerful language while also preserving an aging interaction model. The author's answer was telling: compatibility with legacy code is the priority now, and any better syntax or frontend would come later. That means Woxi's near-term roadmap is constrained by the very system it is trying to liberate users from.

    If you care more about new ways to work with math than about Wolfram compatibility, this may not be the right project to bet on. Treat it as an infrastructure layer first, not a fresh interface paradigm.

      Attribution:
    • jshaqaw #1
    • adius #1
  2. 02

    Legal and licensing questions are still live

    There was credible unease about reimplementing a proprietary language from a company known for taking intellectual property seriously. Another comment undercut the urgency a bit by pointing out that Wolfram Engine is free for personal and development use, which narrows the immediate pain for some users. Together, those points make Woxi look more compelling for open deployment and embedding than for casual hobby use alone.

    Before adopting Woxi in a company product, have counsel review the intellectual property posture and compare it with simply using Wolfram's free or paid licensing options. The business case is strongest where redistribution, embedding, or commercial constraints make the official runtime awkward.

      Attribution:
    • nickpsecurity #1
    • phforms #1

In plain english

CAS
Computer Algebra System, software that can manipulate mathematical expressions symbolically rather than only numerically.
CLI
Command-line interface, a way to run software from a terminal or shell.
Jupyter kernel
A backend process that lets Jupyter notebooks execute code in a specific programming language.
Mathematica
Wolfram's commercial software system for symbolic computation, numerical math, visualization, and notebooks.
MathLink
An older Wolfram protocol for connecting Mathematica to external programs.
npm
Node Package Manager, the standard package registry and toolchain for JavaScript and Node.js projects.
Rubi
Rule-Based Integrator, an open-source system for symbolic integration built around a large set of transformation rules.
Rust
A systems programming language focused on performance and memory safety.
Sage
An open-source mathematics system that combines many existing math packages under a common interface, often through Python.
SymPy
An open-source symbolic mathematics library for Python.
TeXmacs
A scientific editing system that supports high-quality mathematical typesetting and can connect to computer algebra systems.
WASM
WebAssembly, a binary format that lets browsers run code compiled from languages other than JavaScript at near-native speed.
wljs
A JavaScript-related Wolfram Language tool mentioned by a commenter that expects compatibility with wolframscript behavior.
Wolfram Language
The programming language used by Mathematica for symbolic math, scientific computing, and notebook-based workflows.

Reference links

Project documentation and repository

Wolfram ecosystem references

Examples and integration ideas

Related code and experiments

  • scryerpy
    Example Python binding project offered as a model for structured tree APIs
  • steelpy
    Another example of low-effort Python bindings for structured trees
  • microeggpy
    Third example cited for Python binding patterns relevant to Woxi's API