[HN Gopher] Woxi: Wolfram Mathematica Reimplementation in Rust
___________________________________________________________________
Woxi: Wolfram Mathematica Reimplementation in Rust
Author : adamnemecek
Score : 215 points
Date : 2026-02-25 18:24 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| adius wrote:
| Hi, I'm the main developer. We're steadily getting closer to the
| next release which will support most features of Mathematica 1.0
| plus some of the most popular newer functions (> 900 overall!).
| AMA!
| apetresc wrote:
| What percentage of the overall code was written primarily by
| agents?
| cs702 wrote:
| https://github.com/ad-si/Woxi/graphs/contributors
| muizelaar wrote:
| How does it compare to mathics?
|
| How close is it to being able to run rubi:
| https://rulebasedintegration.org/?
| disentanglement wrote:
| You can find the whole integration routine here
| https://github.com/ad-
| si/Woxi/blob/36343ab2cbc97e5081f7c811e.... It's essentially a
| test mock-up (not even trying partial fraction decomposition
| for rational functions).
| cs702 wrote:
| Thank you for sharing this on HN.
|
| It's a worthwhile effort. If successful, Woxi can enable a
| large mass of scientists and engineers who don't have access to
| Mathematica to run legacy code written for it. Also, Woxi would
| give those scientists and engineers who regularly use
| Mathematica a non-proprietary, less restrictive alternative,
| which many of them would welcome.
|
| How does Woxi compare to other "clean-room implementations"[a]
| of the same language?
|
| --
|
| [a] Please check with a lawyer to make sure you won't run into
| legal or copyright issues.
| utopiah wrote:
| Interesting, thanks for sharing. Naive question as I'm not
| familiar with Mathematica much (but aware of it and Wolfram
| Alpha and related tools), how does it compare to e.g. Jupyter
| or Julia or maybe another language (with its framework) that
| might be even closer?
| adius wrote:
| I think Wolfram Language is just so much more ergonomic. No
| need to import dependencies - everything's included and
| consistent, very readable - yet compact - syntax, less
| gotchas than Python, R, etc., sensible default, ...
| Y_Y wrote:
| Ymmv, but I've found that you sure do need to import things
| eventually, and it's not so ergonomic because most projects
| just end up as mega-notebooks.
|
| Just like Python or any other language that looks easy for
| the learning examples, there are still hairy bits, they're
| just better hidden. The difference is that the debuggers
| for Python are far better.
|
| Mathematica is great for quick stuff, but once you hit a
| particular level complexity it goes crazy. In this regard I
| find it similar to Bash.
| dist-epoch wrote:
| Why would I use this and not Wolfram Script?
|
| Better license? Allowed for commercial operations?
| adius wrote:
| Exactly! And:
|
| - Faster startup time because of no license check
|
| - Can run multiple instances of Woxi at the same time
|
| - Embeddable via WASM
|
| - Configurable via compile time flags (which features should
| be included)
|
| - ...
| foobarqux wrote:
| How is the popularity/rank in functions.csv determined?
| adius wrote:
| That's actually a value that Wolfram determines themselves.
| Here is the documentation for it: https://reference.wolfram.c
| om/language/ref/WolframLanguageDa...
|
| Here is e.g. all the values for the Plus[] function:
|
| $ wolframscript -code 'WolframLanguageData["Plus", "Ranks"]'
| {All -> 6, StackExchange -> 8, TypicalNotebookInputs -> 5,
| TypicalProductionCode -> 6, WolframAlphaCodebase -> 6,
| WolframDemonstrations -> 4, WolframDocumentation -> 4}
| egl2020 wrote:
| There's a mystique around Mathematica's math engine. Is this
| groundless, or will you eventually run into problems getting
| correct, identical answers -- especially for answers that
| Mathematic derives symbolically? The capabilities and results
| of the computer algebra systems that I've used varied widely.
| adius wrote:
| Hard to tell honestly. So far there was always some
| surprisingly straight forward solution If had any problems
| with the math engine. There is actually a lot of public
| research how equations can be solved/simplified with computer
| algorithms. So I'm optimistic. I also stumbled upon a few
| cases where Mathematica itself didn't quite do things
| correctly itself (rounding errors, missing simplifications,
| etc.). So maybe it's actually a little overhyped ...
| Y_Y wrote:
| I also found problems with integrating some obscure
| functions a few years black, though IIRC the issue was
| remedies by using the amazing Rubi package:
|
| https://rulebasedintegration.org/
| foobarqux wrote:
| Have you considered using quickcheck/random/property-based
| testing with LLM code generation to automate function
| implementation?
| adius wrote:
| Yeah, I've already looked into it, but decided to keep
| developing it "example driven" for now. Aka I'm playing
| around with it, and whenever I find something that's broken I
| keep a note of it and then I pick those notes one by one and
| implement them. Once the most common things are implemented I
| will start writing property tests to catch all the edge cases
| of each feature.
| foobarqux wrote:
| I'm saying you can go even further and automate the entire
| thing using LLMs/agents, it is pretty much the ideal use
| case: you have a black-box reference implementation to test
| against; descriptive documentation for what the functions
| should do; some explicitly supplied examples in the
| documentation; and the ability to automatically create an
| arbitrary number of tests.
|
| So not only do you have a closed loop system that has
| objective/automatic pass-fail criteria you also don't even
| have to supply the instructions about what the function is
| supposed to do or the test cases!
|
| Obviously this isn't going to be 100% reliable (especially
| for edge cases) but you should be able to get an enormous
| speed up. And in many cases you should be able to supply
| the edge case tests and have the LLM fix it.
|
| (Codex is still free for the next few days if you want to
| try their "High"/"Extra high" thinking models)
| thrtythreeforty wrote:
| You accidentally raise an interesting point: good,
| thorough public documentation, once considered a great
| selling point for your system, now invites automated
| reimplementation by competition. It would be a shame to
| see public docs vanish because it turns out they are
| literally machine readable specs.
| pwdisswordfishy wrote:
| LSP?
| adius wrote:
| Not yet, but on the roadmap!
| the__alchemist wrote:
| I love Rust for mathematical and scientific tasks (I am building
| the structural bio crate infrastructure), and I love Mathematica
| and have a personal sub. I should be the audience, but... What
| makes Mathematica great, IMO, is the polish and overall
| experience created by consistent work with applications in mind
| over decades. So, I look at this project with skepticism
| regarding its utility.
| amelius wrote:
| Yeah, the Mathematica language is the least interesting aspect
| of the Mathematica system. Closely followed by the interactive
| notebooks.
| aeonik wrote:
| I disagree, the language itself is one of the more elegant
| parts of the system, and enables a lot of the rest of the
| elegance.
|
| From a purely programming language theory, it's pretty
| unique.
|
| I once tried to find a language that had all the same
| properties, and I failed. The Factor language is probably the
| closest. But they are still pretty different.
| zozbot234 wrote:
| The relevant programming paradigm is string/term rewriting,
| which is featured in other programming languages such as
| Pure. It seems to have few direct applications outside of
| symbolic computing itself, compilers and related fields
| such as PL theory. (Formal calculi and languages are often
| specified in PL theory as rewrite rules, even though the
| practical implementation may ultimately differ.)
| s3p wrote:
| First I believe there is no such thing as the Mathematica
| language, it's Wolframscript which is useful in a bunch of
| different applications. And second, if you don't have access
| to a $1000 / yr wolfram subscription, this would be the next
| best thing.
| adius wrote:
| They rebranded it to Wolfram Language a few years ago
| (which I actually appreciate, as it is so much more than
| just "math" by now!)
|
| https://writings.stephenwolfram.com/2013/02/what-should-
| we-c...
| stared wrote:
| The notebooks were THE thing of Mathematica, at least to me.
| 12 years ago, as I was finishing my PhD in quantum optics, I
| wanted to migrate to the stack used in industry - and picked
| Python. Also, that way I was an early adopter of Jupyter
| Notebook, as it captured what was need + was open.
|
| Now Mathematica notebooks (still remember, it is .nb) do not
| have the novelty factor. But they were the first to set a
| trend, which we now take for granted.
|
| That said, I rarely use notebooks anymore. In the coding
| time, it is much easier to create scripts and ask to create a
| visualization in HTML.
| abdullahkhalids wrote:
| > Closely followed by the interactive notebooks.
|
| Mathematica's notebooks are the only environment where I can
| do some computation to arrive at a _symbolic_ expression.
| Copy the expression from the output cell into a new input
| cell. Then manipulate it by hand into the form I want. Then
| continue processing it further.
|
| Also, symbolic expressions can be written nicely with actual
| superscripts and subscripts, and with non-latin characters.
|
| One of the best features of Mathematica system.
| lejalv wrote:
| Have a look at TeXmacs! (https://texmacs.org)
|
| (AFAIK, you can run Mathematica sessions in TeXmacs, get
| proper typesetting, and can copy/paste expressions for
| simplification by hand or using other CAS sessions in the
| same TeXmacs document).
| adius wrote:
| Sure, but you've got to start somewhere! And with the amount of
| progress I was able to make in just a few weeks, I'm very
| optimistic that the polish will come sooner rather than later.
| the__alchemist wrote:
| Based on the list of contributors to your project, I am not
| sure this starting location is optimally suited to the task
| of building a foundation for polished, reliable, expandable
| software.
| s3p wrote:
| The sneering on HN really has no end. This is a good
| project! I for one am very excited to see an interpreter
| born out of rust.
| mountainriver wrote:
| It's so obnoxious
| Keyframe wrote:
| It's a defense mechanism. I was guilty as charge as well
| initially. Suddenly most of your l33t skillz are
| trivialized and surpassed by an inhumane actor. It's a
| tough pill to swallow.
| adius wrote:
| It's having ~ 5000 tests already. Used correctly, AI agents
| can help you _improve_ the quality of the code!
| the__alchemist wrote:
| Do you see why this perspective is a red flag on its own?
| mountainriver wrote:
| No I don't, review your code
| supriyo-biswas wrote:
| If I go by the contributor numbers on Github, I see
| Claude has committed something on the order of 300,000
| lines of code. I don't think it's reasonable to review
| that much code, even in weeks worth of time.
| ComplexSystems wrote:
| I certainly don't. If a software developer has found a
| way to use these tools that works well for them and
| produces good results, that's a good thing.
| copperx wrote:
| God help us.
| adampunk wrote:
| In that case I kindly refer you to the matter of Arkell v.
| Pressdam.
| jjtheblunt wrote:
| i'm curious if you intend to reimplement highly optimized
| numerical algorithms, symbolic algorithms, and so on,
| accumulated and tuned in mathematica since its 1988 release?
|
| it's a huuuuuuuuge amount of technology in the standard
| library of mathematica, beyond the surface syntax and rewrite
| system, i mean.
| rustyhancock wrote:
| Similarly I'm not sure Octave ever really got that polish to
| compete with MATLAB.
|
| SPSS is hilariously painful to use. Still it's only losing
| ground ever so slowly. PSPP remains almost unheard of among
| SPSS core users.
| 3eb7988a1663 wrote:
| I am not sure Octave ever had to put on that much polish. It
| just had to be decent enough to save $$$$ vs a Matlab
| license. If it can drop-in run the code that has been keeping
| the lab going for decades, good enough.
| gmueckl wrote:
| MathWorks offers a huge list of "toolboxes", domain
| specific extensions that cover a lot of features in each
| domain. Replacing Matlab isn't about the core language
| alone.
| tstenner wrote:
| Which often means that e.g. loading an image for
| displaying it increases cost by a few thousands
| gmueckl wrote:
| The price tags are wild for sure. But the sheer number of
| supported features is what makes them attractive. Cloning
| that completely is practically infeasable.
| wolvesechoes wrote:
| > It just had to be decent enough to save $$$$ vs a Matlab
| license
|
| And it failed at this.
| hasley wrote:
| I did my PhD with Octave. Sure, I did not have this nice
| convex optimization toolbox. But I had everything else I
| needed and did not need to wait because people arrived
| earlier in the lab and grabbed all floating licenses of,
| for instance, the communications toolbox.
|
| However, I switched to Python during the last years.
| drnick1 wrote:
| Half-assed reimplementations of existing software (often in the
| name of "memory safety") is what the Rust community is best
| known for.
| the__alchemist wrote:
| I find rust to be the best language and tool set in most
| categories. I still agree with this characterization.
| nextaccountic wrote:
| Mathematica is proprietary software. Any reimplementation is
| better than nothing at all, at least for people that don't
| run proprietary software
| wolvesechoes wrote:
| Useless thing is not less useless by the virtue of being
| FOSS. That's something FOSS folks have yet to understand.
|
| All the best to the author, they definitely have fun doing
| this, but I've seen enough of such attempts. Having agents
| doesn't make much difference.
| downboots wrote:
| Great! Math tools for everyone.
|
| what's stopping some Mathematica employee from taking the source
| code and having an agent port it. Or even reconstruction from the
| manual. Who owns an algorithm?
|
| Will everything get copied eventually?
| adius wrote:
| According to https://en.wikipedia.org/wiki/Lotus_Development_Co
| rp._v._Bor...., a software clone does not infringe software
| copyright. So yeah, I'd guess sooner or later everything is
| going be cloned ...
| MengerSponge wrote:
| > what's stopping some employee from something like Mathematica
| from taking the source code and having an agent port it to open
| source
|
| Laws against theft. Also the same reason employees don't
| release the code on pastebin or something.
|
| > Who owns an algorithm?
|
| The org or person who was granted the software patent.
| https://en.wikipedia.org/wiki/Software_patent
|
| > Will everything get copied eventually?
|
| If we're lucky. More likely everything bitrots as technical
| capabilities are lost. Slowly at first, then quickly.
| downboots wrote:
| https://en.wikipedia.org/wiki/Illegal_number
| Y_Y wrote:
| Which patent are you referring to?
| shwaj wrote:
| Any patent. The question was who owns a (arbitrary)
| algorithm. The elaborated answer is that nobody "owns" an
| algorithm (i.e. has intellectual property rights to it)
| without a patent: in USA and many other jurisdictions,
| patents are the IP tool relating to algorithms.
| fnord77 wrote:
| vibe coded?
| adius wrote:
| Such a massive undertaking would be almost impossible without
| AI agents, so yeah, they help me. But with around 5000 tests,
| they are actually helping to _improve_ the software quality!
| throawayonthe wrote:
| are all the tests hand written or are some agent-contributed?
| curious
| mountainriver wrote:
| What's the difference if you review the code getting
| merged?
| i_cannot_hack wrote:
| Reviewing the correctness of code is a lot harder than
| writing correct code, in my experience. Especially when
| the code given looks correct on an initial glance, and
| leads you into faulty assumptions you would not have made
| otherwise.
|
| I'm not claiming AI-written and human-reviewed code is
| necessarily bad, just that the claim that reviewing code
| is equivalent to writing it yourself does not match my
| experience at all.
| tempest_ wrote:
| Plus if you look at the commit cadence there is a lot of
| commits like 5-10 minutes a part in places that add new
| functionality (which I realize doesn't mean they were
| "written" in that time)
|
| I find people do argue a lot about "if it is reviewed it
| is the same" which might be easy when you start but I
| think the allure of just glancing going "it makes sense"
| and hammering on is super high and hard to resist.
|
| We are still early into the use of these tools so perhaps
| best practices will need to be adjusted with these tools
| in mind. At the moment it seems to be a bit of a crap
| shoot to me.
| throawayonthe wrote:
| i mean idk that's sorta like asking what's the difference
| of having tests if you review the code getting merged
| IshKebab wrote:
| The difference is we can't tell if you reviewed the code.
| layer8 wrote:
| To be fair, we also couldn't tell for sure if they hand-
| wrote the code.
| IshKebab wrote:
| If they hand wrote the code we know they at least looked
| at it once.
| tock wrote:
| Did you actually review 313,397 LOC written by claude? And
| you wrote the tests? That's honestly very impressive if yes.
| WillAdams wrote:
| For folks who are considering passing, note that there is a
| "Jupyter Lite" mode in addition to "Woxi Studio" --- seems very
| promising and the former addressed my first concern out-the-gate.
| esafak wrote:
| I wonder if it would make a good Zeppelin interpreter.
| https://zeppelin.apache.org/
| adius wrote:
| Oh cool, haven't heard of this before. Could be a good fit -
| I'll have to try it out some day!
| anandijain wrote:
| This is cool! I've always wanted a polished kernel on the
| terminal. I spent a lot of time a few years ago writing my own
| Wolfram Kernel. It was a blast to understand how a pattern
| matching (symbolic) language is implemented.
|
| https://github.com/anandijain/cas8.rs
| singularity2001 wrote:
| Is the syntax for symbolic computation already near optimal or
| should something be rethought and redone?
| oofbey wrote:
| AGPL licensed. An interesting choice. Author really doesn't want
| Wolfram to use it??
| adius wrote:
| Why should I want them to use it?
| oofbey wrote:
| Well it would get vastly more popular if it was officially
| endorsed. Do you want lots of people using it?
| pwdisswordfishy wrote:
| Why is that important?
| poly2it wrote:
| Because you get changes upstreamed.
| peterus wrote:
| I regularly use Mathematica for working with symbolic expressions
| (for its DSolve and transfer function stuff) and it is way more
| maintainable and elegant to have fractions, symbols and powers
| rendered in math mode instead of having to deal with a text only
| representation. Are there any front ends (either custom or
| somehow extending jupyter) for this project which recreate this
| experience?
| lejalv wrote:
| Maybe http://texmacs.org would fit here!
| samwillis wrote:
| Have you considered doing property tests with Mathematica as an
| oracle?
|
| An ai based development workflow with a concrete oracle works
| very well. You still need the research and planing to solve
| things in a scalable way, but it solves the "are the tests
| correct" issue.
|
| What we've done is pull out failing property tests as a unit
| tests, makes regression testing during the agentic coding loop
| much more efficient.
| Grosvenor wrote:
| My Bona fides: I've written my own Mathematica clone at least
| twice, maybe three times. Each time I get it parsing expressions
| and doing basic math, getting to basic calculus. Then I look up
| the sheer cliff face in front of me and think better of the whole
| thing.
|
| There is an architectural flaw in Woxi that will sink it hard.
| Looking through the codebase things like polynomials are
| implemented in the rust code, not in woxilang. This will kill you
| long term.
|
| The right approach is to have a tiny core interpreter, maybe go
| to JIT at some point if you can figure that out. Then implement
| all the functionality in woxilang itself. That means addition and
| subtraction, calculus, etc are term rewriting rules written in
| woxilang, not rust code.
|
| This frees you up in the interpreter. Any improvements you make
| there will immediately show up over the entire language. It's
| also a better language to implement symbolic math in than rust.
|
| It also means contributors only need to know one language:
| woxilang. No need to split between rust and woxilang.
| adius wrote:
| Mh, I thought about this a little and came actually to exactly
| the opposite conclusion: Implement as much as possible in Rust
| to get the fastest code possible. Do you have any more insights
| why this should not be possible / unsustainable?
| Grosvenor wrote:
| You have two distinct products 1) An interpreter 2) a math
| language. Don't write your math in some funny imperative
| computer language.
|
| Keep the interpreters surface area as small as possible. Do
| some work to make sure you can accelerate numeric, and
| JIT/compile functions down to something as close to native as
| you can.
|
| Wolfram, and Taliesin Beynon have both said Wolfram were
| working internally to get a JIT working in the interpreter
| loop. Keep the core small, and do that now while it's easy.
|
| Also, it's just easier to write in Mathematica. It's probably
| 10x smaller than the rust code:
| f[x_Integer]:=13*x; f::help:="Multiplies x by 13, in
| case you needed an easy function for that."
|
| EDIT: Another important thing to note is the people who
| really deeply know specific subjects in math won't be the
| best, or even good rust programmers. So letting them program
| in woxilang will give the an opportunity to contribute which
| they wouldn't have had otherwise.
| layer8 wrote:
| Symbolic manipulation?
| 0x3f wrote:
| Switching out to an interpreted language has got to be anathema
| to a rewrite-it-in-Rust project
| nextaccountic wrote:
| implementing addition in woxilang itself?? this gotta be
| terribly slow. am i missing something?
| tadfisher wrote:
| You are missing the term "JIT", which would enable a host of
| runtime optimizations which include generating calls to some
| static piece of native code which performs addition.
| porcoda wrote:
| I noticed the same thing, having also written an interpreter
| for the Wolfram language that focused on the core
| rule/rewriting/pattern language. At its heart it's more or less
| a Lisp-like language where the core can be quite small and a
| lot of the functionality built via pattern matching and
| rewriting atop that. Aside from the sheer scale of WL, I ended
| up setting aside my experiments replicating it when I did
| performance comparisons and realized how challenging it would
| be to not just match WL in functionality but performance.
|
| Woxi reminds me of some experiments I did to see how far vibe
| coding could get me on similar math and symbolic reasoning
| tools. It seems like unless you explicitly and very actively
| force a design with a small core, the models tend towards
| building out a lot of complex, hard-coded logic that ultimately
| is hard to tune, maintain, or reason about in terms of
| correctness.
|
| Interesting exercise with woxi in terms of what vibe coding can
| produce. Not sure about the WL implementation though.
|
| (For context, I write compiler/interpreter tools for a living -
| have been for a couple decades)
| LowLevelKernel wrote:
| Many Wolfram language algorithms are proprietary right?
___________________________________________________________________
(page generated 2026-02-28 23:00 UTC)